doc: Add RFC documents

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]
+