idnits 2.17.1 draft-ietf-cdi-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 74 instances of too long lines in the document, the longest one being 29 characters in excess of 72. == There are 14 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7986 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 1217, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1225, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1255, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 1136 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 1591 (ref. '4') ** Obsolete normative reference: RFC 1771 (ref. '5') (Obsoleted by RFC 4271) ** Downref: Normative reference to an Informational RFC: RFC 1958 (ref. '6') ** Obsolete normative reference: RFC 2326 (ref. '7') (Obsoleted by RFC 7826) ** Obsolete normative reference: RFC 2396 (ref. '8') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2616 (ref. '9') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 2775 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 3040 (ref. '11') ** Downref: Normative reference to an Informational RFC: RFC 2904 (ref. '12') ** Downref: Normative reference to an Informational draft: draft-ietf-cdi-model (ref. '13') ** Downref: Normative reference to an Informational draft: draft-ietf-cdi-scenarios (ref. '14') -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Normative reference to a draft: ref. '16' == Outdated reference: A later version (-01) exists of draft-ietf-cdi-request-routing-reqs-00 -- Possible downref: Normative reference to a draft: ref. '17' == Outdated reference: A later version (-01) exists of draft-ietf-cdi-distribution-reqs-00 -- Possible downref: Normative reference to a draft: ref. '18' Summary: 16 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDI M. Green 3 Internet-Draft No Affiliation 4 Expires: November 30, 2002 B. Cain 5 Storigen Systems 6 G. Tomlinson 7 No Affiliation 8 M. Speer 9 Sun Microsystems 10 P. Rzewski 11 Inktomi 12 S. Thomas 13 TransNexus 14 June 2002 16 Content Internetworking Architectural Overview 17 draft-ietf-cdi-architecture-01.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at http:// 35 www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on November 30, 2002. 42 Copyright Notice 44 Copyright (C) The Internet Society (2002). All Rights Reserved. 46 Abstract 48 There is wide interest in the technology for interconnecting Content 49 Networks, variously called "Content Peering" or "Content 50 Internetworking". We present the general architecture and core 51 building blocks used in the internetworking of Content Networks. The 52 scope of this work is limited to external interconnections with 53 Content Networks and does not address internal mechanisms used within 54 Content Networks, which for the purpose of the document are 55 considered to be black boxes. This work establishes an abstract 56 architectural framework to be used in the development of protocols, 57 interfaces, and system models for standardized Content 58 Internetworking. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1 Change Log . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.2 Outstanding Issues . . . . . . . . . . . . . . . . . . . . 5 65 2. Content Internetworking System Architecture . . . . . . . 6 66 2.1 Conceptual View of Peered Content Networks . . . . . . . . 6 67 2.2 Content Internetworking Architectural Elements . . . . . . 8 68 3. Request-Routing Internetworking System . . . . . . . . . . 12 69 3.1 Request-Routing Overview . . . . . . . . . . . . . . . . . 12 70 3.2 Request-Routing . . . . . . . . . . . . . . . . . . . . . 14 71 3.3 System Requirements . . . . . . . . . . . . . . . . . . . 14 72 3.4 Protocol Requirements . . . . . . . . . . . . . . . . . . 15 73 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 3.6 Request-Routing Problems to Solve . . . . . . . . . . . . 16 75 4. Distribution Internetworking System . . . . . . . . . . . 18 76 4.1 Distribution Overview . . . . . . . . . . . . . . . . . . 18 77 4.2 Distribution Models . . . . . . . . . . . . . . . . . . . 20 78 4.3 Distribution Components . . . . . . . . . . . . . . . . . 21 79 4.4 Distribution System Requirements . . . . . . . . . . . . . 21 80 4.4.1 Replication Requirements . . . . . . . . . . . . . . . . . 21 81 4.4.2 Signaling Requirements . . . . . . . . . . . . . . . . . . 22 82 4.4.3 Advertising Requirements . . . . . . . . . . . . . . . . . 22 83 4.5 Protocol Requirements . . . . . . . . . . . . . . . . . . 23 84 4.6 Distribution Problems to Solve . . . . . . . . . . . . . . 23 85 4.6.1 General Problems . . . . . . . . . . . . . . . . . . . . . 23 86 4.6.2 Replication Problems . . . . . . . . . . . . . . . . . . . 23 87 4.6.3 Signaling Problems . . . . . . . . . . . . . . . . . . . . 24 88 4.6.4 Advertising Problems . . . . . . . . . . . . . . . . . . . 24 89 5. Accounting Internetworking System . . . . . . . . . . . . 25 90 5.1 Accounting Overview . . . . . . . . . . . . . . . . . . . 25 91 5.2 Accounting System Requirements . . . . . . . . . . . . . . 27 92 5.3 Protocol Requirements . . . . . . . . . . . . . . . . . . 27 93 6. Security Considerations . . . . . . . . . . . . . . . . . 28 94 6.1 Threats to Content Networking . . . . . . . . . . . . . . 28 95 6.1.1 Threats to the CLIENT . . . . . . . . . . . . . . . . . . 28 96 6.1.1.1 Defeat of CLIENT's Security Settings . . . . . . . . . . . 28 97 6.1.1.2 Delivery of Bad Accounting Information . . . . . . . . . . 28 98 6.1.1.3 Delivery of Bad Content . . . . . . . . . . . . . . . . . 29 99 6.1.1.4 Denial of Service . . . . . . . . . . . . . . . . . . . . 29 100 6.1.1.5 Exposure of Private Information . . . . . . . . . . . . . 29 101 6.1.1.6 Substitution of Security Parameters . . . . . . . . . . . 29 102 6.1.1.7 Substitution of Security Policies . . . . . . . . . . . . 29 103 6.1.2 Threats to the PUBLISHER . . . . . . . . . . . . . . . . . 29 104 6.1.2.1 Delivery of Bad Accounting Information . . . . . . . . . . 30 105 6.1.2.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 30 106 6.1.2.3 Substitution of Security Parameters . . . . . . . . . . . 30 107 6.1.2.4 Substitution of Security Policies . . . . . . . . . . . . 30 108 6.1.3 Threats to a CN . . . . . . . . . . . . . . . . . . . . . 30 109 6.1.3.1 Bad Accounting Information . . . . . . . . . . . . . . . . 30 110 6.1.3.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 30 111 6.1.3.3 Transitive Threats . . . . . . . . . . . . . . . . . . . . 31 112 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32 113 References . . . . . . . . . . . . . . . . . . . . . . . . 33 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 34 115 Full Copyright Statement . . . . . . . . . . . . . . . . . 36 117 1. Introduction 119 Terms in ALL CAPS, except those qualified with explicit citations are 120 defined in [13]. 122 This memo describes the overall architectural structure and the 123 fundamental building blocks used in the composition of Content 124 Internetworking. Consult [13] for the system model, and vocabulary 125 used in, this application domain. A key requirement of the 126 architecture itself is that it be able to address each of the Content 127 Internetworking scenarios enumerated in [14] . The scope of this 128 work is limited to external interconnections between Content Networks 129 (CN) (i.e. INTER-CN) and does not address internal mechanisms used 130 within Content Networks (i.e. INTRA-CN), which for the purposes of 131 the document are considered to be black boxes. This work is intended 132 to establish an abstract architectural framework to be used in the 133 development of protocols, interfaces and system models for 134 standardized, interoperable peering among Content Networks. 136 We first present the architecture as an abstract system. Then we 137 develop a more concrete system architecture. For each core 138 architectural element, we first present the structure of the element 139 followed by system requirements. Protocol requirements for 140 individual core elements are presented in accompanying works 141 [17][18][15]. The assumptions and scenarios constraining the 142 architecture is explained in [13] . We intend that the architecture 143 should support a wide variety of business models. 145 At the core of Content Internetworking are three principal 146 architectural elements that constitute the building blocks of the 147 Content Internetworking system. These elements are the REQUEST- 148 ROUTING INTERNETWORKING SYSTEM, DISTRIBUTION INTERNETWORKING SYSTEM, 149 and ACCOUNTING INTERNETWORKING SYSTEM. Collectively, they control 150 selection of the delivery Content Network, content distribution 151 between peering Content Networks, and usage accounting, including 152 billing settlement among the peering Content Networks. 154 This work takes into consideration relevant IETF RFCs and IETF works- 155 in-progress. In particular, it is mindful of the end-to-end nature 156 [6][10] of the Internet, and the taxonomy of web replication and 157 caching [11]. 159 1.1 Change Log 161 1. First pass at integration of the terms from the latest models 162 draft [13]. 164 2. New Editor of document -- Michael Speer (Sun Microsystems). 166 1.2 Outstanding Issues 168 1. Need to complete integration of [13], and [17], [18], and [15]. 170 2. Need to address the open and outstanding questions. 172 2. Content Internetworking System Architecture 174 2.1 Conceptual View of Peered Content Networks 176 Before developing the system architecture, a conceptual view of 177 peered CNs is presented to frame the problem space. CNs are 178 comprised principally of four core system elements [13], the REQUEST- 179 ROUTING SYSTEM, the DISTRIBUTION SYSTEM, the ACCOUNTING SYSTEM, and 180 SURROGATES. In order for CNs to peer with one another, it is 181 necessary to interconnect several of the core system elements of 182 individual CNs. The interconnection of CN core system elements 183 occurs through network elements called Content Internetworking 184 Gateways (CIG). Namely, the CN core system elements that need to be 185 interconnected are the REQUEST-ROUTING SYSTEM, the DISTRIBUTION 186 SYSTEM, and the ACCOUNTING SYSTEM. 188 Figure 1 contains a conceptual peered Content Networks diagram. 190 +---------------+ +---------------+ 191 | CN A | | CN B | 192 |...............| +---------+ +---------+ |.......... ....+ 193 |REQUEST-ROUTING|<=>| |<=>| |<=>|REQUEST-ROUTING| 194 |...............| | | | | |...............| 195 | DISTRIBUTION |<=>| CIG |<=>| CIG |<=>| DISTRIBUTION | 196 |...............| | | | | |...............| 197 | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING | 198 |---------------| +---------+ +---------+ +---------------+ 199 | ^ \^ \^ \^ ^/ ^/ ^/ | ^ 200 v | \\ \\ \\ // // // v | 201 +---------------+ \\ \\ \\ // // // +---------------+ 202 | SURROGATEs | \\ v\ v\ /v /v // | SURROGATEs | 203 +---------------+ \\+---------+// +---------------+ 204 ^ | v| |v ^ | 205 | | | | | | 206 | | | CIG | | | 207 | | | | | | 208 | | | | | | 209 | | +---------+ | | 210 | | ^| ^| ^| | | 211 | | || || || | | 212 | | |v |v |v | | 213 | | +------------- -+ | | 214 | | | CN C | | | 215 | | |...............| | | 216 | | |REQUEST-ROUTING| | | 217 | | |...............| | | 218 \ \ | DISTRIBUTION | / / 219 \ \ |...............| / / 220 \ \ | ACCOUNTING | / / 221 \ \ |---------------| / / 222 \ \ | ^ / / 223 \ \ v | / / 224 \ \ +---------------+ / / 225 \ \ | SURROGATEs | / / 226 \ \ +---------------+ / / 227 \ \ | ^ / / 228 \ \ | | / / 229 \ \ v | / / 230 \ \ +---------+ / / 231 \ \--->| CLIENTs |---/ / 232 \-----| |<---/ 233 +---------+ 235 CIG = Content Internetworking Gateway 236 Figure 1 Conceptual View of Peered Content Networks 238 This conceptual view illustrates the peering of three Content 239 Networks; CN A, CN B, and CN C. The CNs are peered through 240 interconnection at Content Internetworking Gateways. The result is 241 presented as a virtual CN to CLIENTs for the DELIVERY of CONTENT by 242 the aggregated set of SURROGATES. 244 Note: 245 Not all Content Networks contain the complete set of core 246 elements. For these Content Networks, peering will be done with 247 only the core elements they do contain. 249 2.2 Content Internetworking Architectural Elements 251 The system architecture revolves around the general premise that 252 individual Content Networks are wholly contained within an 253 administrative domain [3] that is composed of either autonomous 254 systems [1] (physical networks) or overlay networks (virtual 255 networks). For the purpose of this memo, an overlay network is 256 defined as a set of connected CN network elements layered onto 257 existing underlying networks, and present the result as a virtual 258 application layer to both CLIENTs and ORIGINs. The system 259 architecture for CN peering accommodates this premise by assuring 260 that the information and controls are available for inter-CN-domain 261 administration . Content Internetworking involves the 262 interconnection of the individual CN administrative domains through 263 gateway protocols and mechanisms loosely modeled after BGP [5]. 265 The system architecture depends on the following assumptions: 267 1. The URI [8] name space is the basis of PUBLISHER object 268 identifiers. 270 2. PUBLISHERs delegate authority of their object URI name space 271 being distributed by peering CNs to the REQUEST-ROUTING 272 INTERNETWORKING SYSTEM. 274 3. Peering CNs use a common convention for encoding CN metadata into 275 the URI name space. 277 Figure 2 contains a system architecture diagram of the core elements 278 involved in Content Internetworking. 280 +---------------+ 1 281 /-------------|REQUEST-ROUTING|<----\ 282 / 4 |INTERNETWORKING| 7 | 283 / /------------->| SYSTEM* |<-\ | 284 / / +---------------+ | | 285 / / ^ | | 286 / / |3 | | 287 / / | | | 288 / / +---------------+ | | 289 5| | | DISTRIBUTION | 2| | 290 V | __|INTERNETWORKING|<-\ | 291 +--------+ 6 +-----------+ 3 / | SYSTEM* |\ | +--------+ 292 | |<---| |<-/ +---------------+ | \\_| | 293 | CLIENT | | SURROGATE | | \_ | ORIGIN | 294 | |--->| |-\ +---------------+ | /-->| | 295 +--------+ +-----------+ \ 7 | ACCOUNTING |--// 7 +--------+ 296 \->|INTERNETWORKING|--/ 297 | SYSTEM* |--\ +--------+ 298 +---------------+ \ 7| BILLING| 299 \->| ORG. | 300 | | 301 +--------+ 303 Note: * represents core elements of Content Internetworking 305 Figure 2 System Architecture Elements of a Content Internetworking 306 System 308 The System Architecture is comprised of 7 major elements, 3 of which 309 constitute the Content Internetworking system itself. The peering 310 elements are REQUEST-ROUTING INTERNETWORKING SYSTEM, DISTRIBUTION 311 INTERNETWORKING SYSTEM, and ACCOUNTING INTERNETWORKING SYSTEM. 312 Correspondingly, the system architecture is a system of systems: 314 1. The ORIGIN delegates its URI name space for objects to be 315 distributed and delivered by the peering CNs to the REQUEST- 316 ROUTING INTERNETWORKING SYSTEM. 318 2. The ORIGIN INJECTS CONTENT that is to be distributed and 319 delivered by the peering CNs into the DISTRIBUTION 320 INTERNETWORKING SYSTEM. 322 Note: 323 CONTENT which is to be pre-populated (pushed) within the 324 peering CNs is pro-actively injected, while CONTENT which is 325 to be pulled on demand is injected at the time the object is 326 being requested for DELIVERY. 328 3. The DISTRIBUTION INTERNETWORKING SYSTEM moves content between CN 329 DISTRIBUTION SYSTEMs. Additionally this system interacts with 330 the REQUEST-ROUTING INTERNETWORKING SYSTEM via feedback 331 ADVERTISEMENTs to assist in the peered CN selection process for 332 CLIENT requests. 334 4. The CLIENT requests CONTENT from what it perceives to be the 335 ORIGIN, however due to URI name space delegation, the request is 336 actually made to the REQUEST-ROUTING INTERNETWORKING SYSTEM. 338 Note: 339 The request routing function may be implied by an in-path 340 network element such as caching proxy, which is typical for a 341 Access Content Network. In this case, request routing is 342 optimized to a null function, since the CLIENT is a priori 343 mapped to the SURROGATE. 345 5. The REQUEST-ROUTING INTERNETWORKING SYSTEM routes the request to 346 a suitable SURROGATE in a peering CN. REQUEST-ROUTING 347 INTERNETWORKING SYSTEMs interact with one another via feedback 348 ADVERTISEMENTs in order to keep request-routing tables current. 350 6. The selected SURROGATE delivers the requested content to the 351 CLIENT. Additionally, the SURROGATE sends accounting information 352 for delivered content to the ACCOUNTING INTERNETWORKING SYSTEM. 354 7. The ACCOUNTING INTERNETWORKING SYSTEM aggregates and distills the 355 accounting information into statistics and content detail records 356 for use by the ORIGIN and BILLING ORGANIZATION. Statistics are 357 also used as feedback to the REQUEST-ROUTING INTERNETWORKING 358 SYSTEM. 360 8. The BILLING ORGANIZATION uses the content detail records to 361 settle with each of the parties involved in the content 362 distribution and delivery process. 364 This process has been described in its simplest form in order to 365 present the Content Internetworking architecture in the most abstract 366 way possible. In practice, this process is more complex when applied 367 to policies, business models and service level agreements that span 368 multiple peering Content Networks. The orthogonal core peering 369 systems are discussed in greater depth in Section 3, Section 4 and 370 Section 5 respectively. 372 Note: 373 Figure 2 simplifies the presentation of the core Content 374 Internetworking elements as single boxes, when in fact they 375 represent a collection of CIGs and interconnected individual CN 376 core system elements. This has been done to introduce the system 377 architecture at its meta level. 379 The system architecture does not impose any administrative domain [3] 380 restrictions on the core peering elements (REQUEST-ROUTING 381 INTERNETWORKING SYSTEM, DISTRIBUTION INTERNETWORKING SYSTEM and 382 ACCOUNTING INTERNETWORKING SYSTEM). The only requirement is that 383 they be authorized by the principal parties (ORIGIN and peering CNs) 384 to act in their behalf. Thus, it is possible for each of the core 385 elements to be provided by a different organization. 387 3. Request-Routing Internetworking System 389 The REQUEST-ROUTING INTERNETWORKING SYSTEM represents the request- 390 routing function of the Content Internetworking system. It is 391 responsible for routing CLIENT requests to an appropriate peered CN 392 for the delivery of content. 394 Note: 395 When the DISTRIBUTION INTERNETWORKING SYSTEM and/or the ACCOUNTING 396 INTERNETWORKING SYSTEM is present, it is highly desirable to 397 utilize content location information within the peered CNs and/or 398 system load information in the selection of appropriate peered CNs 399 in the routing of requests. 401 3.1 Request-Routing Overview 403 REQUEST-ROUTING SYSTEMs route CLIENT requests to a suitable 404 SURROGATE, which is able to service a client request. Many request- 405 routing systems route users to the surrogate that is "closest" to the 406 requesting user, or to the "least loaded" surrogate. However, the 407 only requirement of the request-routing system is that it route users 408 to a surrogate that can serve the requested content. 410 REQUEST-ROUTING INTERNETWORKING is the interconnection of two or more 411 REQUEST-ROUTING SYSTEMs so as to increase the number of REACHABLE 412 SURROGATEs for at least one of the interconnected systems. 414 In order for a PUBLISHER's CONTENT to be delivered by multiple 415 peering CNs, it is necessary to federate each Content Network 416 REQUEST-ROUTING SYSTEM under the URI name space of the PUBLISHER 417 object. This federation is accomplished by first delegating 418 authority of the PUBLISHER URI name space to an AUTHORITATIVE 419 REQUEST-ROUTING SYSTEM. The AUTHORITATIVE REQUEST-ROUTING SYSTEM 420 subsequently splices each peering Content Network REQUEST-ROUTING 421 SYSTEM into this URI name space and transitively delegates URI name 422 space authority to them for their participation in request-routing. 423 Figure 3 is a diagram of the entities involved in the REQUEST-ROUTING 424 INTERNETWORKING SYSTEM. 426 Note: 427 For the null request routing case (in path caching proxy present), 428 the caching proxy acts as the SURROGATE. In this case, the 429 SURROGATE performs the request routing via its pre-established 430 proxy relationship with the CLIENT and is implicitly the 431 terminating level of request routing. In essence, the SURROGATE 432 is federated into the URI namespace without the need to 433 communicate with the AUTHORITATIVE REQUEST-ROUTING SYSTEM. 435 +---------------+ 436 | CLIENT | 437 +---------------+ 438 | 439 (Request-Routing Tree Root) +---------------+ 440 | AUTHORITATIVE | 441 |REQUEST-ROUTING| 442 | SYSTEM | 443 +---------------+ 444 | | INTER-CN Request-Routing 445 /----------------/ \-----------------\ 446 | | 447 (1st Level) +---------------+ +---------------+ 448 .........|REQUEST-ROUTING|.......... .........|REQUEST-ROUTING|........ 449 . CN A | CIG | . . CN B | CIG | . 450 . +---------------+ . . +---------------+ . 451 . | . . | . 452 . +---------------+ . . +---------------+ . 453 . |REQUEST-ROUTING| . . |REQUEST-ROUTING| . 454 . | SYSTEM | . . | SYSTEM | . 455 . +---------------+ . . +---------------+ . 456 . | | . . | | . 457 . /---/ \-------\ . . /-----/ \----\ . 458 . | | . . | | . 459 . +---------------+ | . . | | . 460 . |REQUEST-ROUTING| +------------+ . . +-----------+ +-----------+ . 461 ..| CIG |.| SURROGATEs |.. ..| SURROGATE |....| SURROGATES| . 462 +---------------+ +------------+ +-----------+ +-----------+ 463 | INTER-CN Recursive Request-Routing 464 \------\ 465 | 466 (2nd Level) +---------------+ 467 .........|REQUEST-ROUTING|.......... 468 . CN C | CIG | . 469 . +---------------+ . 470 . | . 471 . +---------------+ . 472 . |REQUEST-ROUTING| . 473 . | SYSTEM | . 474 . +---------------+ . 475 . | | . 476 . /----/ \-----\ . 477 . | | . 478 . +-----------+ +------------+ . 479 ..| SURROGATE |....| SURROGATEs |... 480 +-----------+ +------------+ 482 Figure 3 REQUEST-ROUTING INTERNETWORKING SYSTEM Architecture 484 The REQUEST-ROUTING INTERNETWORKING SYSTEM is hierarchical in nature. 485 There exists exactly one request-routing tree for each PUBLISHER URI. 486 The AUTHORITATIVE REQUEST-ROUTING SYSTEM is the root of the request- 487 routing tree. There may be only one AUTHORITATIVE REQUEST-ROUTING 488 SYSTEM for a URI request-routing tree. Subordinate to the 489 AUTHORITATIVE REQUEST-ROUTING SYSTEM are the REQUEST-ROUTING SYSTEMs 490 of the first level peering CNs. There may exist recursive 491 subordinate REQUEST-ROUTING SYSTEMs of additional level peering CNs. 493 Note: 494 A PUBLISHER object may have more than one URI associated with it 495 and therefore be present in more than one request-routing tree. 497 3.2 Request-Routing 499 The actual "routing" of a client request is through REQUEST-ROUTING 500 CIGs. The AUTHORITATIVE REQUEST-ROUTING CIG receives the CLIENT 501 request and forwards the REQUEST to an appropriate DISTRIBUTING CN. 502 This process of INTER-CN request-routing may occur multiple times in 503 a recursive manner between REQUEST-ROUTING CIGs until the REQUEST- 504 ROUTING SYSTEM arrives at an appropriate DISTRIBUTING CN to deliver 505 the content. 507 Note: 508 The Client request may be for resolution of a URI component and 509 not the content of the URI itself. This is the case when DNS is 510 being utilized in the request-routing process to resolve the URI 511 server component. 513 Request-Routing systems explicitly peer but do not have "interior" 514 knowledge of surrogates from other CNs. Each CN operates its 515 internal request-routing system. In this manner, request-routing 516 systems peer very much like IP network layer peering. 518 3.3 System Requirements 520 We assume that there is a peering relationship between REQUEST- 521 ROUTING CIGs. This peering relationship at a minimum must exchange a 522 set of CLIENT IP addresses that can be serviced, and a set of 523 information about the DISTRIBUTION SYSTEMs, for which they are 524 performing request-routing. 526 Request-Routing Requirements 528 1. Use of a URI name space based request-routing mechanism. The 529 request-routing mechanism is allowed to use as much of the URI 530 name space as it needs to select the proper SURROGATE. For 531 example, DNS based mechanisms utilize only the host subcomponent, 532 while content aware mechanisms utilize use multiple components. 534 2. Normalized canonical URI name space structure for peered CN 535 distribution of PUBLISHER objects. The default in the absence of 536 encoded meta data is the standard components as defined by [8]. 537 Encoded meta data must conform to the syntactical grammar defined 538 in [7] . 540 3. Single AUTHORITATIVE REQUEST-ROUTING SYSTEM for PUBLISHER object 541 URI name space. 543 4. Assure that the request-routing tree remains a tree -- i.e., has 544 no cycles. 546 5. Assure that adjacent request-routing systems from different 547 administrative domains (different CNs) use a compatible request- 548 routing mechanism. 550 6. Assure that adjacent request-routing systems from different 551 administrative domains (different CNs) agree to forward requests 552 for the CONTENT in question. 554 Editor Note: 555 System requirements being generated in the request-routing 556 peering protocol design team have not yet been reconciled and 557 integrated into this document.] 559 3.4 Protocol Requirements 561 The REQUEST-ROUTING INTERNETWORKING system's protocol has a complete 562 set of requirements that it must implement to solve a variety of 563 internetworking problems to enable REQUEST-ROUTING systems to peer 564 each other. 566 Some of the internetworking problems that the protocol must address 567 include: 569 1. Satisfying the need to interconnect a variety of request-routing 570 system types. 572 2. Satisfying the need to exchange content and associated meta-data. 574 3. Satisfying the need to exchange attributes and policies 575 assoicated with given pieces of content. 577 For a complete of set of requirements that the Request-Routing 578 Internetworking protocol needs to satisfy, consult [17]. 580 3.5 Examples 582 Consult [16] for in-depth information on known request-routing 583 systems. 585 3.6 Request-Routing Problems to Solve 587 Editor Note: 588 This section is being preserved until it has been determined that 589 these issues have been addressed in the request-routing peering 590 protocol requirements draft.] 592 Specific problems in request-routing needing further investigation 593 include: 595 1. What is the aggregated granularity of CLIENT IP address being 596 serviced by a peering CN's DISTRIBUTION SYSTEM? 598 2. How do DNS request-routing systems forward a request? If a given 599 CN is peered with many other CNs, what are the criteria that 600 forwards a request to another CN? 602 3. How do content-aware request-routing systems forward a request? 603 If a given CN is peered with many other CNs, what are the 604 criteria that forwards a request to another CN? 606 4. What are the merits of designing a generalized content routing 607 protocol, rather than relying on request-routing mechanisms. 609 5. What is the normalized canonical URI name space for request- 610 routing? Because request-routing is federated across multiple 611 CNs, it is necessary to have agreed upon standards for the 612 encoding of meta data in URIs. There are many potential 613 elements, which may be encoded. Some of these elements are: 614 authoritative agent domain, publisher domain, content type, 615 content length, etc. 617 6. How are policies communicated between the REQUEST-ROUTING SYSTEM 618 and the DISTRIBUTION ADVERTISEMENT SYSTEM? A given CN may wish 619 to serve only a given content type or a particular set of users. 620 These types of policies must be communicated between CNs. 622 7. What are the request-routing protocols in DNS? When a request is 623 routed to a particular REQUEST-ROUTING CIG, a clear set of DNS 624 rules and policies must be followed in order to have a workable 625 and predictable system. 627 8. How do we protect the REQUEST-ROUTING SYSTEM against denial of 628 service attacks? 630 9. How do we select the appropriate peering CN for DELIVERY? 632 Note: 633 The selection process must to consider the distribution 634 policies involved in Section 4. Investigation into other 635 policy "work in progress" within the IETF is needed to 636 understand the relationship of policies developed within 637 Content Internetworking. 639 4. Distribution Internetworking System 641 The DISTRIBUTION INTERNETWORKING SYSTEM represents the content 642 distribution function of the CN peering system. It is responsible 643 for moving content from one DISTRIBUTION CIG to another DISTRIBUTION 644 CIG and for supplying content location information to the REQUEST- 645 ROUTING INTERNETWORKING SYSTEM. 647 4.1 Distribution Overview 649 One goal of the Content Internetworking system is to move content 650 closer to the CLIENT. Typically this is accomplished by copying 651 content from its ORIGIN to SURROGATEs. The SURROGATEs then have the 652 CONTENT available when it is requested by a CLIENT. Even with a 653 single PUBLISHER and single CN, the copying of CONTENT to a SURROGATE 654 may traverse a number of links, some in the PUBLISHER's network, some 655 in the CN's network, and some between those two networks. For 656 DISTRIBUTION INTERNETWORKING, we consider only the communication 657 "between" two networks, and ignore the mechanisms for copying CONTENT 658 within a network. 660 In the above example the last server on the content provider's 661 network in the path, and the first server on the CN's network in the 662 path, must contain DISTRIBUTION CIGs which communicate directly with 663 each other. The DISTRIBUTION CIGs could be located in the ORIGIN 664 server and the SURROGATE server. Thus in the simplest form the 665 ORIGIN server is in direct contact with the SURROGATE. However the 666 DISTRIBUTION CIG in the content provider's network could aggregate 667 content from multiple ORIGIN servers and the DISTRIBUTION CIG in the 668 CN's network could represent multiple SURROGATEs. These DISTRIBUTION 669 CIGs could then be co-located in an exchange facility. In fact, 670 given the common practice of independently managed IP peering co- 671 location exchange facilities for layer 3, there exists the distinct 672 opportunity to create similar exchanges for CIGs. 674 Figure 4 is a diagram of the entities involved in the DISTRIBUTION 675 INTERNETWORKING SYSTEM. 677 +--------+ 678 | ORIGIN | 679 +--------+ 680 | | INJECTION 681 /------------------/ \----------------\ 682 | | 683 +--------------+ +--------------+ 684 .........| DISTRIBUTION |........... ...........| DISTRIBUTION |...... 685 . CN A | CIG | . . CN B | CIG | . 686 . +--------------+ . . +--------------+ . 687 . | . . | . 688 . +--------------+ . . +--------------+ . 689 . | DISTRIBUTION | . . | DISTRIBUTION | . 690 . | SYSTEM | . . | SYSTEM | . 691 . +--------------+ . . +--------------+ . 692 . | | . . | | . 693 . /-----/ \-------\ . . /-----/ \----\ . 694 . | | . . | | . 695 . | +--------------+ . . +--------------+ | . 696 . +------------+ | DISTRIBUTION | . . | DISTRIBUTION | +----------+ . 697 ..| SURROGATEs |.| CIG |... ..| CIG |.|SURROGATEs|.. 698 +------------+ +--------------+ +--------------+ +----------+ 699 | | | | 700 | \-----------------/ | 701 \----------\ /-----------/ 702 | | INTER-CN DISTRIBUTION INTERNETWORKING 703 | | 704 +--------------+ 705 .........| DISTRIBUTION |........... 706 . CN C | CIG | . 707 . +--------------+ . 708 . | . 709 . +--------------+ . 710 . | DISTRIBUTION | . 711 . | SYSTEM | . 712 . +--------------+ . 713 . | | . 714 . /-----/ \-------\ . 715 . | | . 716 . | | . 717 . +-----------+ +------------+ . 718 ..| SURROGATE |.....| SURROGATEs |.. 719 +-----------+ +------------+ 721 Figure 4 DISTRIBUTION INTERNETWORKING SYSTEM Architecture 722 While Content Internetworking in general relates to interfacing with 723 CNs, there are two CN distribution peering relationships we expect to 724 be common; INTER-CN distribution peering and INJECTION peering. 725 INTER-CN distribution peering involves distributing CONTENT between 726 individual CNs in a inter-network of peered CNs. INJECTION peering 727 involves the publishing of CONTENT directly into CNs by ORIGINs. 729 4.2 Distribution Models 731 Replication ADVERTISEMENTs may take place in a model similar to the 732 way IP routing table updates are done between BGP routers. 733 DISTRIBUTION CIGs could take care of exterior content replication 734 between content providers and CNs, while at the same time performing 735 content replication interior to their networks in an independent 736 manner. If this model is used then the internal structure of the 737 networks is hidden and the only knowledge of other networks is the 738 locations of DISTRIBUTION CIGs. 740 Replication of content may take place using a push model, or a pull 741 model, or a combination of both. Use initiated replication, where 742 SURROGATEs, upon getting a cache miss, retrieve CONTENT from the 743 DISTRIBUTION SYSTEM, represents the pull model. ORIGIN initiated 744 replication of CONTENT to SURROGATEs represents the push model. 745 DISTRIBUTION CIGs may be located at various points in these models 746 depending on the topologies of the networks involved. 748 With Content Internetworking it may be desirable to replicate content 749 through a network, which has no internal SURROGATEs. For example add 750 a exchange network between the content provider network and the CN 751 network to the example above. The exchange network could have a 752 DISTRIBUTION CIG co-located with the content provider's DISTRIBUTION 753 CIG, which acts as a proxy for the CN. The exchange network could 754 also have a DISTRIBUTION CIG co-located with the CN's DISTRIBUTION 755 CIG, which acts as a proxy for the content provider. In a 756 consolidated example, the exchange network could have a single 757 DISTRIBUTION CIG that acts as a proxy for both the content provider 758 and the CN. 760 Replication of CONTINUOUS MEDIA that is not to be cached on 761 SURROGATEs, such as live streaming broadcasts, takes place in a 762 different model from content that is to be persistently stored. 763 Replication in this case, typically takes the form of splitting the 764 live streaming data at various points in the network. In Content 765 Internetworking, DISTRIBUTION CIGs may support CONTINUOUS MEDIA 766 splitting replication, as they likely provide ideal network topologic 767 points for application layer multicasting. 769 4.3 Distribution Components 771 The three main components of DISTRIBUTION INTERNETWORKING are 772 replication, signaling and advertising. 774 The first component of content distribution is replication. 775 Replication involves moving the content from an ORIGIN server to 776 SURROGATE servers. The immediate goal in CN peering is moving the 777 content between DISTRIBUTION CIGs. 779 The second component of content distribution is content signaling. 780 Content signaling is the propagation of content meta-data. This 781 meta-data may include such information such as the immediate 782 expiration of content or a change in the expiration time of CONTENT. 783 The immediate goal in signaling is exchanging signals between 784 DISTRIBUTION CIGs. 786 The third component of content distribution is content advertising. 787 Content providers must be able to advertise content that can be 788 distributed by CNs and its associated terms. It is important that 789 the advertising of content must be able to aggregate content 790 information. The immediate goal in advertising is exchanging 791 advertisements between DISTRIBUTION CIGs. 793 4.4 Distribution System Requirements 795 Replication systems must have a peering relationship. This peering 796 relationship must exchange sets of aggregated content and its meta- 797 data. Meta-data may change over time independently of the content 798 data and must be exchanged independently as well. 800 4.4.1 Replication Requirements 802 The specific requirements in content replication are: 804 1. A common protocol for the replication of content. 806 2. A common format for the actual content data in the protocol. 808 3. A common format for the content meta-data in the protocol. 810 4. Security mechanisms (see Section 6). 812 5. Scalable distribution of the content. 814 4.4.2 Signaling Requirements 816 The specific requirements in content signaling are: 818 1. Signals for (at least) "flush" and "expiration time update". 820 2. Security mechanisms (see Section 6). 822 3. Scalable distribution of the signals on a large scale. 824 Editor Note: 825 We have to start being quantitative about what we mean by 826 "large scale". Are we thinking in terms of the number of 827 content items, the number of networks, or the number of 828 signals? For each of those, how big is "large scale"? 830 4. Content location and serviced CLIENT IP aggregate address 831 exchanges with REQUEST-ROUTING CIGs. 833 4.4.3 Advertising Requirements 835 The specific requirements in CONTENT ADVERTISEMENT are: 837 1. A common protocol for the ADVERTISEMENT of CONTENT. 839 2. A common format for the actual ADVERTISEMENTs in the protocol. 841 Editor Note: 842 The following requirements need further discussion. As it 843 stands now, there isn't sufficient information to substantiate 844 them. 846 3. A well-known state machine. 848 4. Use of TCP or SCTP (because soft-state protocols will not scale). 850 5. Well-known error codes to diagnose protocols between different 851 networks. 853 6. Capability negotiation. 855 7. Ability to represent policy. 857 Editor Note: 858 System requirements being generated in the distribution 859 peering protocol design team have not yet been reconciled and 860 integrated into this document.] 862 4.5 Protocol Requirements 864 Consult [18] for distribution internetworking protocol requirements. 866 4.6 Distribution Problems to Solve 868 [Editor Note: 869 This section is being preserved until it has been determined that 870 these issues have been addressed in the distribution peering 871 protocol requirements draft.] 873 Some of the problems in distribution revolve around supporting both a 874 push model and a pull model for replication of content in that they 875 are not symmetric. The push model is used for pre-loading of content 876 and the pull model is used for on-demand fetching and pre-fetching of 877 content. These models are not symmetric in that the amount of 878 available resources in which to place the content on the target 879 server must be known. In the fetching cases the server that pulls 880 the content knows the available resources on the target server, 881 itself. In the pre-loading case the server that pushes the content 882 must find out the available resources from the target server before 883 pushing the data. 885 4.6.1 General Problems 887 General problems in distribution peering needing further 888 investigation include: 890 1. How would a single distribution peering protocol adequately 891 support replication, signaling and advertising? 893 2. Should a single distribution peering protocol be considered, 894 rather than separate protocols for each component? 896 3. How do we prevent looping of distribution updates? That is to 897 say, detect and stop propagating replication, signaling and 898 advertisement of events a DISTRIBUTION CIG has already issued. 899 Looping here has the possibility of becoming infinite, if not 900 bounded by the protocol(s). IP route updating and forwarding has 901 faced similar issues and has solved them. 903 4.6.2 Replication Problems 905 Specific problems in replication needing further investigation 906 include: 908 1. How do replication systems forward a request? 909 2. How do we keep pull based replication serviced within the 910 DISTRIBUTION CIGs in order to prevent it from inadvertently 911 bleeding out into REQUEST-ROUTING SYSTEM and potentially getting 912 into a recursive loop? 914 3. How are policies communicated between the replication systems? 916 4. What are the replication protocols? 918 5. Does replication only take place between CIGs? 920 4.6.3 Signaling Problems 922 Specific problems in content signaling needing further investigation 923 include: 925 1. How do we represent a content signal? 927 2. What content meta-data needs to be signaled? 929 3. How do we represent aggregates of meta-data in a concise and 930 compressed manner? 932 4. What protocol(s) should be used for content signals? 934 5. What is a scalable architecture for delivering content signals? 936 6. Do content signals need a virtual distribution system of their 937 own? 939 4.6.4 Advertising Problems 941 Specific problems in CONTENT ADVERTISEMENT needing further 942 investigation include: 944 1. How do we represent aggregates of content to be distributed in a 945 concise and compressed manner? 947 2. What protocol(s) should be used for the aggregation of this data? 949 3. What are the issues involved in the creation of CIG exchanges? 950 This is actually a broader question than just for distribution, 951 but needs to be considered for all forms of CIGs {REQUEST- 952 ROUTING, DISTRIBUTION, ACCOUNTING}. 954 5. Accounting Internetworking System 956 The ACCOUNTING INTERNETWORKING SYSTEM represents the accounting data 957 collection function of the Content Internetworking system. It is 958 responsible for moving accounting data from one ACCOUNTING CIG to 959 another ACCOUNTING CIG. 961 5.1 Accounting Overview 963 Content Internetworking must provide the ability for the content 964 provider to collect data regarding the delivery of their CONTENT by 965 the peered CNs. ACCOUNTING CIGs exchange the data collected by the 966 interior ACCOUNTING SYSTEMS. This interior data may be collected 967 from the SURROGATEs by ACCOUNTING CIGs using SNMP or FTP, for 968 example. ACCOUNTING CIGs may transfer the data to exterior 969 neighboring ACCOUNTING CIGs on request (push), in an asynchronous 970 manner (push), or a combination of both. Accounting data may also be 971 aggregated before it is transferred. 973 Figure 5 is a diagram of the entities involved in the ACCOUNTING 974 INTERNETWORKING SYSTEM. 976 +---------+ 977 | BILLING | +--------+ 978 | ORG. | | ORIGIN | 979 +---------+ +--------+ 980 BILLING | | ACCOUNTING INTERNETWORKING | | ORIGIN ACCOUNTING INTERNETWORKING 981 /-----/ \-----------------------|-|----\ 982 | /-----------------------------/ \----|-\ 983 | | | | 984 +--------------+ +--------------+ 985 .........| ACCOUNTING |........... ...........| ACCOUNTING |...... 986 . CN A | CIG | . . CN B | CIG | . 987 . +--------------+ . . +--------------+ . 988 . | . . | . 989 . +--------------+ . . +--------------+ . 990 . | ACCOUNTING | . . | ACCOUNTING | . 991 . | SYSTEM | . . | SYSTEM | . 992 . +--------------+ . . +--------------+ . 993 . | | . . | | . 994 . /-----/ \-------\ . . /-----/ \----\ . 995 . | | . . | | . 996 . | +--------------+ . . +--------------+ | . 997 . +------------+ | ACCOUNTING | . . | ACCOUNTING | +----------+ . 998 ..| SURROGATEs |.| CIG |... ..| CIG |.|SURROGATEs|.. 999 +------------+ +--------------+ +--------------+ +----------+ 1000 | | | | 1001 | \-----------------/ | 1002 \----------\ /-----------/ 1003 | | INTER-CN ACCOUNTING INTERNETWORKING 1004 | | 1005 +--------------+ 1006 .........| ACCOUNTING |........... 1007 . CN C | CIG | . 1008 . +--------------+ . 1009 . | . 1010 . +--------------+ . 1011 . | ACCOUNTING | . 1012 . | SYSTEM | . 1013 . +--------------+ . 1014 . | | . 1015 . /-----/ \-------\ . 1016 . | | . 1017 . | | . 1018 . +-----------+ +------------+ . 1019 ..| SURROGATE |.....| SURROGATEs |.. 1020 +-----------+ +------------+ 1022 Figure 5 ACCOUNTING Internetworking Ssystem Architecture 1024 There are three CN accounting peering relationships we expect to be 1025 common; INTER-CN accounting peering, BILLING ORGANIZATION accounting 1026 peering and ORIGIN accounting peering. INTER-CN accounting peering 1027 involves exchanging accounting information between individual CNs in 1028 a inter-network of peered CNs. BILLING ORGANIZATION peering involves 1029 exchanging to accounting information between CNs and a billing 1030 organization. ORIGIN accounting peering involves the exchanging of 1031 accounting information between CNs and ORIGINs. 1033 Note: 1034 It is not necessary for an ORIGIN to peer directly with multiple 1035 CNs in order to participate in Content Internetworking. ORIGINs 1036 participating in a single home CN will be indirectly peered by 1037 their home CN with the inter-network of CNs the home CN is a 1038 member of. Nor is it necessary to have a BILLING ORGANIZATION 1039 peer, since this function may also be provided by the home CN. 1040 However, ORIGINs that directly peer for ACCOUNTING may have access 1041 to greater accounting detail. Also, through the use of ACCOUNTING 1042 peering, 3rd party billing can be provided. 1044 5.2 Accounting System Requirements 1046 [Editor Note: 1047 System requirements being generated in the accounting peering 1048 protocol design team have not yet been reconciled and integrated 1049 into this document.] 1051 5.3 Protocol Requirements 1053 Consult [15] for accounting internetworking protocol requirements. 1055 6. Security Considerations 1057 Security concerns with respect to Content Internetworking can be 1058 generally categorized into trust within the system and protection of 1059 the system from threats. The trust model utilized with Content 1060 Internetworking is predicated largely on transitive trust between the 1061 ORIGIN, REQUEST-ROUTING INTERNETWORKING SYSTEM, DISTRIBUTION 1062 INTERNETWORKING SYSTEM, ACCOUNTING INTERNETWORKING SYSTEM and 1063 SURROGATES. Network elements within the Content Internetworking 1064 system are considered to be "insiders" and therefore trusted. 1066 6.1 Threats to Content Networking 1068 The following sections document key threats to CLIENTs, PUBLISHERs, 1069 and CNs. The threats are classified according to the party that they 1070 most directly harm, but, of course, a threat to any party is 1071 ultimately a threat to all. (For example, having a credit card 1072 number stolen may most directly affect a CLIENT; however, the 1073 resulting dissatisfaction and publicity will almost certainly cause 1074 some harm to the PUBLISHER and CN, even if the harm is only to those 1075 organizations' reputations.) 1077 6.1.1 Threats to the CLIENT 1079 6.1.1.1 Defeat of CLIENT's Security Settings 1081 Because the SURROGATE's location may differ from that of the ORIGIN, 1082 the use of a SURROGATE may inadvertently or maliciously defeat any 1083 location-based security settings employed by the CLIENT. And since 1084 the SURROGATE's location is generally transparent to the CLIENT, the 1085 CLIENT may be unaware that its protections are no longer in force. 1086 For example, a CN may relocate CONTENT from a Internet Explorer 1087 user's "Internet Web Content Zone" to that user's "Local Intranet 1088 Web Content Zone." If the relocation is visible to the Internet 1089 Explorer browser but otherwise invisible to the user, the browser may 1090 be employing less stringent security protections than the user is 1091 expecting for that CONTENT. (Note that this threat differs, at least 1092 in degree, from the substitution of security parameters threat below, 1093 as Web Content Zones can control whether or not, for example, the 1094 browser executes unsigned active content.) 1096 6.1.1.2 Delivery of Bad Accounting Information 1098 In the case of CONTENT with value, CLIENTs may be inappropriately 1099 charged for viewing content that they did not successfully access. 1100 Conversely, some PUBLISHERs may reward CLIENTs for viewing certain 1101 CONTENT (e.g. programs that "pay" users to surf the Web). Should a 1102 CN fail to deliver appropriate accounting information, the CLIENT may 1103 not receive appropriate credit for viewing the required CONTENT. 1105 6.1.1.3 Delivery of Bad Content 1107 A CN that does not deliver the appropriate CONTENT may provide the 1108 user misleading information (either maliciously or inadvertently). 1109 This threat can be manifested as a failure of either the DISTRIBUTION 1110 SYSTEM (inappropriate content delivered to appropriate SURROGATEs) or 1111 REQUEST-ROUTING SYSTEM (request routing to inappropriate SURROGATEs, 1112 even though they may have appropriate CONTENT), or both. A REQUEST- 1113 ROUTING SYSTEM may also fail by forwarding the CLIENT request when no 1114 forwarding is appropriate, or by failing to forward the CLIENT 1115 request when forwarding is appropriate. 1117 6.1.1.4 Denial of Service 1119 A CN that does not forward the CLIENT appropriately may deny the 1120 CLIENT access to CONTENT. 1122 6.1.1.5 Exposure of Private Information 1124 CNs may inadvertently or maliciously expose private information 1125 (passwords, buying patterns, page views, credit card numbers) as it 1126 transits from SURROGATEs to ORIGINs and/or PUBLISHERs. 1128 6.1.1.6 Substitution of Security Parameters 1130 If a SURROGATE does not duplicate completely the security facilities 1131 of the ORIGIN (e.g. encryption algorithms, key lengths, certificate 1132 authorities) CONTENT delivered through the SURROGATE may be less 1133 secure than the CLIENT expects. 1135 6.1.1.7 Substitution of Security Policies 1137 If a SURROGATE does not employ the same security policies and 1138 procedures as the ORIGIN, the CLIENT's private information may be 1139 treated with less care than the CLIENT expects. For example, the 1140 operator of a SURROGATE may not have as rigorous protection for the 1141 CLIENT's password as does the operator of the ORIGIN server. This 1142 threat may also manifest itself if the legal jurisdiction of the 1143 SURROGATE differs from that of the ORIGIN, should, for example, legal 1144 differences between the jurisdictions require or permit different 1145 treatment of the CLIENT's private information. 1147 6.1.2 Threats to the PUBLISHER 1148 6.1.2.1 Delivery of Bad Accounting Information 1150 If a CN does not deliver accurate accounting information, the 1151 PUBLISHER may be unable to charge CLIENTs for accessing CONTENT or it 1152 may reward CLIENTs inappropriately. Inaccurate accounting 1153 information may also cause a PUBLISHER to pay for services (e.g. 1154 content distribution) that were not actually rendered.) Invalid 1155 accounting information may also effect PUBLISHERs indirectly by, for 1156 example, undercounting the number of site visitors (and, thus, 1157 reducing the PUBLISHER's advertising revenue). 1159 6.1.2.2 Denial of Service 1161 A CN that does not distribute CONTENT appropriately may deny CLIENTs 1162 access to CONTENT. 1164 6.1.2.3 Substitution of Security Parameters 1166 If a SURROGATE does not duplicate completely the security services of 1167 the ORIGIN (e.g. encryption algorithms, key lengths, certificate 1168 authorities, client authentication) CONTENT stored on the SURROGATE 1169 may be less secure than the PUBLISHER prefers. 1171 6.1.2.4 Substitution of Security Policies 1173 If a SURROGATE does not employ the same security policies and 1174 procedures as the ORIGIN, the CONTENT may be treated with less care 1175 than the PUBLISHER expects. This threat may also manifest itself if 1176 the legal jurisdiction of the SURROGATE differs from that of the 1177 ORIGIN, should, for example, legal differences between the 1178 jurisdictions require or permit different treatment of the CONTENT. 1180 6.1.3 Threats to a CN 1182 6.1.3.1 Bad Accounting Information 1184 If a CN is unable to collect or receive accurate accounting 1185 information, it may be unable to collect compensation for its 1186 services from PUBLISHERs. 1188 6.1.3.2 Denial of Service 1190 Misuse of a CN may make that CN's facilities unavailable, or 1191 available only at reduced functionality, to legitimate customers or 1192 the CN provider itself. Denial of service attacks can be targeted at 1193 a CN's ACCOUNTING SYSTEM, DISTRIBUTION SYSTEM, or REQUEST-ROUTING 1194 SYSTEM. 1196 6.1.3.3 Transitive Threats 1198 To the extent that a CN acts as either a CLIENT or a PUBLISHER (such 1199 as, for example, in transitive implementations) such a CN may be 1200 exposed to any or all of the threats described above for both roles. 1202 7. Acknowledgements 1204 The authors would like to acknowledge the contributions and comments 1205 of Mark Day (Cisco), Fred Douglis (AT&T), Patrik Falstrom (Cisco), 1206 Don Gilletti (CacheFlow), Barron Housel (Cisco) John Martin (Network 1207 Appliance), Raj Nair (Cisco), Hilarie Orman (Novell), Doug Potter 1208 (Cisco), John Scharber (CacheFlow), Michael Speer (Sun), and Oliver 1209 Spatscheck (AT&T). 1211 References 1213 [1] Hawkinson, J. and T. Bates, "Guidelines for creation, 1214 selection, and registration of an Autonomous System (AS)", BCP 1215 6, March 1996, . 1217 [2] Postel, J., "Internet Protocol, DARPA Internet Program Protocol 1218 Specification", RFC 791, September 1981, . 1221 [3] Hares, S. and D. Katz, "Administrative Domains and Routing 1222 Domains A Model for Routing in the Internet", RFC 1136, 1223 December 1989, . 1225 [4] Postel, J., "Domain Name Structure and Delegation", RFC 1591, 1226 March 1994, . 1228 [5] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 1229 RFC 1771, March 1995, . 1232 [6] Carpenter, B., "Architectural Principles of the Internet", RFC 1233 1958, June 1996, . 1235 [7] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 1236 Protocol (RTSP)", RFC 2326, April 1998, . 1239 [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1240 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1241 1998, . 1243 [9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1244 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 1245 HTTP/1.1", RFC 2616, June 1999, . 1248 [10] Carpenter, B., "Internet Transparency", RFC 2775, February 1249 2000, . 1251 [11] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web 1252 Replication and Caching Taxonomy", RFC 3040, January 2001, 1253 . 1255 [12] Volbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, 1256 G., de Bruijn, B., de Latt, C., Holdrege, M. and D. Spence, 1257 "AAA Authorization Framework", RFC 2904, August 2000, . 1260 [13] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for 1261 Content Internetworking (CDI)", draft-ietf-cdi-model-02.txt 1262 (work in progress), May 2002, . 1265 [14] Day, M., Gilletti, D. and P. Rzewski, "Content Internetworking 1266 Scenarios", draft-ietf-cdi-scenarios-01.txt (work in progress), 1267 April 2002, . 1270 [15] Gilletti, D., Nair, R., Scharber, J., Guha, J. and D. Frascone, 1271 "Content Internetworking Authentication, Authorizaiton, and 1272 Accounting Requirements", draft-ietf-cdi-aaa-reqs-01.txt (work 1273 in progress), June 2002, . 1276 [16] Douglis, F., Chaudhri, I. and P. Rzewski, "Known Mechanisms For 1277 Content Internetworking", draft-douglis-cdi-known-mech-00.txt 1278 (work in progress), November 2001, . 1281 [17] Cain, B., Spatscheck, O., May, M. and A. Barbir, "Request- 1282 Routing Requirements for Content Internetworking", draft-ietf- 1283 cdi-request-routing-reqs-00.txt (work in progress), February 1284 2002, . 1287 [18] Amini, L., Thomas, S. and O. Spatscheck, "Requirements for 1288 Content Distribution Internetworking", draft-ietf-cdi- 1289 distribution-reqs-00.txt (work in progress), February 2002, 1290 . 1293 Authors' Addresses 1295 Mark Green 1296 No Affiliation 1298 EMail: reserved@pacbell.net 1299 Brad Cain 1300 Storigen Systems 1301 650 Suffolk Street 1302 Lowell, MA 01854 1303 US 1305 Phone: +1 978 323 4454 1306 EMail: bcain@storigen.com 1308 Gary Tomlinson 1309 No Affiliation 1311 EMail: gary@tomlinsongroup.net 1313 Michael F. Speer 1314 Sun Microsystems, Inc. 1315 4150 Network Circle 1316 UMPK17-103 1317 Santa Clara, CA 95054 1318 US 1320 Phone: +1 650 786 6368 1321 EMail: michael.speer@sun.com 1323 Phil Rzewski 1324 Inktomi 1325 4100 East Third Avenue 1326 MS FC1-4 1327 Foster City, CA 94404 1328 US 1330 Phone: +1 650 653 2487 1331 EMail: philr@intkomi.com 1333 Stephen Thomas 1334 TransNexus, Inc. 1335 430 Tenth Street NW 1336 Suite N204 1337 Atlanta, GA 30318 1338 US 1340 Phone: +1 404 872 4887 1341 EMail: stephen.thomas@transnexus.com 1343 Full Copyright Statement 1345 Copyright (C) The Internet Society (2002). All Rights Reserved. 1347 This document and translations of it may be copied and furnished to 1348 others, and derivative works that comment on or otherwise explain it 1349 or assist in its implementation may be prepared, copied, published 1350 and distributed, in whole or in part, without restriction of any 1351 kind, provided that the above copyright notice and this paragraph are 1352 included on all such copies and derivative works. However, this 1353 document itself may not be modified in any way, such as by removing 1354 the copyright notice or references to the Internet Society or other 1355 Internet organizations, except as needed for the purpose of 1356 developing Internet standards in which case the procedures for 1357 copyrights defined in the Internet Standards process must be 1358 followed, or as required to translate it into languages other than 1359 English. 1361 The limited permissions granted above are perpetual and will not be 1362 revoked by the Internet Society or its successors or assigns. 1364 This document and the information contained herein is provided on an 1365 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1366 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1367 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1368 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1369 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1371 Acknowledgement 1373 Funding for the RFC Editor function is currently provided by the 1374 Internet Society.