idnits 2.17.1 draft-ietf-cdi-architecture-00.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 58 instances of too long lines in the document, the longest one being 10 characters in excess of 72. 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 (February 22, 2002) is 8098 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 1188, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1197, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1218, 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') -- Possible downref: Normative reference to a draft: ref. '12' == Outdated reference: A later version (-09) exists of draft-day-cdnp-model-05 -- Possible downref: Normative reference to a draft: ref. '13' == Outdated reference: A later version (-05) exists of draft-day-cdnp-scenarios-03 -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-05) exists of draft-cain-cdnp-known-request-routing-01 -- Possible downref: Normative reference to a draft: ref. '16' -- No information found for draft-ietf-cain-request-routing-req - is the name correct? -- Possible downref: Normative reference to a draft: ref. '17' == Outdated reference: A later version (-02) exists of draft-amini-cdi-distribution-reqs-00 -- Possible downref: Normative reference to a draft: ref. '18' Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Green 2 Internet-Draft CacheFlow 3 Expires: August 22, 2002 B. Cain 4 Cereva Networks 5 G. Tomlinson 6 CacheFlow 7 S. Thomas 8 TransNexus 9 P. Rzewski 10 Inktomi 11 February 22, 2002 13 Content Internetworking Architectural Overview 14 draft-ietf-cdi-architecture-00.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 22, 2002. 39 Copyright Notice 41 Copyright (C) The Internet Society (2001). All Rights Reserved. 43 Abstract 45 There is wide interest in the technology for interconnecting Content 46 Networks, variously called "Content Peering" or "Content 47 Internetworking". We present the general architecture and core 48 building blocks used in the internetworking of Content Networks. 49 The scope of this work is limited to external interconnections with 50 Content Networks and does not address internal mechanisms used 51 within Content Networks, which for the purpose of the document are 52 considered to be black boxes. This work establishes an abstract 53 architectural framework to be used in the development of protocols, 54 interfaces, and system models for standardized Content 55 Internetworking. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Content Internetworking System Architecture . . . . . . . 5 61 2.1 Conceptual View of Peered Content Networks . . . . . . . . 5 62 2.2 Content Internetworking Architectural Elements . . . . . . 7 63 3. Request-Routing Peering System . . . . . . . . . . . . . . 11 64 3.1 Request-Routing Overview . . . . . . . . . . . . . . . . . 11 65 3.2 Request Routing . . . . . . . . . . . . . . . . . . . . . 13 66 3.3 System Requirements . . . . . . . . . . . . . . . . . . . 13 67 3.4 Protocol Requirements . . . . . . . . . . . . . . . . . . 14 68 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 3.6 Request-Routing Problems to Solve . . . . . . . . . . . . 15 70 4. Distribution Peering System . . . . . . . . . . . . . . . 17 71 4.1 Distribution Overview . . . . . . . . . . . . . . . . . . 17 72 4.2 Distribution Models . . . . . . . . . . . . . . . . . . . 19 73 4.3 Distribution Components . . . . . . . . . . . . . . . . . 20 74 4.4 Distribution System Requirements . . . . . . . . . . . . . 20 75 4.4.1 Replication Requirements . . . . . . . . . . . . . . . . . 21 76 4.4.2 Signaling Requirements . . . . . . . . . . . . . . . . . . 21 77 4.4.3 Advertising Requirements . . . . . . . . . . . . . . . . . 21 78 4.5 Protocol Requirements . . . . . . . . . . . . . . . . . . 22 79 4.6 Distribution Problems to Solve . . . . . . . . . . . . . . 22 80 4.6.1 General Problems . . . . . . . . . . . . . . . . . . . . . 22 81 4.6.2 Replication Problems . . . . . . . . . . . . . . . . . . . 23 82 4.6.3 Signaling Problems . . . . . . . . . . . . . . . . . . . . 23 83 4.6.4 Advertising Problems . . . . . . . . . . . . . . . . . . . 23 84 5. Accounting Peering System . . . . . . . . . . . . . . . . 25 85 5.1 Accounting Overview . . . . . . . . . . . . . . . . . . . 25 86 5.2 Accounting System Requirements . . . . . . . . . . . . . . 27 87 5.3 Protocol Requirements . . . . . . . . . . . . . . . . . . 27 88 6. Security Considerations . . . . . . . . . . . . . . . . . 28 89 6.1 Threats to Content Internetworking . . . . . . . . . . . . 28 90 6.1.1 Threats to the CLIENT . . . . . . . . . . . . . . . . . . 28 91 6.1.1.1 Defeat of CLIENT's Security Settings . . . . . . . . . . . 28 92 6.1.1.2 Delivery of Bad Accounting Information . . . . . . . . . . 28 93 6.1.1.3 Delivery of Bad CONTENT . . . . . . . . . . . . . . . . . 29 94 6.1.1.4 Denial of Service . . . . . . . . . . . . . . . . . . . . 29 95 6.1.1.5 Exposure of Private Information . . . . . . . . . . . . . 29 96 6.1.1.6 Substitution of Security Parameters . . . . . . . . . . . 29 97 6.1.1.7 Substitution of Security Policies . . . . . . . . . . . . 29 98 6.1.2 Threats to the PUBLISHER . . . . . . . . . . . . . . . . . 29 99 6.1.2.1 Delivery of Bad Accounting Information . . . . . . . . . . 29 100 6.1.2.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 30 101 6.1.2.3 Substitution of Security Parameters . . . . . . . . . . . 30 102 6.1.2.4 Substitution of Security Policies . . . . . . . . . . . . 30 103 6.1.3 Threats to a CN . . . . . . . . . . . . . . . . . . . . . 30 104 6.1.3.1 Bad Accounting Information . . . . . . . . . . . . . . . . 30 105 6.1.3.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 30 106 6.1.3.3 Transitive Threats . . . . . . . . . . . . . . . . . . . . 31 107 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32 108 References . . . . . . . . . . . . . . . . . . . . . . . . 33 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 35 110 Full Copyright Statement . . . . . . . . . . . . . . . . . 36 112 1. Introduction 114 Terms in ALL CAPS, except those qualified with explicit citations 115 are defined in [13]. 117 This memo describes the overall architectural structure and the 118 fundamental building blocks used in the composition of Content 119 Internetworking. Consult [13] for the system model, and vocabulary 120 used in, this application domain. A key requirement of the 121 architecture itself is that it be able to address each of the 122 Content Internetworking scenarios enumerated in [14]. The scope of 123 this work is limited to external interconnections between Content 124 Networks (CN) (i.e. INTER-CN) and does not address internal 125 mechanisms used within Content Networks (i.e. INTRA-CN), which for 126 the purposes of the document are considered to be black boxes. This 127 work is intended to establish an abstract architectural framework to 128 be used in the development of protocols, interfaces and system 129 models for standardized, interoperable peering among Content 130 Networks. 132 We first present the architecture as an abstract system. Then we 133 develop a more concrete system architecture. For each core 134 architectural element, we first present the structure of the element 135 followed by system requirements. Protocol requirements for 136 individual core elements are presented in accompanying works 137 [17][18][15]. The assumptions and scenarios constraining the 138 architecture is explained in [14]. We intend that the architecture 139 should support a wide variety of business models. 141 At the core of Content Internetworking are three principal 142 architectural elements that constitute the building blocks of the 143 Content Internetworking system. These elements are the 144 REQUEST-ROUTING PEERING SYSTEM, DISTRIBUTION PEERING SYSTEM, and 145 ACCOUNTING PEERING SYSTEM. Collectively, they control selection of 146 the delivery Content Network, content distribution between peering 147 Content Networks, and usage accounting, including billing settlement 148 among the peering Content Networks. 150 This work takes into consideration relevant IETF RFCs and IETF 151 works-in-progress. In particular, it is mindful of the end-to-end 152 nature [6][10] of the Internet, the current taxonomy of web 153 replication and caching [11], and the accounting, authorization and 154 authentication framework [12]. 156 2. Content Internetworking System Architecture 158 2.1 Conceptual View of Peered Content Networks 160 Before developing the system architecture, a conceptual view of 161 peered CNs is presented to frame the problem space. CNs are 162 comprised principally of four core system elements [13], the 163 REQUEST-ROUTING SYSTEM, the DISTRIBUTION SYSTEM, the ACCOUNTING 164 SYSTEM, and SURROGATES. In order for CNs to peer with one another, 165 it is necessary to interconnect several of the core system elements 166 of individual CNs. The interconnection of CN core system elements 167 occurs through network elements called Content Peering Gateways 168 (CPG). Namely, the CN core system elements that need to be 169 interconnected are the REQUEST-ROUTING SYSTEM, the DISTRIBUTION 170 SYSTEM, and the ACCOUNTING SYSTEM. 172 Figure 1 contains a conceptual peered Content Networks diagram. 174 +---------------+ +---------------+ 175 | CN A | | CN B | 176 |...............| +---------+ +---------+ |.......... ....+ 177 |REQUEST-ROUTING|<=>| |<=>| |<=>|REQUEST-ROUTING| 178 |...............| | CONTENT | | CONTENT | |...............| 179 | DISTRIBUTION |<=>| PEERING |<=>| PEERING |<=>| DISTRIBUTION | 180 |...............| | GATEWAY | | GATEWAY | |...............| 181 | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING | 182 |---------------| +---------+ +---------+ +---------------+ 183 | ^ \^ \^ \^ ^/ ^/ ^/ | ^ 184 v | \\ \\ \\ // // // v | 185 +---------------+ \\ \\ \\ // // // +---------------+ 186 | SURROGATEs | \\ v\ v\ /v /v // | SURROGATEs | 187 +---------------+ \\+---------+// +---------------+ 188 ^ | v| |v ^ | 189 | | | CONTENT | | | 190 | | | PEERING | | | 191 | | | GATEWAY | | | 192 | | | | | | 193 | | +---------+ | | 194 | | ^| ^| ^| | | 195 | | || || || | | 196 | | |v |v |v | | 197 | | +------------- -+ | | 198 | | | CN C | | | 199 | | |...............| | | 200 | | |REQUEST-ROUTING| | | 201 | | |...............| | | 202 \ \ | DISTRIBUTION | / / 203 \ \ |...............| / / 204 \ \ | ACCOUNTING | / / 205 \ \ |---------------| / / 206 \ \ | ^ / / 207 \ \ v | / / 208 \ \ +---------------+ / / 209 \ \ | SURROGATEs | / / 210 \ \ +---------------+ / / 211 \ \ | ^ / / 212 \ \ | | / / 213 \ \ v | / / 214 \ \ +---------+ / / 215 \ \--->| CLIENTs |---/ / 216 \-----| |<---/ 217 +---------+ 219 Figure 1 Conceptual View of Peered Content Networks 220 This conceptual view illustrates the peering of three Content 221 Networks; CN A, CN B, and CN C. The CNs are peered through 222 interconnection at Content Peering Gateways. The result is 223 presented as a virtual CN to CLIENTs for the DELIVERY of CONTENT by 224 the aggregated set of SURROGATES. 226 Note: 227 Not all Content Networks contain the complete set of core 228 elements. For these Content Networks, peering will be done with 229 only the core elements they do contain. 231 2.2 Content Internetworking Architectural Elements 233 The system architecture revolves around the general premise that 234 individual Content Networks are wholly contained within an 235 administrative domain [3] that is composed of either autonomous 236 systems [1] (physical networks) or overlay networks (virtual 237 networks). For the purpose of this memo, an overlay network is 238 defined as a set of connected CN network elements layered onto 239 existing underlying networks, and present the result as a virtual 240 application layer to both CLIENTs and ORIGINs. The system 241 architecture for CN peering accommodates this premise by assuring 242 that the information and controls are available for inter-CN-domain 243 administration . Content Internetworking involves the 244 interconnection of the individual CN administrative domains through 245 gateway protocols and mechanisms loosely modeled after BGP [5]. 247 The system architecture depends on the following assumptions: 249 1. The URI [8] name space is the basis of PUBLISHER object 250 identifiers. 252 2. PUBLISHERs delegate authority of their object URI name space 253 being distributed by peering CNs to the REQUEST-ROUTING 254 PEERING SYSTEM. 256 3. Peering CNs use a common convention for encoding CN metadata 257 into the URI name space. 259 Figure 2 contains a system architecture diagram of the core elements 260 involved in Content Internetworking. 262 +---------------+ 1 263 /-------------|REQUEST-ROUTING|<----\ 264 / 4 | PEERING | 7 | 265 / /------------->| SYSTEM* |<-\ | 266 / / +---------------+ | | 267 / / ^ | | 268 / / |3 | | 269 / / | | | 270 / / +--------------+ | | 271 5| | | DISTRIBUTION | 2| | 272 V | __| PEERING |<-\ | 273 +--------+ 6 +-----------+ 3 / | SYSTEM* | |\ | +---------+ 274 | |<---| |<-/ +--------------+ | \ \_| | 275 | CLIENT | | SURROGATE | | \__| ORIGIN | 276 | |--->| |-\ +--------------+ | /-->| | 277 +--------+ +-----------+ \ 7 | ACCOUNTING |--// 7 +---------+ 278 \->| PEERING |--/ 279 | SYSTEM* |--\ +---------+ 280 +--------------+ \ 7 | BILLING | 281 \-->| ORG. | 282 | | 283 +---------+ 285 Note: * represents core elements of Content Internetworking 287 Figure 2 System Architecture Elements of a Content Internetworking 288 System 290 The System Architecture is comprised of 7 major elements, 3 of which 291 constitute the Content Internetworking system itself. The peering 292 elements are REQUEST-ROUTING PEERING SYSTEM, DISTRIBUTION PEERING 293 SYSTEM, and ACCOUNTING PEERING SYSTEM. Correspondingly, the system 294 architecture is a system of systems: 296 1. The ORIGIN delegates its URI name space for objects to be 297 distributed and delivered by the peering CNs to the 298 REQUEST-ROUTING PEERING SYSTEM. 300 2. The ORIGIN INJECTS CONTENT that is to be distributed and 301 delivered by the peering CNs into the DISTRIBUTION PEERING 302 SYSTEM. 304 Note: 305 CONTENT which is to be pre-populated (pushed) within the 306 peering CNs is pro-actively injected, while CONTENT which 307 is to be pulled on demand is injected at the time the 308 object is being requested for DELIVERY. 310 3. The DISTRIBUTION PEERING SYSTEM moves content between CN 311 DISTRIBUTION SYSTEMs. Additionally this system interacts with 312 the REQUEST-ROUTING PEERING SYSTEM via feedback 313 ADVERTISEMENTs to assist in the peered CN selection process 314 for CLIENT requests. 316 4. The CLIENT requests CONTENT from what it perceives to be the 317 ORIGIN, however due to URI name space delegation, the request 318 is actually made to the REQUEST-ROUTING PEERING SYSTEM. 320 Note: 321 The request routing function may be implied by an in-path 322 network element such as caching proxy, which is typical 323 for a Access Content Network. In this case, request 324 routing is optimized to a null function, since the CLIENT 325 is a priori mapped to the SURROGATE. 327 5. The REQUEST-ROUTING PEERING SYSTEM routes the request to a 328 suitable SURROGATE in a peering CN. REQUEST-ROUTING PEERING 329 SYSTEMs interact with one another via feedback ADVERTISEMENTs 330 in order to keep request-routing tables current. 332 6. The selected SURROGATE delivers the requested content to the 333 CLIENT. Additionally, the SURROGATE sends accounting 334 information for delivered content to the ACCOUNTING PEERING 335 SYSTEM. 337 7. The ACCOUNTING PEERING SYSTEM aggregates and distills the 338 accounting information into statistics and content detail 339 records for use by the ORIGIN and BILLING ORGANIZATION. 340 Statistics are also used as feedback to the REQUEST-ROUTING 341 PEERING SYSTEM. 343 8. The BILLING ORGANIZATION uses the content detail records to 344 settle with each of the parties involved in the content 345 distribution and delivery process. 347 This process has been described in its simplest form in order to 348 present the Content Internetworking architecture in the most 349 abstract way possible. In practice, this process is more complex 350 when applied to policies, business models and service level 351 agreements that span multiple peering Content Networks. The 352 orthogonal core peering systems are discussed in greater depth in 353 Section 3, Section 4 and Section 5 respectively. 355 Note: 356 Figure 2 simplifies the presentation of the core Content 357 Internetworking elements as single boxes, when in fact they 358 represent a collection of CPGs and interconnected individual CN 359 core system elements. This has been done to introduce the system 360 architecture at its meta level. 362 The system architecture does not impose any administrative domain 363 [3] restrictions on the core peering elements (REQUEST-ROUTING 364 PEERING SYSTEM, DISTRIBUTION PEERING SYSTEM and ACCOUNTING PEERING 365 SYSTEM). The only requirement is that they be authorized by the 366 principal parties (ORIGIN and peering CNs) to act in their behalf. 367 Thus, it is possible for each of the core elements to be provided by 368 a different organization. 370 3. Request-Routing Peering System 372 The REQUEST-ROUTING PEERING SYSTEM represents the request-routing 373 function of the Content Internetworking system. It is responsible 374 for routing CLIENT requests to an appropriate peered CN for the 375 delivery of content. 377 Note: 378 When the DISTRIBUTION PEERING SYSTEM and/or the ACCOUNTING 379 PEERING SYSTEM is present, it is highly desirable to utilize 380 content location information within the peered CNs and/or system 381 load information in the selection of appropriate peered CNs in 382 the routing of requests. 384 3.1 Request-Routing Overview 386 REQUEST-ROUTING SYSTEMs route CLIENT requests to a suitable 387 SURROGATE, which is able to service a client request. Many 388 request-routing systems route users to the surrogate that is 389 "closest" to the requesting user, or to the "least loaded" 390 surrogate. However, the only requirement of the request-routing 391 system is that it route users to a surrogate that can serve the 392 requested content. 394 REQUEST-ROUTING PEERING is the interconnection of two or more 395 REQUEST-ROUTING SYSTEMs so as to increase the number of REACHABLE 396 SURROGATEs for at least one of the interconnected systems. 398 In order for a PUBLISHER's CONTENT to be delivered by multiple 399 peering CNs, it is necessary to federate each Content Network 400 REQUEST-ROUTING SYSTEM under the URI name space of the PUBLISHER 401 object. This federation is accomplished by first delegating 402 authority of the PUBLISHER URI name space to an AUTHORITATIVE 403 REQUEST-ROUTING SYSTEM. The AUTHORITATIVE REQUEST-ROUTING SYSTEM 404 subsequently splices each peering Content Network REQUEST-ROUTING 405 SYSTEM into this URI name space and transitively delegates URI name 406 space authority to them for their participation in request-routing. 407 Figure 3 is a diagram of the entities involved in the 408 REQUEST-ROUTING PEERING SYSTEM. 410 Note: 411 For the null request routing case (in path caching proxy 412 present), the caching proxy acts as the SURROGATE. In this case, 413 the SURROGATE performs the request routing via its 414 pre-established proxy relationship with the CLIENT and is 415 implicitly the terminating level of request routing. In essence, 416 the SURROGATE is federated into the URI namespace without the 417 need to communicate with the AUTHORITATIVE REQUEST-ROUTING SYSTEM. 419 +---------------+ 420 | CLIENT | 421 +---------------+ 422 | 423 (Request-Routing Tree Root) +---------------+ 424 | AUTHORITATIVE | 425 |REQUEST-ROUTING| 426 | SYSTEM | 427 +---------------+ 428 | | INTER-CN Request-Routing 429 /----------------/ \-----------------\ 430 | | 431 (1st Level) +---------------+ +---------------+ 432 .........|REQUEST-ROUTING|.......... .........|REQUEST-ROUTING|......... 433 . CN A | CPG | . . CN B | CPG | . 434 . +---------------+ . . +---------------+ . 435 . | . . | . 436 . +---------------+ . . +---------------+ . 437 . |REQUEST-ROUTING| . . |REQUEST-ROUTING| . 438 . | SYSTEM | . . | SYSTEM | . 439 . +---------------+ . . +---------------+ . 440 . | | . . | | . 441 . /---/ \-------\ . . /-----/ \----\ . 442 . | | . . | | . 443 . +---------------+ | . . | | . 444 . |REQUEST-ROUTING| +------------+ . . +-----------+ +------------+ . 445 ..| CPG |.| SURROGATEs |.. ..| SURROGATE |....| SURROGATES |.. 446 +---------------+ +------------+ +-----------+ +------------+ 447 | INTER-CN Recursive Request-Routing 448 \------\ 449 | 450 (2nd Level) +---------------+ 451 .........|REQUEST-ROUTING|.......... 452 . CN C | CPG | . 453 . +---------------+ . 454 , | . 455 . +---------------+ . 456 . |REQUEST-ROUTING| . 457 . | SYSTEM | . 458 . +---------------+ . 459 . | | . 460 . /----/ \-----\ . 461 . | | . 462 . +-----------+ +------------+ . 463 ..| SURROGATE |....| SURROGATEs |... 464 +-----------+ +------------+ 466 Figure 3 REQUEST-ROUTING PEERING SYSTEM Architecture 467 The REQUEST-ROUTING PEERING SYSTEM is hierarchical in nature. There 468 exists exactly one request-routing tree for each PUBLISHER URI. The 469 AUTHORITATIVE REQUEST-ROUTING SYSTEM is the root of the 470 request-routing tree. There may be only one AUTHORITATIVE 471 REQUEST-ROUTING SYSTEM for a URI request-routing tree. Subordinate 472 to the AUTHORITATIVE REQUEST-ROUTING SYSTEM are the REQUEST-ROUTING 473 SYSTEMs of the first level peering CNs. There may exist recursive 474 subordinate REQUEST-ROUTING SYSTEMs of additional level peering CNs. 476 Note: 477 A PUBLISHER object may have more than one URI associated with it 478 and therefore be present in more than one request-routing tree. 480 3.2 Request Routing 482 The actual "routing" of a client request is through REQUEST-ROUTING 483 CPGs. The AUTHORITATIVE REQUEST-ROUTING CPG receives the CLIENT 484 request and forwards the REQUEST to an appropriate DISTRIBUTING CN. 485 This process of INTER-CN request-routing may occur multiple times in 486 a recursive manner between REQUEST-ROUTING CPGs until the 487 REQUEST-ROUTING SYSTEM arrives at an appropriate DISTRIBUTING CN to 488 deliver the content. 490 Note: 491 The Client request may be for resolution of a URI component and 492 not the content of the URI itself. This is the case when DNS is 493 being utilized in the request-routing process to resolve the URI 494 server component. 496 Request-Routing systems explicitly peer but do not have "interior" 497 knowledge of surrogates from other CNs. Each CN operates its 498 internal request-routing system. In this manner, request-routing 499 systems peer very much like IP network layer peering. 501 3.3 System Requirements 503 We assume that there is a peering relationship between 504 REQUEST-ROUTING CPGs. This peering relationship at a minimum must 505 exchange a set of CLIENT IP addresses that can be serviced, and a 506 set of information about the DISTRIBUTION SYSTEMs, for which they 507 are performing request-routing. 509 Request-Routing Requirements 511 1. Use of a URI name space based request-routing mechanism. The 512 request-routing mechanism is allowed to use as much of the URI 513 name space as it needs to select the proper SURROGATE. For 514 example, DNS based mechanisms utilize only the host 515 subcomponent, while content aware mechanisms utilize use 516 multiple components. 518 2. Normalized canonical URI name space structure for peered CN 519 distribution of PUBLISHER objects. The default in the absence 520 of encoded meta data is the standard components as defined by 521 [8]. Encoded meta data must conform to the syntactical grammar 522 defined in [7]. 524 3. Single AUTHORITATIVE REQUEST-ROUTING SYSTEM for PUBLISHER object 525 URI name space. 527 4. Assure that the request-routing tree remains a tree -- i.e., has 528 no cycles. 530 5. Assure that adjacent request-routing systems from different 531 administrative domains (different CNs) use a compatible 532 request-routing mechanism. 534 6. Assure that adjacent request-routing systems from different 535 administrative domains (different CNs) agree to forward requests 536 for the CONTENT in question. 538 7. 540 [Editor Note: 541 System requirements being generated in the request-routing 542 peering protocol design team have not yet been reconciled and 543 integrated into this document.] 545 3.4 Protocol Requirements 547 Consult [17] for request-routing peering protocol requirements. 549 3.5 Examples 551 Consult [16] for in-depth information on known request-routing 552 systems. 554 3.6 Request-Routing Problems to Solve 556 [Editor Note: 557 This section is being preserved until it has been determined that 558 these issues have been addressed in the request-routing peering 559 protocol requirements draft.] 561 Specific problems in request-routing needing further investigation 562 include: 564 1. What is the aggregated granularity of CLIENT IP address being 565 serviced by a peering CN's DISTRIBUTION SYSTEM? 567 2. How do DNS request-routing systems forward a request? If a 568 given CN is peered with many other CNs, what are the criteria 569 that forwards a request to another CN? 571 3. How do content-aware request-routing systems forward a request? 572 If a given CN is peered with many other CNs, what are the 573 criteria that forwards a request to another CN? 575 4. What are the merits of designing a generalized content routing 576 protocol, rather than relying on request-routing mechanisms. 578 5. What is the normalized canonical URI name space for 579 request-routing? Because request-routing is federated across 580 multiple CNs, it is necessary to have agreed upon standards for 581 the encoding of meta data in URIs. There are many potential 582 elements, which may be encoded. Some of these elements are: 583 authoritative agent domain, publisher domain, content type, 584 content length, etc. 586 6. How are policies communicated between the REQUEST-ROUTING SYSTEM 587 and the DISTRIBUTION ADVERTISEMENT SYSTEM? A given CN may wish 588 to serve only a given content type or a particular set of users. 589 These types of policies must be communicated between CNs. 591 7. What are the request-routing protocols in DNS? When a request is 592 routed to a particular REQUEST-ROUTING CPG, a clear set of DNS 593 rules and policies must be followed in order to have a workable 594 and predictable system. 596 8. How do we protect the REQUEST-ROUTING SYSTEM against denial of 597 service attacks? 599 9. How do we select the appropriate peering CN for DELIVERY? 601 The selection process must to consider the distribution 602 policies involved in Section 4. Investigation into other 603 policy "work in progress" within the IETF is needed to 604 understand the relationship of policies developed within 605 Content Internetworking. 607 4. Distribution Peering System 609 The DISTRIBUTION PEERING SYSTEM represents the content distribution 610 function of the CN peering system. It is responsible for moving 611 content from one DISTRIBUTION CPG to another DISTRIBUTION CPG and 612 for supplying content location information to the REQUEST-ROUTING 613 PEERING SYSTEM. 615 4.1 Distribution Overview 617 One goal of the Content Internetworking system is to move content 618 closer to the CLIENT. Typically this is accomplished by copying 619 content from its ORIGIN to SURROGATEs. The SURROGATEs then have the 620 CONTENT available when it is requested by a CLIENT. Even with a 621 single PUBLISHER and single CN, the copying of CONTENT to a 622 SURROGATE may traverse a number of links, some in the PUBLISHER's 623 network, some in the CN's network, and some between those two 624 networks. For DISTRIBUTION PEERING, we consider only the 625 communication "between" two networks, and ignore the mechanisms for 626 copying CONTENT within a network. 628 In the above example the last server on the content provider's 629 network in the path, and the first server on the CN's network in the 630 path, must contain DISTRIBUTION CPGs which communicate directly with 631 each other. The DISTRIBUTION CPGs could be located in the ORIGIN 632 server and the SURROGATE server. Thus in the simplest form the 633 ORIGIN server is in direct contact with the SURROGATE. However the 634 DISTRIBUTION CPG in the content provider's network could aggregate 635 content from multiple ORIGIN servers and the DISTRIBUTION CPG in the 636 CN's network could represent multiple SURROGATEs. These DISTRIBUTION 637 CPGs could then be co-located in an exchange facility. In fact, 638 given the common practice of independently managed IP peering 639 co-location exchange facilities for layer 3, there exists the 640 distinct opportunity to create similar exchanges for CPGs. 642 Figure 4 is a diagram of the entities involved in the DISTRIBUTION 643 PEERING SYSTEM. 645 +--------+ 646 | ORIGIN | 647 +--------+ 648 | | INJECTION 649 /------------------/ \----------------\ 650 | | 651 +--------------+ +--------------+ 652 .........| DISTRIBUTION |........... ...........| DISTRIBUTION |........ 653 . CN A | CPG | . . CN B | CPG | . 654 . +--------------+ . . +--------------+ . 655 . | . . | . 656 . +--------------+ . . +--------------+ . 657 . | DISTRIBUTION | . . | DISTRIBUTION | . 658 . | SYSTEM | . . | SYSTEM | . 659 . +--------------+ . . +--------------+ . 660 . | | . . | | . 661 . /-----/ \-------\ . . /-----/ \----\ . 662 . | | . . | | . 663 . | +--------------+ . . +--------------+ | . 664 . +------------+ | DISTRIBUTION | . . | DISTRIBUTION | +------------+ . 665 ..| SURROGATEs |.| CPG |... ..| CPG |.| SURROGATEs |.. 666 +------------+ +--------------+ +--------------+ +------------+ 667 | | | | 668 | \-----------------/ | 669 \----------\ /-----------/ 670 | | INTER-CN DISTRIBUTION PEERING 671 | | 672 +--------------+ 673 .........| DISTRIBUTION |........... 674 . CN C | CPG | . 675 . +--------------+ . 676 . | . 677 . +--------------+ . 678 . | DISTRIBUTION | . 679 . | SYSTEM | . 680 . +--------------+ . 681 . | | . 682 . /-----/ \-------\ . 683 . | | . 684 . | | . 685 . +-----------+ +------------+ . 686 ..| SURROGATE |.....| SURROGATEs |.. 687 +-----------+ +------------+ 689 Figure 4 DISTRIBUTION PEERING SYSTEM Architecture 690 While Content Internetworking in general relates to interfacing with 691 CNs, there are two CN distribution peering relationships we expect 692 to be common; INTER-CN distribution peering and INJECTION peering. 693 INTER-CN distribution peering involves distributing CONTENT between 694 individual CNs in a inter-network of peered CNs. INJECTION peering 695 involves the publishing of CONTENT directly into CNs by ORIGINs. 697 4.2 Distribution Models 699 Replication ADVERTISEMENTs may take place in a model similar to the 700 way IP routing table updates are done between BGP routers. 701 DISTRIBUTION CPGs could take care of exterior content replication 702 between content providers and CNs, while at the same time performing 703 content replication interior to their networks in an independent 704 manner. If this model is used then the internal structure of the 705 networks is hidden and the only knowledge of other networks is the 706 locations of DISTRIBUTION CPGs. 708 Replication of content may take place using a push model, or a pull 709 model, or a combination of both. Use initiated replication, where 710 SURROGATEs, upon getting a cache miss, retrieve CONTENT from the 711 DISTRIBUTION SYSTEM, represents the pull model. ORIGIN initiated 712 replication of CONTENT to SURROGATEs represents the push model. 713 DISTRIBUTION CPGs may be located at various points in these models 714 depending on the topologies of the networks involved. 716 With Content Internetworking it may be desirable to replicate 717 content through a network, which has no internal SURROGATEs. For 718 example add a exchange network between the content provider network 719 and the CN network to the example above. The exchange network could 720 have a DISTRIBUTION CPG co-located with the content provider's 721 DISTRIBUTION CPG, which acts as a proxy for the CN. The exchange 722 network could also have a DISTRIBUTION CPG co-located with the CN's 723 DISTRIBUTION CPG, which acts as a proxy for the content provider. In 724 a consolidated example, the exchange network could have a single 725 DISTRIBUTION CPG that acts as a proxy for both the content provider 726 and the CN. 728 Replication of CONTINUOUS MEDIA that is not to be cached on 729 SURROGATEs, such as live streaming broadcasts, takes place in a 730 different model from content that is to be persistently stored. 731 Replication in this case, typically takes the form of splitting the 732 live streaming data at various points in the network. In Content 733 Internetworking, DISTRIBUTION CPGs may support CONTINUOUS MEDIA 734 splitting replication, as they likely provide ideal network 735 topologic points for application layer multicasting. 737 4.3 Distribution Components 739 The three main components of DISTRIBUTION PEERING are replication, 740 signaling and advertising. 742 The first component of content distribution is replication. 743 Replication involves moving the content from an ORIGIN server to 744 SURROGATE servers. The immediate goal in CN peering is moving the 745 content between DISTRIBUTION CPGs. 747 The second component of content distribution is content signaling. 748 Content signaling is the propagation of content meta-data. This 749 meta-data may include such information such as the immediate 750 expiration of content or a change in the expiration time of CONTENT. 751 The immediate goal in signaling is exchanging signals between 752 DISTRIBUTION CPGs. 754 The third component of content distribution is content advertising. 755 Content providers must be able to advertise content that can be 756 distributed by CNs and its associated terms. It is important that 757 the advertising of content must be able to aggregate content 758 information. The immediate goal in advertising is exchanging 759 advertisements between DISTRIBUTION CPGs. 761 4.4 Distribution System Requirements 763 Replication systems must have a peering relationship. This peering 764 relationship must exchange sets of aggregated content and its 765 meta-data. Meta-data may change over time independently of the 766 content data and must be exchanged independently as well. 768 4.4.1 Replication Requirements 770 The specific requirements in content replication are: 772 1. A common protocol for the replication of content. 774 2. A common format for the actual content data in the protocol. 776 3. A common format for the content meta-data in the protocol. 778 4. Security mechanisms (see Section 6). 780 5. Scalable distribution of the content. 782 4.4.2 Signaling Requirements 784 The specific requirements in content signaling are: 786 1. Signals for (at least) "flush" and "expiration time update". 788 2. Security mechanisms (see Section 6). 790 3. Scalable distribution of the signals on a large scale. 792 Editor Note: 793 We have to start being quantitative about what we mean by 794 "large scale". Are we thinking in terms of the number of 795 content items, the number of networks, or the number of 796 signals? For each of those, how big is "large scale"? 798 4. Content location and serviced CLIENT IP aggregate address 799 exchanges with REQUEST-ROUTING CPGs. 801 4.4.3 Advertising Requirements 803 The specific requirements in CONTENT ADVERTISEMENT are: 805 1. A common protocol for the ADVERTISEMENT of CONTENT. 807 2. A common format for the actual ADVERTISEMENTs in the protocol. 809 Editor Note: 810 The following requirements need further discussion. As it 811 stands now, there isn't sufficient information to 812 substantiate them. 814 3. A well-known state machine. 816 4. Use of TCP or SCTP (because soft-state protocols will not scale). 818 5. Well-known error codes to diagnose protocols between different 819 networks. 821 6. Capability negotiation. 823 7. Ability to represent policy. 825 [Editor Note: 826 System requirements being generated in the distribution peering 827 protocol design team have not yet been reconciled and integrated 828 into this document.] 830 4.5 Protocol Requirements 832 Consult [18] for distribution peering protocol requirements. 834 4.6 Distribution Problems to Solve 836 [Editor Note: 837 This section is being preserved until it has been determined that 838 these issues have been addressed in the distribution peering 839 protocol requirements draft.] 841 Some of the problems in distribution revolve around supporting both 842 a push model and a pull model for replication of content in that 843 they are not symmetric. The push model is used for pre-loading of 844 content and the pull model is used for on-demand fetching and 845 pre-fetching of content. These models are not symmetric in that the 846 amount of available resources in which to place the content on the 847 target server must be known. In the fetching cases the server that 848 pulls the content knows the available resources on the target 849 server, itself. In the pre-loading case the server that pushes the 850 content must find out the available resources from the target server 851 before pushing the data. 853 4.6.1 General Problems 855 General problems in distribution peering needing further 856 investigation include: 858 1. How would a single distribution peering protocol adequately 859 support replication, signaling and advertising? 861 2. Should a single distribution peering protocol be considered, 862 rather than separate protocols for each component? 864 3. How do we prevent looping of distribution updates? That is to 865 say, detect and stop propagating replication, signaling and 866 advertisement of events a DISTRIBUTION CPG has already issued. 868 Looping here has the possibility of becoming infinite, if not 869 bounded by the protocol(s). IP route updating and forwarding 870 has faced similar issues and has solved them. 872 4.6.2 Replication Problems 874 Specific problems in replication needing further investigation 875 include: 877 1. How do replication systems forward a request? 879 2. How do we keep pull based replication serviced within the 880 DISTRIBUTION CPGs in order to prevent it from inadvertently 881 bleeding out into REQUEST-ROUTING SYSTEM and potentially getting 882 into a recursive loop? 884 3. How are policies communicated between the replication systems? 886 4. What are the replication protocols? 888 5. Does replication only take place between CPGs? 890 4.6.3 Signaling Problems 892 Specific problems in content signaling needing further investigation 893 include: 895 1. How do we represent a content signal? 897 2. What content meta-data needs to be signaled? 899 3. How do we represent aggregates of meta-data in a concise and 900 compressed manner? 902 4. What protocol(s) should be used for content signals? 904 5. What is a scalable architecture for delivering content signals? 906 6. Do content signals need a virtual distribution system of their 907 own? 909 4.6.4 Advertising Problems 911 Specific problems in CONTENT ADVERTISEMENT needing further 912 investigation include: 914 1. How do we represent aggregates of content to be distributed in a 915 concise and compressed manner? 917 2. What protocol(s) should be used for the aggregation of this data? 919 3. What are the issues involved in the creation of CPG exchanges? 920 This is actually a broader question than just for distribution, 921 but needs to be considered for all forms of CPGs 922 {REQUEST-ROUTING, DISTRIBUTION, ACCOUNTING}. 924 5. Accounting Peering System 926 The ACCOUNTING PEERING SYSTEM represents the accounting data 927 collection function of the Content Internetworking system. It is 928 responsible for moving accounting data from one ACCOUNTING CPG to 929 another ACCOUNTING CPG. 931 5.1 Accounting Overview 933 Content Internetworking must provide the ability for the content 934 provider to collect data regarding the delivery of their CONTENT by 935 the peered CNs. ACCOUNTING CPGs exchange the data collected by the 936 interior ACCOUNTING SYSTEMS. This interior data may be collected 937 from the SURROGATEs by ACCOUNTING CPGs using SNMP or FTP, for 938 example. ACCOUNTING CPGs may transfer the data to exterior 939 neighboring ACCOUNTING CPGs on request (push), in an asynchronous 940 manner (push), or a combination of both. Accounting data may also be 941 aggregated before it is transferred. 943 Figure 5 is a diagram of the entities involved in the ACCOUNTING 944 PEERING SYSTEM. 946 +---------+ 947 | BILLING | +--------+ 948 | ORG. | | ORIGIN | 949 +---------+ +--------+ 950 BILLING | | ACCOUNTING PEERING | | ORIGIN ACCOUNTING PEERING 951 /-----/ \-----------------------|-|----\ 952 | /-----------------------------/ \----|-\ 953 | | | | 954 +--------------+ +--------------+ 955 .........| ACCOUNTING |........... ...........| ACCOUNTING |........ 956 . CN A | CPG | . . CN B | CPG | . 957 . +--------------+ . . +--------------+ . 958 . | . . | . 959 . +--------------+ . . +--------------+ . 960 . | ACCOUNTING | . . | ACCOUNTING | . 961 . | SYSTEM | . . | SYSTEM | . 962 . +--------------+ . . +--------------+ . 963 . | | . . | | . 964 . /-----/ \-------\ . . /-----/ \----\ . 965 . | | . . | | . 966 . | +--------------+ . . +--------------+ | . 967 . +------------+ | ACCOUNTING | . . | ACCOUNTING | +------------+ . 968 ..| SURROGATEs |.| CPG |... ..| CPG |.| SURROGATEs |.. 969 +------------+ +--------------+ +--------------+ +------------+ 970 | | | | 971 | \-----------------/ | 972 \----------\ /-----------/ 973 | | INTER-CN ACCOUNTING PEERING 974 | | 975 +--------------+ 976 .........| ACCOUNTING |........... 977 . CN C | CPG | . 978 . +--------------+ . 979 . | . 980 . +--------------+ . 981 . | ACCOUNTING | . 982 . | SYSTEM | . 983 . +--------------+ . 984 . | | . 985 . /-----/ \-------\ . 986 . | | . 987 . | | . 988 . +-----------+ +------------+ . 989 ..| SURROGATE |.....| SURROGATEs |.. 990 +-----------+ +------------+ 992 Figure 5 ACCOUNTING Peering system Architecture 993 There are three CN accounting peering relationships we expect to be 994 common; INTER-CN accounting peering, BILLING ORGANIZATION accounting 995 peering and ORIGIN accounting peering. INTER-CN accounting peering 996 involves exchanging accounting information between individual CNs in 997 a inter-network of peered CNs. BILLING ORGANIZATION peering involves 998 exchanging to accounting information between CNs and a billing 999 organization. ORIGIN accounting peering involves the exchanging of 1000 accounting information between CNs and ORIGINs. 1002 Note: 1003 It is not necessary for an ORIGIN to peer directly with multiple 1004 CNs in order to participate in Content Internetworking. ORIGINs 1005 participating in a single home CN will be indirectly peered by 1006 their home CN with the inter-network of CNs the home CN is a 1007 member of. Nor is it necessary to have a BILLING ORGANIZATION 1008 peer, since this function may also be provided by the home CN. 1009 However, ORIGINs that directly peer for ACCOUNTING may have 1010 access to greater accounting detail. Also, through the use of 1011 ACCOUNTING peering, 3rd party billing can be provided. 1013 5.2 Accounting System Requirements 1015 [Editor Note: 1016 System requirements being generated in the accounting peering 1017 protocol design team have not yet been reconciled and integrated 1018 into this document.] 1020 5.3 Protocol Requirements 1022 Consult [15] for accounting peering protocol requirements. 1024 6. Security Considerations 1026 Security concerns with respect to Content Internetworking can be 1027 generally categorized into trust within the system and protection of 1028 the system from threats. The trust model utilized with Content 1029 Internetworking is predicated largely on transitive trust between 1030 the ORIGIN, REQUEST-ROUTING PEERING SYSTEM, DISTRIBUTION PEERING 1031 SYSTEM, ACCOUNTING PEERING SYSTEM and SURROGATES. Network elements 1032 within the Content Internetworking system are considered to be 1033 "insiders" and therefore trusted. 1035 6.1 Threats to Content Internetworking 1037 The following sections document key threats to CLIENTs, PUBLISHERs, 1038 and CNs. The threats are classified according to the party that they 1039 most directly harm, but, of course, a threat to any party is 1040 ultimately a threat to all. (For example, having a credit card 1041 number stolen may most directly affect a CLIENT; however, the 1042 resulting dissatisfaction and publicity will almost certainly cause 1043 some harm to the PUBLISHER and CN, even if the harm is only to those 1044 organizations' reputations.) 1046 6.1.1 Threats to the CLIENT 1048 6.1.1.1 Defeat of CLIENT's Security Settings 1050 Because the SURROGATE's location may differ from that of the ORIGIN, 1051 the use of a SURROGATE may inadvertently or maliciously defeat any 1052 location-based security settings employed by the CLIENT. And since 1053 the SURROGATE's location is generally transparent to the CLIENT, the 1054 CLIENT may be unaware that its protections are no longer in force. 1055 For example, a CN may relocate CONTENT from a Internet Explorer 1056 user's "Internet Web Content Zone" to that user's "Local Intranet 1057 Web Content Zone." If the relocation is visible to the Internet 1058 Explorer browser but otherwise invisible to the user, the browser 1059 may be employing less stringent security protections than the user 1060 is expecting for that CONTENT. (Note that this threat differs, at 1061 least in degree, from the substitution of security parameters threat 1062 below, as Web Content Zones can control whether or not, for example, 1063 the browser executes unsigned active content.) 1065 6.1.1.2 Delivery of Bad Accounting Information 1067 In the case of CONTENT with value, CLIENTs may be inappropriately 1068 charged for viewing content that they did not successfully access. 1069 Conversely, some PUBLISHERs may reward CLIENTs for viewing certain 1070 CONTENT (e.g. programs that "pay" users to surf the Web). Should a 1071 CN fail to deliver appropriate accounting information, the CLIENT 1072 may not receive appropriate credit for viewing the required CONTENT. 1074 6.1.1.3 Delivery of Bad CONTENT 1076 A CN that does not deliver the appropriate CONTENT may provide the 1077 user misleading information (either maliciously or inadvertently). 1078 This threat can be manifested as a failure of either the 1079 DISTRIBUTION SYSTEM (inappropriate content delivered to appropriate 1080 SURROGATEs) or REQUEST-ROUTING SYSTEM (request routing to 1081 inappropriate SURROGATEs, even though they may have appropriate 1082 CONTENT), or both. A REQUEST-ROUTING SYSTEM may also fail by 1083 forwarding the CLIENT request when no forwarding is appropriate, or 1084 by failing to forward the CLIENT request when forwarding is 1085 appropriate. 1087 6.1.1.4 Denial of Service 1089 A CN that does not forward the CLIENT appropriately may deny the 1090 CLIENT access to CONTENT. 1092 6.1.1.5 Exposure of Private Information 1094 CNs may inadvertently or maliciously expose private information 1095 (passwords, buying patterns, page views, credit card numbers) as it 1096 transits from SURROGATEs to ORIGINs and/or PUBLISHERs. 1098 6.1.1.6 Substitution of Security Parameters 1100 If a SURROGATE does not duplicate completely the security facilities 1101 of the ORIGIN (e.g. encryption algorithms, key lengths, certificate 1102 authorities) CONTENT delivered through the SURROGATE may be less 1103 secure than the CLIENT expects. 1105 6.1.1.7 Substitution of Security Policies 1107 If a SURROGATE does not employ the same security policies and 1108 procedures as the ORIGIN, the CLIENT's private information may be 1109 treated with less care than the CLIENT expects. For example, the 1110 operator of a SURROGATE may not have as rigorous protection for the 1111 CLIENT's password as does the operator of the ORIGIN server. This 1112 threat may also manifest itself if the legal jurisdiction of the 1113 SURROGATE differs from that of the ORIGIN, should, for example, 1114 legal differences between the jurisdictions require or permit 1115 different treatment of the CLIENT's private information. 1117 6.1.2 Threats to the PUBLISHER 1119 6.1.2.1 Delivery of Bad Accounting Information 1121 If a CN does not deliver accurate accounting information, the 1122 PUBLISHER may be unable to charge CLIENTs for accessing CONTENT or 1123 it may reward CLIENTs inappropriately. Inaccurate accounting 1124 information may also cause a PUBLISHER to pay for services (e.g. 1125 content distribution) that were not actually rendered.) Invalid 1126 accounting information may also effect PUBLISHERs indirectly by, for 1127 example, undercounting the number of site visitors (and, thus, 1128 reducing the PUBLISHER's advertising revenue). 1130 6.1.2.2 Denial of Service 1132 A CN that does not distribute CONTENT appropriately may deny CLIENTs 1133 access to CONTENT. 1135 6.1.2.3 Substitution of Security Parameters 1137 If a SURROGATE does not duplicate completely the security services 1138 of the ORIGIN (e.g. encryption algorithms, key lengths, certificate 1139 authorities, client authentication) CONTENT stored on the SURROGATE 1140 may be less secure than the PUBLISHER prefers. 1142 6.1.2.4 Substitution of Security Policies 1144 If a SURROGATE does not employ the same security policies and 1145 procedures as the ORIGIN, the CONTENT may be treated with less care 1146 than the PUBLISHER expects. This threat may also manifest itself if 1147 the legal jurisdiction of the SURROGATE differs from that of the 1148 ORIGIN, should, for example, legal differences between the 1149 jurisdictions require or permit different treatment of the CONTENT. 1151 6.1.3 Threats to a CN 1153 6.1.3.1 Bad Accounting Information 1155 If a CN is unable to collect or receive accurate accounting 1156 information, it may be unable to collect compensation for its 1157 services from PUBLISHERs. 1159 6.1.3.2 Denial of Service 1161 Misuse of a CN may make that CN's facilities unavailable, or 1162 available only at reduced functionality, to legitimate customers or 1163 the CN provider itself. Denial of service attacks can be targeted at 1164 a CN's ACCOUNTING SYSTEM, DISTRIBUTION SYSTEM, or REQUEST-ROUTING 1165 SYSTEM. 1167 6.1.3.3 Transitive Threats 1169 To the extent that a CN acts as either a CLIENT or a PUBLISHER (such 1170 as, for example, in transitive implementations) such a CN may be 1171 exposed to any or all of the threats described above for both roles. 1173 7. Acknowledgements 1175 The authors would like to acknowledge the contributions and comments 1176 of Mark Day (Cisco), Fred Douglis (AT&T), Patrik Falstrom (Cisco), 1177 Don Gilletti (CacheFlow), Barron Housel (Cisco) John Martin (Network 1178 Appliance), Raj Nair (Cisco), Hilarie Orman (Novell), Doug Potter 1179 (Cisco), John Scharber (CacheFlow), and Oliver Spatscheck (AT&T). 1181 References 1183 [1] Hawkinson, J. and T. Bates, "Guidelines for creation, 1184 selection, and registration of an Autonomous System (AS)", BCP 1185 6, March 1996, 1186 . 1188 [2] Postel, J., "Internet Protocol, DARPA Internet Program 1189 Protocol Specification", RFC 791, September 1981, 1190 . 1192 [3] Hares, S. and D. Katz, "Administrative Domains and Routing 1193 Domains A Model for Routing in the Internet", RFC 1136, 1194 December 1989, 1195 . 1197 [4] Postel, J., "Domain Name Structure and Delegation", RFC 1591, 1198 March 1994, 1199 . 1201 [5] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 1202 RFC 1771, March 1995, 1203 . 1205 [6] Carpenter, B., "Architecture Principles of the Internet", RFC 1206 1958, June 1996, 1207 . 1209 [7] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 1210 Protocol", RFC 2326, April 1998, 1211 . 1213 [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1214 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1215 1998, 1216 . 1218 [9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 1219 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol 1220 -- HTTP/1.1", RFC 2616, June 1999, 1221 . 1223 [10] Carpenter, B., "Internet Transparency", RFC 2775, February 1224 2000, 1225 . 1227 [11] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web 1228 Replication and Caching Taxonomy", RFC 3040, January 2001, 1229 . 1231 [12] Volbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, 1232 G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, 1233 "AAA Authorization Framework", 1234 draft-ietf-aaa-authz-arch-00.txt (work in progress), October 1235 1999, 1236 . 1239 [13] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for 1240 Content Internetworking", draft-day-cdnp-model-05.txt (work in 1241 progress), March 2001, 1242 . 1245 [14] Day, M., Gilletti, D. and P. Rzewski, "Content Internetworking 1246 Scenarios", draft-day-cdnp-scenarios-03.txt (work in 1247 progress), March 2001, 1248 . 1251 [15] Gilletti, D., Nair, R., Scharber, J. and J. Guha, "Content 1252 Internetworking Authentication, Authorization, and Accounting 1253 Requirements", draft-gilletti-cdnp-aaa-reqs-01.txt (work in 1254 progress), January 2001, 1255 . 1258 [16] Barbir, A., Cain, B., Douglis, F., Green, M., Hofmann, M., 1259 Nair, R., Potter, D. and O. Spatscheck, "Known CDN 1260 Request-Routing Mechanisms", 1261 draft-cain-cdnp-known-request-routing-01.txt (work in 1262 progress), February 2001. 1264 [17] Cain, B., Spatscheck, O., May, M. and A. Barbir, 1265 "Request-Routing Requirements for Content Internetworking", 1266 draft-ietf-cain-request-routing-req-01.txt (work in progress), 1267 March 2001. 1269 [18] Amini, L., Thomas, S. and O. Spatscheck, "Distribution Peering 1270 Requirements for Content Distribution Internetworking", 1271 draft-amini-cdi-distribution-reqs-00.txt (work in progress), 1272 February 2001. 1274 Authors' Addresses 1276 Mark Green 1277 CacheFlow Inc. 1278 650 Almanor Avenue 1279 Sunnyvale, CA 94086 1280 US 1282 Phone: +1 408 543 0470 1283 EMail: markg@cacheflow.com 1285 Brad Cain 1286 Cereva Networks 1288 EMail: bcain@cereva.com 1290 Gary Tomlinson 1291 CacheFlow Inc. 1292 12034 134th Ct. NE 1293 Suite 201 1294 Redmond, WA 98052 1295 US 1297 Phone: +1 425 820 3009 1298 EMail: garyt@cacheflow.com 1300 Stephen Thomas 1301 TransNexus, Inc. 1302 430 Tenth Street NW 1303 Suite N204 1304 Atlanta, GA 30318 1305 US 1307 Phone: +1 404 872 4887 1308 EMail: stephen.thomas@transnexus.com 1310 Phil Rzewski 1311 Inktomi 1312 4100 East Third Avenue 1313 MS FC1-4 1314 Foster City, CA 94404 1315 US 1317 Phone: +1 650 653 2487 1318 EMail: philr@inktomi.com 1320 Full Copyright Statement 1322 Copyright (C) The Internet Society (2001). All Rights Reserved. 1324 This document and translations of it may be copied and furnished to 1325 others, and derivative works that comment on or otherwise explain it 1326 or assist in its implementation may be prepared, copied, published 1327 and distributed, in whole or in part, without restriction of any 1328 kind, provided that the above copyright notice and this paragraph 1329 are included on all such copies and derivative works. However, this 1330 document itself may not be modified in any way, such as by removing 1331 the copyright notice or references to the Internet Society or other 1332 Internet organizations, except as needed for the purpose of 1333 developing Internet standards in which case the procedures for 1334 copyrights defined in the Internet Standards process must be 1335 followed, or as required to translate it into languages other than 1336 English. 1338 The limited permissions granted above are perpetual and will not be 1339 revoked by the Internet Society or its successors or assigns. 1341 This document and the information contained herein is provided on an 1342 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1343 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1344 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1345 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1346 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1348 Acknowledgement 1350 Funding for the RFC editor function is currently provided by the 1351 Internet Society.