summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3570.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3570.txt')
-rw-r--r--doc/rfc/rfc3570.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc3570.txt b/doc/rfc/rfc3570.txt
new file mode 100644
index 0000000..32d82e1
--- /dev/null
+++ b/doc/rfc/rfc3570.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group P. Rzewski
+Request for Comments: 3570 Media Publisher, Inc.
+Category: Informational M. Day
+ Cisco
+ D. Gilletti
+ July 2003
+
+
+ Content Internetworking (CDI) Scenarios
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ In describing content internetworking as a technology targeted for
+ use in production networks, it is useful to provide examples of the
+ sequence of events that may occur when two content networks decide to
+ interconnect. The scenarios presented here seek to provide some
+ concrete examples of what content internetworking is, and also to
+ provide a basis for evaluating content internetworking proposals.
+
+Table of Contents
+
+ 1. Introduction...................................................2
+ 1.1. Terminology..............................................3
+ 2. Special Cases of Content Networks..............................3
+ 2.1. Publishing Content Network...............................3
+ 2.2. Brokering Content Network................................3
+ 2.3. Local Request-Routing Content Network....................4
+ 3. Content Internetworking Arrangements...........................5
+ 4. Content Internetworking Scenarios..............................5
+ 4.1. General Content Internetworking..........................6
+ 4.2. BCN providing ACCOUNTING INTERNETWORKING and
+ REQUEST-ROUTING INTERNETWORKING..........................9
+ 4.3. BCN providing ACCOUNTING INTERNETWORKING................11
+ 4.4. PCN ENLISTS multiple CNs................................12
+ 4.5. Multiple CNs ENLIST LCN.................................13
+ 5. Security Considerations.......................................15
+ 5.1. Threats to Content Internetworking......................15
+ 5.1.1. Threats to the CLIENT.............................15
+
+
+
+Rzewski, et al. Informational [Page 1]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+ 5.1.2. Threats to the PUBLISHER..........................17
+ 5.1.3. Threats to a CN...................................17
+ 6. Acknowledgements..............................................18
+ 7. References....................................................18
+ 8. Authors' Addresses............................................19
+ 9. Full Copyright Statement......................................20
+
+1. Introduction
+
+ In [1], the concept of a "content network" is introduced and
+ described. In addition to describing some general types of content
+ networks, it also describes motivations for allowing content networks
+ to interconnect (defined as "content internetworking").
+
+ In describing content internetworking as a technology targeted for
+ use in production networks, it's useful to provide examples of the
+ sequence of events that may occur when two content networks decide to
+ interconnect. Naturally, different types of content networks may be
+ created due to different business motivations, and so many
+ combinations are likely.
+
+ This document first provides detailed examples of special cases of
+ content networks that are specifically designed to participate in
+ content internetworking (Section 2). We then discuss the steps that
+ would be taken in order to "bring up" or "tear down" a content
+ internetworking arrangement (Section 3). Next we provide some
+ detailed examples of how content networks (such as those from Section
+ 2) could interconnect (Section 4). Finally, we describe any security
+ considerations that arise specifically from the examples presented
+ here (Section 5).
+
+ The scenarios presented here answer two distinct needs:
+
+ 1. To provide some concrete examples of what content internetworking
+ is, and
+
+ 2. To provide a basis for evaluating content internetworking
+ proposals.
+
+ A number of content internetworking systems have been implemented,
+ but there are few published descriptions. One such description is
+ [2].
+
+1.1. Terminology
+
+ Terms in ALL CAPS are defined in [1] except for the following terms
+ defined below in this document: PCN, BCN, and LCN. Additionally, the
+ term SLA is used as an abbreviation for Service Level Agreement.
+
+
+
+Rzewski, et al. Informational [Page 2]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+2. Special Cases of Content Networks
+
+ A CN may have REQUEST-ROUTING, DISTRIBUTION, and ACCOUNTING
+ interfaces. However, some participating networks may gravitate
+ toward particular subsets of the CONTENT INTERNETWORKING interfaces.
+ Others may be seen differently in terms of how they relate to their
+ CLIENT bases. This section describes these refined cases of the
+ general CN case so they may be available for easier reference in the
+ further development of CONTENT INTERNETWORKING scenarios. The
+ special cases described are the Publishing Content Network, the
+ Brokering Content Network, and the Local Request-Routing Content
+ Network.
+
+2.1. Publishing Content Network
+
+ A Publishing Content Network (PCN), maintained by a PUBLISHER,
+ contains an ORIGIN and has a NEGOTIATED RELATIONSHIP with two or more
+ CNs. A PCN may contain SURROGATES for the benefit of serving some
+ CONTENT REQUESTS locally, but does not intend to allow its SURROGATES
+ to serve CONTENT on behalf of other PUBLISHERS.
+
+ Several implications follow from knowing that a particular CN is a
+ PCN. First, the PCN contains the AUTHORITATIVE REQUEST-ROUTING
+ SYSTEM for the PUBLISHER's CONTENT. This arrangement allows the
+ PUBLISHER to determine the distribution of CONTENT REQUESTS among
+ ENLISTED CNs. Second, it implies that the PCN need only participate
+ in a subset of CONTENT INTERNETWORKING. For example, a PCN's
+ DISTRIBUTION INTERNETWORKING SYSTEM need only be able to receive
+ DISTRIBUTION ADVERTISEMENTS, it need not send them. Similarly, a
+ PCN's REQUEST-ROUTING INTERNETWORKING SYSTEM has no reason to send
+ AREA ADVERTISEMENTS. Finally, a PCN's ACCOUNTING INTERNETWORKING
+ SYSTEM need only be able to receive ACCOUNTING data, it need not send
+ it.
+
+2.2. Brokering Content Network
+
+ A Brokering Content Network (BCN) is a network that does not operate
+ its own SURROGATES. Instead, a BCN operates only CIGs as a service
+ on behalf other CNs. A BCN may therefore be regarded as a
+ "clearinghouse" for CONTENT INTERNETWORKING information.
+
+ For example, a BCN may choose to participate in DISTRIBUTION
+ INTERNETWORKING and/or REQUEST-ROUTING INTERNETWORKING in order to
+ aggregate ADVERTISEMENTS from one set of CNs into a single update
+ stream for the benefit of other CNs. To name a single specific
+ example, a BCN could aggregate CONTENT SIGNALS from CNs that
+ represent PUBLISHERS into a single update stream for the benefit of
+ CNs that contain SURROGATES. A BCN may also choose to participate in
+
+
+
+Rzewski, et al. Informational [Page 3]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+ ACCOUNTING INTERNETWORKING in order to aggregate utilization data
+ from several CNs into combined reports for CNs that represent
+ PUBLISHERS.
+
+ This definition of a BCN implies that a BCN's CIGs would implement
+ the sending and/or receiving of any combination of ADVERTISEMENTS and
+ ACCOUNTING data as is necessary to provide desired services to other
+ CONTENT NETWORKS. For example, if a BCN is only interested in
+ aggregating ACCOUNTING data on behalf of other CNs, it would only
+ need to have an ACCOUNTING INTERNETWORKING interface on its CIGs.
+
+2.3. Local Request-Routing Content Network
+
+ Another type of CN is the Local Request-Routing CONTENT NETWORK
+ (LCN). An LCN is defined as a type of network where CLIENTS' CONTENT
+ REQUESTS are always handled by some local SERVER (such as a caching
+ proxy [1]). In this context, "local" is taken to mean that both the
+ CLIENT and SERVER are within the same administrative domain, and
+ there is an administrative motivation for forcing the local mapping.
+ This type of arrangement is common in enterprises where all CONTENT
+ REQUESTS must be directed through a local SERVER for access control
+ purposes.
+
+ As implied by the name, the LCN creates an exception to the rule that
+ there is a single AUTHORITATIVE REQUEST-ROUTING SYSTEM for a
+ particular item of CONTENT. By directing CONTENT REQUESTS through
+ the local SERVER, CONTENT RESPONSES may be given to CLIENTS without
+ first referring to the AUTHORITATIVE REQUEST-ROUTING SYSTEM. Knowing
+ this to be true, other CNs may seek a NEGOTIATED RELATIONSHIP with an
+ LCN in order to perform DISTRIBUTION into the LCN and receive
+ ACCOUNTING data from it. Note that once SERVERS participate in
+ DISTRIBUTION INTERNETWORKING and ACCOUNTING INTERNETWORKING, they
+ effectively take on the role of SURROGATES. However, an LCN would
+ not intend to allow its SURROGATES to be accessed by non-local
+ CLIENTS.
+
+ This set of assumptions implies multiple things about the LCN's
+ CONTENT INTERNETWORKING relationships. First, it is implied that the
+ LCN's DISTRIBUTION INTERNETWORKING SYSTEM need only be able to send
+ DISTRIBUTION ADVERTISEMENTS, it need not receive them. Second, it is
+ implied that an LCN's ACCOUNTING INTERNETWORKING SYSTEM need only be
+ able to send ACCOUNTING data, it need not receive it. Finally, due
+ to the locally defined REQUEST-ROUTING, the LCN would not participate
+ in REQUEST-ROUTING INTERNETWORKING.
+
+
+
+
+
+
+
+Rzewski, et al. Informational [Page 4]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+3. Content Internetworking Arrangements
+
+ When the controlling interests of two CNs decide to interconnect
+ their respective networks (such as for business reasons), it is
+ expected that multiple steps would need to occur.
+
+ The first step would be the creation of a NEGOTIATED RELATIONSHIP.
+ This relationship would most likely take the form of a legal document
+ that describes the services to be provided, cost of services, SLAs,
+ and other stipulations. For example, if an ORIGINATING CN wished to
+ leverage another CN's reach into a particular country, this would be
+ laid out in the NEGOTIATED RELATIONSHIP.
+
+ The next step would be to configure CONTENT INTERNETWORKING protocols
+ on the CIGs of the respective CNs in order to technically support the
+ terms of the NEGOTIATED RELATIONSHIP. To follow our previous
+ example, this could include the configuration of the ENLISTED CN's
+ CIGs in a particular country to send DISTRIBUTION ADVERTISEMENTS to
+ the CIGs of the ORIGINATING CN. In order to configure these
+ protocols, technical details (such as CIG addresses/hostnames and
+ authentication information) would be exchanged by administrators of
+ the respective CNs.
+
+ Note also that some terms of the NEGOTIATED RELATIONSHIP would be
+ upheld through means outside the scope of CDI protocols. These could
+ include non-technical terms (such as financial settlement) or other
+ technical terms (such as SLAs).
+
+ In the event that the controlling interests of two CNs no longer wish
+ to have their networks interconnected, it is expected that these
+ tasks would be undone. That is, the protocol configurations would be
+ changed to cease the movement of ADVERTISEMENTS and/or ACCOUNTING
+ data between the networks, and the NEGOTIATED RELATIONSHIP would be
+ legally terminated.
+
+4. Content Internetworking Scenarios
+
+ This section provides several scenarios that may arise in CONTENT
+ INTERNETWORKING implementations.
+
+ Note that we obviously cannot examine every single permutation.
+ Specifically, it should be noted that:
+
+ o Any one of the interconnected CNs may have other CONTENT
+ INTERNETWORKING arrangements that may or may not be transitive to
+ the relationships being described in the diagram.
+
+
+
+
+
+Rzewski, et al. Informational [Page 5]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+ o The graphical figures do not illustrate the CONTENT REQUEST paths.
+ It is assumed that a REQUEST-ROUTING SYSTEM eventually returns to
+ the CLIENT the IP address of the SURROGATE deemed appropriate to
+ honor the CLIENT's CONTENT REQUEST.
+
+ The scenarios described include a general case, two cases in which
+ BCNs provide limited interfaces, a case in which a PCN enlists the
+ services of multiple CNs, and a case in which multiple CNs enlist the
+ services of an LCN.
+
+4.1. General Content Internetworking
+
+ This scenario considers the general case where two or more existing
+ CNs wish to establish a CONTENT INTERNETWORKING relationship in order
+ to provide increased scale and reach for their existing customers.
+ It assumes that all of these CNs already provide REQUEST-ROUTING,
+ DISTRIBUTION, and ACCOUNTING services and that they will continue to
+ provide these services to existing customers as well as offering them
+ to other CNs.
+
+ In this scenario, these CNs would interconnect with others via a CIG
+ that provides a REQUEST-ROUTING INTERNETWORKING SYSTEM, a
+ DISTRIBUTION INTERNETWORKING SYSTEM, and an ACCOUNTING
+ INTERNETWORKING SYSTEM. The net result of this interconnection would
+ be that a larger set of SURROGATES will now be available to the
+ CLIENTS.
+
+ Figure 1 shows three CNs which have interconnected to provide greater
+ scale and reach to their existing customers. They are all
+ participating in DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING
+ INTERNETWORKING, and ACCOUNTING INTERNETWORKING.
+
+ As a result of the NEGOTIATED RELATIONSHIPS it is assumed that:
+
+ 1. CONTENT that has been INJECTED into any one of these ORIGINATING
+ CNs may be distributed into any other ENLISTED CN.
+
+ 2. Commands affecting the DISTRIBUTION of CONTENT may be issued
+ within the ORIGINATING CN, or may also be issued within the
+ ENLISTED CN. The latter case allows local decisions to be made
+ about DISTRIBUTION within the ENLISTED CN, but such commands would
+ not control DISTRIBUTION within the ORIGINATING CN.
+
+ 3. ACCOUNTING information regarding CLIENT access and/or DISTRIBUTION
+ actions will be made available to the ORIGINATING CN by the
+ ENLISTED CN.
+
+
+
+
+
+Rzewski, et al. Informational [Page 6]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+ 4. The ORIGINATING CN would provide this ACCOUNTING information to
+ the PUBLISHER based on existing Service Level Agreements (SLAs).
+
+ 5. CONTENT REQUESTS by CLIENTS may be directed to SURROGATES within
+ any of the ENLISTED CNs.
+
+ The decision of where to direct an individual CONTENT REQUEST may be
+ dependent upon the DISTRIBUTION and REQUEST-ROUTING policies
+ associated with the CONTENT being requested as well as the specific
+ algorithms and methods used for directing these requests. For
+ example, a REQUEST-ROUTING policy for a piece of CONTENT may indicate
+ multiple versions exist based on the spoken language of a CLIENT.
+ Therefore, the REQUEST-ROUTING SYSTEM of an ENLISTED CN would likely
+ direct a CONTENT REQUEST to a SURROGATE known to be holding a version
+ of CONTENT of a language that matches that of a CLIENT.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rzewski, et al. Informational [Page 7]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+ Figure 1 - General CONTENT INTERNETWORKING
+
+ +--------------+ +--------------+
+ | CN A | | CN B |
+ |..............| +---------+ +---------+ |..............+
+ | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
+ |..............| | CONTENT | | CONTENT | |..............|
+ | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
+ |..............| | GATEWAY | | GATEWAY | |..............|
+ | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |
+ +--------------+ +---------+ +---------+ +--------------+
+ | ^ \^ \ \ ^/ ^/ ^/ | ^
+ v | \\ \\ \\ // // // v |
+ +--------------+ \\ \\ \\ // // // +--------------+
+ | SURROGATES | \\ v\ v\ /v /v // | SURROGATES |
+ +--------------+ \\+---------+// +--------------+
+ ^ | v| |v ^ |
+ | | | CONTENT | | |
+ | | |INTWRKING| | |
+ | | | GATEWAY | | |
+ | | | | | |
+ | | +---------+ | |
+ | | ^| ^| ^| | |
+ | | || || || | |
+ | | |v |v |v | |
+ | | +--------------+ | |
+ | | | CN C | | |
+ | | |..............| | |
+ | | | REQ-ROUTING | | |
+ | | |..............| | |
+ \ \ | DISTRIBUTION | / /
+ \ \ |..............| / /
+ \ \ | ACCOUNTING | / /
+ \ \ |--------------| / /
+ \ \ | ^ / /
+ \ \ v | / /
+ \ \ +--------------+ / /
+ \ \ | SURROGATES | / /
+ \ \ +--------------+ / /
+ \ \ | ^ / /
+ \ \ | | / /
+ \ \ v | / /
+ \ \ +---------+ / /
+ \ \-->| CLIENTS |---/ /
+ \----| |<---/
+ +---------+
+
+
+
+
+
+Rzewski, et al. Informational [Page 8]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+4.2. BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING
+ INTERNETWORKING
+
+ This scenario describes the case where a single entity (BCN A)
+ performs ACCOUNTING INTERNETWORKING and REQUEST-ROUTING
+ INTERNETWORKING functions, but has no inherent DISTRIBUTION or
+ DELIVERY capabilities. A potential configuration which illustrates
+ this concept is given in Figure 2.
+
+ In the scenario shown in Figure 2, BCN A is responsible for
+ collecting ACCOUNTING information from multiple CONTENT NETWORKS (CN
+ A and CN B) to provide a clearinghouse/settlement function, as well
+ as providing a REQUEST-ROUTING service for CN A and CN B.
+
+ In this scenario, CONTENT is injected into either CN A or CN B and
+ its DISTRIBUTION between these CNs is controlled via the DISTRIBUTION
+ INTERNETWORKING SYSTEMS within the CIGs. The REQUEST-ROUTING SYSTEM
+ provided by BCN A is informed of the ability to serve a piece of
+ CONTENT from a particular CONTENT NETWORK by the REQUEST-ROUTING
+ SYSTEMS within the interconnected CIGs.
+
+ BCN A collects statistics and usage information via the ACCOUNTING
+ INTERNETWORKING SYSTEM and disseminates that information to CN A and
+ CN B as appropriate.
+
+ As illustrated in Figure 2, there are separate REQUEST-ROUTING
+ SYSTEMS employed within CN A and CN B. If the REQUEST-ROUTING SYSTEM
+ provided by BCN A is the AUTHORITATIVE REQUEST-ROUTING SYSTEM for a
+ given piece of CONTENT this is not a problem. However, each
+ individual CN may also provide the AUTHORITATIVE REQUEST-ROUTING
+ SYSTEM for some portion of its PUBLISHER customers. In this case
+ care must be taken to ensure that the there is one and only one
+ AUTHORITATIVE REQUEST-ROUTING SYSTEM identified for each given
+ CONTENT object.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rzewski, et al. Informational [Page 9]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+ Figure 2 - BCN providing ACCOUNTING INTERNETWORKING and
+ REQUEST-ROUTING INTERNETWORKING
+
+ +--------------+
+ | BCN A |
+ |..............| +-----------+
+ | REQ-ROUTING |<===>| |
+ |..............| | CONTENT |
+ | ACCOUNTING |<===>| INTWRKING |
+ +--------------+ | GATEWAY |
+ | |
+ +-----------+
+ ^| ^| ^| ^|
+ +--------------+ // // \\ \\ +--------------+
+ | CN A | |v |v |v |v | CN B |
+ |..............| +---------+ +---------+ |..............|
+ | REQ-ROUTING |<=>| | | |<=>| REQ-ROUTING |
+ |..............| | CONTENT | | CONTENT | |..............|
+ | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
+ |..............| | GATEWAY | | GATEWAY | |..............|
+ | ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
+ +--------------+ +---------+ +---------+ +--------------+
+ | ^ | ^
+ v | v |
+ +--------------+ +--------------+
+ | SURROGATES | | SURROGATES |
+ +--------------+ +--------------+
+ ^ \ ^ /
+ \ \ / /
+ \ \ / /
+ \ \ / /
+ \ \ +---------+ / /
+ \ \---->| CLIENTS |-----/ /
+ \------| |<-----/
+ +---------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rzewski, et al. Informational [Page 10]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+4.3. BCN providing ACCOUNTING INTERNETWORKING
+
+ This scenario describes the case where a single entity (BCN A)
+ performs ACCOUNTING INTERNETWORKING to provide a clearinghouse/
+ settlement function only. In this scenario, BCN A would enter into
+ NEGOTIATED RELATIONSHIPS with multiple CNs that each perform their
+ own DISTRIBUTION INTERNETOWRKING and REQUEST-ROUTING INTERNETWORKING
+ as shown in FIGURE 3.
+
+ Figure 3 - BCN providing ACCOUNTING INTERNETWORKING
+
+ +--------------+
+ | BCN A |
+ |..............| +-----------+
+ | ACCOUNTING |<===>| |
+ +--------------+ | CONTENT |
+ | INTWRKING |
+ | GATEWAY |
+ | |
+ +-----------+
+ ^| ^|
+ +--------------+ // \\ +--------------+
+ | CN A | |v |v | CN B |
+ |..............| +---------+ +---------+ |..............|
+ | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
+ |..............| | CONTENT | | CONTENT | |..............|
+ | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
+ |..............| | GATEWAY | | GATEWAY | |..............|
+ | ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
+ +--------------+ +---------+ +---------+ +--------------+
+ | ^ | ^
+ v | v |
+ +--------------+ +--------------+
+ | SURROGATES | | SURROGATES |
+ +--------------+ +--------------+
+ ^ \ ^ /
+ \ \ / /
+ \ \ / /
+ \ \ / /
+ \ \ +---------+ / /
+ \ \---->| CLIENTS |-----/ /
+ \------| |<-----/
+ +---------+
+
+
+
+
+
+
+
+
+Rzewski, et al. Informational [Page 11]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+4.4. PCN ENLISTS multiple CNs
+
+ In the previously enumerated scenarios, PUBLISHERS have not been
+ discussed. Much of the time, it is assumed that the PUBLISHERS will
+ allow CNs to act on their behalf. For example, a PUBLISHER may
+ designate a particular CN to be the AUTHORITATIVE REQUEST-ROUTING
+ SYSTEM for its CONTENT. Similarly, a PUBLISHER may rely on a
+ particular CN to aggregate all its ACCOUNTING data, even though that
+ data may originate at SURROGATES in multiple distant CNs. Finally, a
+ PUBLISHER may INJECT content only into a single CN and rely on that
+ CN to ENLIST other CNs to obtain scale and reach.
+
+ However, a PUBLISHER may wish to maintain more control and take on
+ the task of ENLISTING CNs itself, therefore acting as a PCN (Section
+ 2.1). This scenario, shown in Figure 4, describes the case where a
+ PCN wishes to directly enter into NEGOTIATED RELATIONSHIPS with
+ multiple CNs. In this scenario, the PCN would operate its own CIG
+ and enter into DISTRIBUTION INTERNETWORKING, ACCOUNTING
+ INTERNETWORKING, and REQUEST-ROUTING INTERNETWORKING relationships
+ with two or more CNs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rzewski, et al. Informational [Page 12]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+ Figure 4 - PCN ENLISTS multiple CNs
+
+ +--------------+
+ | PCN |
+ |..............| +-----------+
+ | REQ-ROUTING |<=>| |<---\
+ |..............| | CONTENT |----\\
+ | DISTRIBUTION |<=>| INTWRKING | \\
+ |..............| | GATEWAY |--\ \\
+ | ACCOUNTING |<=>| |<-\\ \\
+ +--------------+ +-----------+ \\ \\
+ ^| ^| ^| ^| \\ ||
+ +--------------+ || || || \\ || || +--------------+
+ | CN A | |v |v |v \v |v |v | CN B |
+ |..............| +---------+ +---------+ |..............|
+ | REQ-ROUTING |<=>| | | |<=>| REQ-ROUTING |
+ |..............| | CONTENT | | CONTENT | |..............|
+ | DISTRIBUTION |<=>|INTWRKING| |INTWRKING|<=>| DISTRIBUTION |
+ |..............| | GATEWAY | | GATEWAY | |..............|
+ | ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
+ +--------------+ +---------+ +---------+ +--------------+
+ | ^ | ^
+ v | v |
+ +--------------+ +--------------+
+ | SURROGATES | | SURROGATES |
+ +--------------+ +--------------+
+ ^ \ ^ /
+ \ \ / /
+ \ \ / /
+ \ \ / /
+ \ \ +---------+ / /
+ \ \---->| CLIENTS |-----/ /
+ \------| |<-----/
+ +---------+
+
+4.5. Multiple CNs ENLIST LCN
+
+ A type of CN described in Section 2.3 is the LCN. In this scenario,
+ we imagine a tightly administered CN (such as within an enterprise)
+ has determined that all CONTENT REQUESTS from CLIENTS must be
+ serviced locally. Likely due to a large CLIENT base in the LCN,
+ multiple CNs determine they would like to engage in DISTRIBUTION
+ INTERNETWORKING with the LCN in order to extend control over CONTENT
+ objects held in the LCN's SURROGATES. Similarly, the CNs would like
+ to engage in ACCOUNTING INTERNETWORKING with the LCN in order to
+ receive ACCOUNTING data regarding the usage of the content in the
+ local SURROGATES. This scenario is shown in Figure 5. Although this
+ diagram shows a DISTRIBUTION INTERNETWORKING connection between CN A
+
+
+
+Rzewski, et al. Informational [Page 13]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+ and CN B, it should be recognized that this connection is optional
+ and not a requirement in this scenario.
+
+ Figure 5 - Multiple CNs ENLIST LCN
+
+ +--------------+ +--------------+
+ | CN A | | CN B |
+ +..............| +---------+ +---------+ |..............+
+ | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
+ |..............| | CONTENT | | CONTENT | |..............|
+ | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
+ |..............| | GATEWAY | | GATEWAY | |..............|
+ | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |
+ +--------------+ +---------+ +---------+ +--------------+
+ | ^ \^ \^ ^/ ^/ | ^
+ v | \\ \\ // // v |
+ +--------------+ \\ \\ // // +--------------+
+ | SURROGATES | v\ v\ /v /v | SURROGATES |
+ +--------------+ +---------+ +--------------+
+ | |
+ | CONTENT |
+ |INTWRKING|
+ | GATEWAY |
+ | |
+ +---------+
+ ^| ^|
+ || ||
+ |v |v
+ +--------------+
+ | LCN A |
+ |..............|
+ | DISTRIBUTION |
+ |..............|
+ | ACCOUNTING |
+ |--------------|
+ | ^
+ v |
+ +--------------+
+ | SURROGATES |
+ +--------------+
+ | ^
+ | |
+ v |
+ +---------+
+ | CLIENTS |
+ | |
+ +---------+
+
+
+
+
+Rzewski, et al. Informational [Page 14]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+5. Security Considerations
+
+ Security concerns with respect to Content Internetworking can be
+ generally categorized into trust within the system and protection of
+ the system from threats. The trust model utilized with Content
+ Internetworking is predicated largely on transitive trust between the
+ ORIGIN, REQUEST-ROUTING INTERNETWORKING SYSTEM, DISTRIBUTION
+ INTERNETWORKING SYSTEM, ACCOUNTING INTERNETWORING SYSTEM, and
+ SURROGATES. Network elements within the Content Internetworking
+ system are considered to be "insiders" and therefore trusted.
+
+5.1. Threats to Content Internetworking
+
+ The following sections document key threats to CLIENTs, PUBLISHERs,
+ and CNs. The threats are classified according to the party that they
+ most directly harm, but, of course, a threat to any party is
+ ultimately a threat to all. (For example, having a credit card
+ number stolen may most directly affect a CLIENT; however, the
+ resulting dissatisfaction and publicity will almost certainly cause
+ some harm to the PUBLISHER and CN, even if the harm is only to those
+ organizations' reputations.)
+
+5.1.1. Threats to the CLIENT
+
+5.1.1.1. Defeat of CLIENT's Security Settings
+
+ Because the SURROGATE's location may differ from that of the ORIGIN,
+ the use of a SURROGATE may inadvertently or maliciously defeat any
+ location-based security settings employed by the CLIENT. And since
+ the SURROGATE's location is generally transparent to the CLIENT, the
+ CLIENT may be unaware that its protections are no longer in force.
+ For example, a CN may relocate CONTENT from a Internet Explorer
+ user's "Internet Web Content Zone" to that user's "Local Intranet Web
+ Content Zone". If the relocation is visible to the Internet Explorer
+ browser but otherwise invisible to the user, the browser may be
+ employing less stringent security protections than the user is
+ expecting for that CONTENT. (Note that this threat differs, at least
+ in degree, from the substitution of security parameters threat below,
+ as Web Content Zones can control whether or not, for example, the
+ browser executes unsigned active content.)
+
+5.1.1.2. Delivery of Bad Accounting Information
+
+ In the case of CONTENT with value, CLIENTs may be inappropriately
+ charged for viewing content that they did not successfully access.
+ Conversely, some PUBLISHERs may reward CLIENTs for viewing certain
+
+
+
+
+
+Rzewski, et al. Informational [Page 15]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+ CONTENT (e.g., programs that "pay" users to surf the Web). Should a
+ CN fail to deliver appropriate accounting information, the CLIENT may
+ not receive appropriate credit for viewing the required CONTENT.
+
+5.1.1.3. Delivery of Bad CONTENT
+
+ A CN that does not deliver the appropriate CONTENT may provide the
+ user misleading information (either maliciously or inadvertently).
+ This threat can be manifested as a failure of either the DISTRIBUTION
+ SYSTEM (inappropriate content delivered to appropriate SURROGATEs) or
+ REQUEST-ROUTING SYSTEM (request routing to inappropriate SURROGATEs,
+ even though they may have appropriate CONTENT), or both. A REQUEST-
+ ROUTING SYSTEM may also fail by forwarding the CLIENT request when no
+ forwarding is appropriate, or by failing to forward the CLIENT
+ request when forwarding is appropriate.
+
+5.1.1.4. Denial of Service
+
+ A CN that does not forward the CLIENT appropriately may deny the
+ CLIENT access to CONTENT.
+
+5.1.1.5. Exposure of Private Information
+
+ CNs may inadvertently or maliciously expose private information
+ (passwords, buying patterns, page views, credit card numbers) as it
+ transmits from SURROGATEs to ORIGINs and/or PUBLISHERs.
+
+5.1.1.6. Substitution of Security Parameters
+
+ If a SURROGATE does not duplicate completely the security facilities
+ of the ORIGIN (e.g., encryption algorithms, key lengths, certificate
+ authorities) CONTENT delivered through the SURROGATE may be less
+ secure than the CLIENT expects.
+
+5.1.1.7. Substitution of Security Policies
+
+ If a SURROGATE does not employ the same security policies and
+ procedures as the ORIGIN, the CLIENT's private information may be
+ treated with less care than the CLIENT expects. For example, the
+ operator of a SURROGATE may not have as rigorous protection for the
+ CLIENT's password as does the operator of the ORIGIN server. This
+ threat may also manifest itself if the legal jurisdiction of the
+ SURROGATE differs from that of the ORIGIN, should, for example, legal
+ differences between the jurisdictions require or permit different
+ treatment of the CLIENT's private information.
+
+
+
+
+
+
+Rzewski, et al. Informational [Page 16]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+5.1.2. Threats to the PUBLISHER
+
+5.1.2.1. Delivery of Bad Accounting Information
+
+ If a CN does not deliver accurate accounting information, the
+ PUBLISHER may be unable to charge CLIENTs for accessing CONTENT or it
+ may reward CLIENTs inappropriately. Inaccurate accounting
+ information may also cause a PUBLISHER to pay for services (e.g.,
+ content distribution) that were not actually rendered. Invalid
+ accounting information may also effect PUBLISHERs indirectly by, for
+ example, undercounting the number of site visitors (and, thus,
+ reducing the PUBLISHER's advertising revenue).
+
+5.1.2.2. Denial of Service
+
+ A CN that does not distribute CONTENT appropriately may deny CLIENTs
+ access to CONTENT.
+
+5.1.2.3. Substitution of Security Parameters
+
+ If a SURROGATE does not duplicate completely the security services of
+ the ORIGIN (e.g., encryption algorithms, key lengths, certificate
+ authorities, client authentication) CONTENT stored on the SURROGATE
+ may be less secure than the PUBLISHER prefers.
+
+5.1.2.4. Substitution of Security Policies
+
+ If a SURROGATE does not employ the same security policies and
+ procedures as the ORIGIN, the CONTENT may be treated with less care
+ than the PUBLISHER expects. This threat may also manifest itself if
+ the legal jurisdiction of the SURROGATE differs from that of the
+ ORIGIN, should, for example, legal differences between the
+ jurisdictions require or permit different treatment of the CONTENT.
+
+5.1.3. Threats to a CN
+
+5.1.3.1. Bad Accounting Information
+
+ If a CN is unable to collect or receive accurate accounting
+ information, it may be unable to collect compensation for its
+ services from PUBLISHERs.
+
+
+
+
+
+
+
+
+
+
+Rzewski, et al. Informational [Page 17]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+5.1.3.2. Denial of Service
+
+ Misuse of a CN may make that CN's facilities unavailable, or
+ available only at reduced functionality, to legitimate customers or
+ the CN provider itself. Denial of service attacks can be targeted at
+ a CN's ACCOUNTING SYSTEM, DISTRIBUTION SYSTEM, or REQUEST-ROUTING
+ SYSTEM.
+
+5.1.3.3. Transitive Threats
+
+ To the extent that a CN acts as either a CLIENT or a PUBLISHER (such
+ as, for example, in transitive implementations) such a CN may be
+ exposed to any or all of the threats described above for both roles.
+
+6. Acknowledgements
+
+ The authors acknowledge the contributions and comments of Fred
+ Douglis (AT&T), Raj Nair (Cisco), Gary Tomlinson (CacheFlow), John
+ Scharber (CacheFlow), Nalin Mistry (Nortel), Steve Rudkin (BT),
+ Christian Hoertnagl (IBM), Christian Langkamp (Oxford University),
+ and Don Estberg (Activate).
+
+7. References
+
+ [1] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for
+ Content Internetworking (CDI)", RFC 3466, February 2003.
+
+ [2] Biliris, A., Cranor, C., Douglis, F., Rabinovich, M., Sibal, S.,
+ Spatscheck, O. and W. Sturm, "CDN Brokering", Proceedings of the
+ 6th International Workshop on Web Caching and Content
+ Distribution, Boston, MA, June 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rzewski, et al. Informational [Page 18]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+8. Authors' Addresses
+
+ Mark S. Day
+ Cisco Systems
+ 1414 Massachusetts Avenue
+ Boxborough, MA 01719
+ US
+
+ Phone: +1 978 936 1089
+ EMail: mday@alum.mit.edu
+
+
+ Don Gilletti
+ 21 22nd Ave.
+ San Mateo, CA 94403
+ US
+
+ Phone +1 408 569 6813
+ EMail: dgilletti@yahoo.com
+
+
+ Phil Rzewski
+ 30 Jennifer Place
+ San Francisco, CA 94107
+ US
+
+ Phone: +1 650 303 3790
+ EMail: philrz@yahoo.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rzewski, et al. Informational [Page 19]
+
+RFC 3570 CDI Scenarios July 2003
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rzewski, et al. Informational [Page 20]
+