idnits 2.17.1 draft-ietf-wrec-taxonomy-05.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([23]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 178: '... other servers. A proxy MUST implement...' 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 (July 4, 2000) is 8697 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) ** Obsolete normative reference: RFC 2616 (ref. '1') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 2186 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2187 (ref. '6') -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 1436 (ref. '11') ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '12') -- Possible downref: Normative reference to a draft: ref. '13' ** Downref: Normative reference to an Informational RFC: RFC 1794 (ref. '15') == Outdated reference: A later version (-02) exists of draft-lovric-francetelecom-satellites-01 -- Possible downref: Normative reference to a draft: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Downref: Normative reference to an Experimental RFC: RFC 2756 (ref. '18') -- Possible downref: Non-RFC (?) normative reference: ref. '19' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '20') -- Possible downref: Normative reference to a draft: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' == Outdated reference: A later version (-03) exists of draft-ietf-wrec-known-prob-02 -- Possible downref: Normative reference to a draft: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' -- Possible downref: Non-RFC (?) normative reference: ref. '25' -- Possible downref: Non-RFC (?) normative reference: ref. '26' -- Possible downref: Non-RFC (?) normative reference: ref. '27' Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Cooper 3 Internet-Draft Mirror Image 4 Expires: January 2, 2001 I. Melve 5 UNINETT 6 G. Tomlinson 7 Novell 8 July 4, 2000 10 Internet Web Replication and Caching Taxonomy 11 draft-ietf-wrec-taxonomy-05.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 2, 2001. 36 Copyright Notice 38 Copyright (C) The Internet Society (2000). All Rights Reserved. 40 Abstract 42 This memo specifies standard terminology and the current taxonomy of 43 web replication and caching infrastructure deployed today. It 44 introduces standard concepts and protocols used today within this 45 application domain. Currently deployed solutions employing these 46 technologies are presented to establish a standard taxonomy. Known 47 problems with caching proxies are covered in an accompanying 48 document[23], and are not part of this document. This document 49 presents open protocols and points to published material for each 50 protocol. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1 Base Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.2 First order derivative terms . . . . . . . . . . . . . . . 7 58 2.3 Second order derivatives . . . . . . . . . . . . . . . . . 8 59 2.4 Topological terms . . . . . . . . . . . . . . . . . . . . 8 60 2.5 Automatic use of proxies . . . . . . . . . . . . . . . . . 9 61 3. Distributed System Relationships . . . . . . . . . . . . . 11 62 3.1 Replication Relationships . . . . . . . . . . . . . . . . 11 63 3.1.1 Client to Replica . . . . . . . . . . . . . . . . . . . . 11 64 3.1.2 Inter-Replica . . . . . . . . . . . . . . . . . . . . . . 11 65 3.2 Proxy Relationships . . . . . . . . . . . . . . . . . . . 12 66 3.2.1 Client to Non-Interception Proxy . . . . . . . . . . . . . 12 67 3.2.2 Client to Surrogate to Origin Server . . . . . . . . . . . 12 68 3.2.3 Inter-Proxy . . . . . . . . . . . . . . . . . . . . . . . 13 69 3.2.3.1 (Caching) Proxy Meshes . . . . . . . . . . . . . . . . . . 13 70 3.2.3.2 (Caching) Proxy Arrays . . . . . . . . . . . . . . . . . . 14 71 3.2.4 Network Element to Caching Proxy . . . . . . . . . . . . . 14 72 4. Replica Selection . . . . . . . . . . . . . . . . . . . . 16 73 4.1 Navigation Hyperlinks . . . . . . . . . . . . . . . . . . 16 74 4.2 HTTP Redirection . . . . . . . . . . . . . . . . . . . . . 16 75 4.3 DNS Redirection . . . . . . . . . . . . . . . . . . . . . 17 76 5. Inter-Replica Communication . . . . . . . . . . . . . . . 18 77 5.1 Batch Driven Replication . . . . . . . . . . . . . . . . . 18 78 5.2 Demand Driven Replication . . . . . . . . . . . . . . . . 18 79 5.3 Synchronized Replication . . . . . . . . . . . . . . . . . 19 80 6. User Agent to Proxy Configuration . . . . . . . . . . . . 20 81 6.1 Manual Proxy Configuration . . . . . . . . . . . . . . . . 20 82 6.2 Proxy Auto Configuration (PAC) . . . . . . . . . . . . . . 20 83 6.3 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 21 84 6.4 Web Proxy Auto-Discovery Protocol (WPAD) . . . . . . . . . 21 85 7. Inter-Proxy Communication . . . . . . . . . . . . . . . . 23 86 7.1 Loosely coupled Inter-Proxy Communication . . . . . . . . 23 87 7.1.1 Internet Cache Protocol (ICP) . . . . . . . . . . . . . . 23 88 7.1.2 Hyper Text Caching Protocol . . . . . . . . . . . . . . . 23 89 7.1.3 Cache Digest . . . . . . . . . . . . . . . . . . . . . . . 24 90 7.1.4 Cache Pre-filling . . . . . . . . . . . . . . . . . . . . 25 91 7.2 Tightly Coupled Inter-Cache Communication . . . . . . . . 26 92 7.2.1 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 26 93 8. Network Element Communication . . . . . . . . . . . . . . 27 94 8.1 Web Cache Control Protocol (WCCP) . . . . . . . . . . . . 27 95 8.2 Network Element Control Protocol (NECP) . . . . . . . . . 27 96 8.3 SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . 28 97 9. Security Considerations . . . . . . . . . . . . . . . . . 29 98 9.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 29 99 9.1.1 Man in the middle attacks . . . . . . . . . . . . . . . . 29 100 9.1.2 Trusted third party . . . . . . . . . . . . . . . . . . . 29 101 9.1.3 Authentication based on IP number . . . . . . . . . . . . 29 102 9.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 30 103 9.2.1 Trusted third party . . . . . . . . . . . . . . . . . . . 30 104 9.2.2 Logs and legal implications . . . . . . . . . . . . . . . 30 105 9.3 Service security . . . . . . . . . . . . . . . . . . . . . 30 106 9.3.1 Denial of service . . . . . . . . . . . . . . . . . . . . 31 107 9.3.2 Replay attack . . . . . . . . . . . . . . . . . . . . . . 31 108 9.3.3 Stupid configuration of proxies . . . . . . . . . . . . . 31 109 9.3.4 Copyrighted transient copies . . . . . . . . . . . . . . . 31 110 9.3.5 Application level access . . . . . . . . . . . . . . . . . 31 111 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32 112 References . . . . . . . . . . . . . . . . . . . . . . . . 33 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 35 114 Full Copyright Statement . . . . . . . . . . . . . . . . . 37 116 1. Introduction 118 Since its introduction in 1990, the World-Wide Web has evolved from 119 a simple client server model into a sophisticated distributed 120 architecture. This evolution has been driven largely due to the 121 scaling problems associated with exponential growth. Distinct 122 paradigms and solutions have emerged to satisfy specific 123 requirements. Two core infrastructure components being employed to 124 meet the demands of this growth are replication and caching. In many 125 cases, there is a need for web caches and replicated services to be 126 able to coexist. 128 There are many protocols, both open and proprietary, employed in web 129 replication and caching today. A majority of the open protocols 130 include DNS[15], Cache Digests[17][19], CARP[4], HTTP[1], ICP[5], 131 PAC[2], SOCKS[14], WPAD[3], and WCCP[13]. Additional protocols are 132 being planned to address emerging solution requirements. 134 This memo specifies standard terminology and the taxonomy of web 135 replication and caching infrastructure deployed in the Internet 136 today. The principal goal of this document is to establish a common 137 understanding and reference point of this application domain. 139 We also expect that this document will be used in the creation of a 140 standard architectural framework for efficient, reliable, and 141 predictable service in a web which includes both replicas and caches. 143 2. Terminology 145 The following terminology provides definitions of common terms used 146 within the web replication and caching community. Base terms are 147 taken, where possible, from the HTTP/1.1 specification[1] and are 148 included here for reference. First- and second-order derivatives are 149 constructed from these base terms to help define the relationships 150 that exist within this area. 152 Terms that are in common usage and which are contrary to definitions 153 in RFC2616 and this document are highlighted. 155 2.1 Base Terms 157 The majority of these terms are taken as-is from RFC2616[1], and are 158 included here for reference. 160 client (taken from [1]) 161 A program that establishes connections for the purpose of sending 162 requests. 164 server (taken from [1]) 165 An application program that accepts connections in order to 166 service requests by sending back responses. Any given program may 167 be capable of being both a client and a server; our use of these 168 terms refers only to the role being performed by the program for 169 a particular connection, rather than to the program's 170 capabilities in general. Likewise, any server may act as an 171 origin server, proxy, gateway, or tunnel, switching behavior 172 based on the nature of each request. 174 proxy (taken from [1]) 175 An intermediary program which acts as both a server and a client 176 for the purpose of making requests on behalf of other clients. 177 Requests are serviced internally or by passing them on, with 178 possible translation, to other servers. A proxy MUST implement 179 both the client and server requirements of this specification. A 180 "transparent proxy" is a proxy that does not modify the request 181 or response beyond what is required for proxy authentication and 182 identification. A "non-transparent proxy" is a proxy that 183 modifies the request or response in order to provide some added 184 service to the user agent, such as group annotation services, 185 media type transformation, protocol reduction, or anonymity 186 filtering. Except where either transparent or non-transparent 187 behavior is explicitly stated, the HTTP proxy requirements apply 188 to both types of proxies. 190 Note: The term "transparent proxy" refers to a semantically 191 transparent proxy as described in [1], not what is commonly 192 understood within the caching community. We recommend that the term 193 "transparent proxy" is always prefixed to avoid confusion (e.g. 194 "network transparent proxy"). However, see definition of 195 "interception proxy" below. 197 The above condition requiring implementation of both the server and 198 client requirements of HTTP/1.1 is only appropriate for a 199 non-network transparent proxy. 201 cache (taken from [1]) 202 A program's local store of response messages and the subsystem 203 that controls its message storage, retrieval, and deletion. A 204 cache stores cacheable responses in order to reduce the response 205 time and network bandwidth consumption on future, equivalent 206 requests. Any client or server may include a cache, though a 207 cache cannot be used by a server that is acting as a tunnel. 209 Note: The term "cache" used alone often is meant as "caching proxy". 211 Note: There are additional motivations for caching, for example 212 reducing server load (as a further means to reduce response time). 214 cacheable (taken from [1]) 215 A response is cacheable if a cache is allowed to store a copy of 216 the response message for use in answering subsequent requests. 217 The rules for determining the cacheability of HTTP responses are 218 defined in section 13. Even if a resource is cacheable, there may 219 be additional constraints on whether a cache can use the cached 220 copy for a particular request. 222 gateway (taken from [1]) 223 A server which acts as an intermediary for some other server. 224 Unlike a proxy, a gateway receives requests as if it were the 225 origin server for the requested resource; the requesting client 226 may not be aware that it is communicating with a gateway. 228 tunnel (taken from [1]) 229 An intermediary program which is acting as a blind relay between 230 two connections. Once active, a tunnel is not considered a party 231 to the HTTP communication, though the tunnel may have been 232 initiated by an HTTP request. The tunnel ceases to exist when 233 both ends of the relayed connections are closed. 235 replication (definition from FOLDOC[22]) 236 Creating and maintaining a duplicate copy of a database or file 237 system on a different computer, typically a server. 239 inbound/outbound (taken from [1]) 240 Inbound and outbound refer to the request and response paths for 241 messages: "inbound" means "traveling toward the origin server", 242 and "outbound" means "traveling toward the user agent". 244 network element 245 A network device that introduces multiple paths between source 246 and destination, transparent to HTTP. 248 2.2 First order derivative terms 250 The following terms are constructed taking the above base terms as 251 foundation. 253 origin server (taken from [1]) 254 The server on which a given resource resides or is to be created. 256 user agent (taken from [1]) 257 The client which initiates a request. These are often browsers, 258 editors, spiders (web-traversing robots), or other end user tools. 260 caching proxy 261 A proxy with a cache, acting as a server to clients, and a client 262 to servers. 264 Caching proxies are often referred to as "proxy caches" or simply 265 "caches". The term "proxy" is also frequently misused when 266 referring to caching proxies. 268 surrogate 269 A gateway co-located with an origin server, or at a different 270 point in the network, delegated the authority to operate on 271 behalf of, and typically working in close co-operation with, one 272 or more origin servers. Responses are typically delivered from an 273 internal cache. 275 Surrogates may derive cache entries from the origin server or 276 from another of the origin server's delegates. In some cases a 277 surrogate may tunnel such requests. 279 Where close co-operation between origin servers and surrogates 280 exists, this enables modifications of some protocol requirements, 281 including the Cache-Control directives in [1]. Such modifications 282 have yet to be fully specified. 284 Devices commonly known as "reverse proxies" and "(origin) server 285 accelerators" are both more properly defined as surrogates. 287 reverse proxy 288 See "surrogate". 290 server accelerator 291 See "surrogate". 293 2.3 Second order derivatives 295 The following terms further build on first order derivatives: 297 master origin server 298 An origin server on which the definitive version of a resource 299 resides. 301 replica origin server 302 An origin server holding a replica of a resource, but which may 303 act as an authoritative reference for client requests. 305 content consumer 306 The user or system that initiates inbound requests, through use 307 of a user agent. 309 browser 310 A special instance of a user agent that acts as a content 311 presentation device for content consumers. 313 2.4 Topological terms 315 The following definitions are added to describe caching device 316 topology: 318 user agent cache 319 The cache within the user agent program. 321 local caching proxy 322 The caching proxy to which a user agent connects. 324 intermediate caching proxy 325 Seen from the content consumer's view, all caches participating 326 in the caching mesh that are not the user agent's local caching 327 proxy. 329 cache server 330 A server to requests made by local and intermediate caching 331 proxies, but which does not act as a proxy. 333 cache array 334 A cluster of caching proxies, acting logically as one service and 335 partitioning the resource name space across the array. Also known 336 as "diffused array" or "cache cluster". 338 caching mesh 339 a loosely coupled set of co-operating proxy- and (optionally) 340 caching-servers, or clusters, acting independently but sharing 341 cacheable content between themselves using inter-cache 342 communication protocols. 344 2.5 Automatic use of proxies 346 Network administrators may wish to force or facilitate the use of 347 proxies by clients, enabling such configuration within the network 348 itself or within automatic systems in user agents, such that the 349 content consumer need not be aware of any such configuration issues. 351 The terms that describe such configurations are given below. 353 automatic user-agent proxy configuration 354 The technique of discovering the availability of one or more 355 proxies and the automated configuration of the user agent to use 356 them. The use of a proxy is transparent to the content consumer 357 but not to the user agent. The term "automatic proxy 358 configuration" is also used in this sense. 360 traffic interception 361 The process of using a network element to examine network traffic 362 to determine whether it should be redirected. 364 traffic redirection 365 Redirection of client requests from a network element performing 366 traffic interception to a proxy. Used to deploy (caching) proxies 367 without the need to manually reconfigure individual user agents, 368 or to force the use of a proxy where such use would not otherwise 369 occur. 371 interception proxy (a.k.a. "transparent proxy", "transparent cache") 372 The term "transparent proxy" has been used within the caching 373 community to describe proxies used with zero configuration within 374 the user agent. Such use is somewhat transparent to user agents. 375 Due to discrepancies with [1] (see definition of "proxy" above), 376 and objections to the use of the word "transparent", we introduce 377 the term "interception proxy" to describe proxies that receive 378 redirected traffic flows from network elements performing traffic 379 interception. 381 Interception proxies receive inbound traffic flows through the 382 process of traffic redirection. (Such proxies are deployed by 383 network administrators to facilitate or require the use of 384 appropriate services offered by the proxy). Problems associated 385 with the deployment of interception proxies are described in the 386 companion document "Known HTTP Proxy/Caching Problems"[23]. The 387 use of interception proxies requires zero configuration of the 388 user agent which act as though communicating directly with an 389 origin server. 391 3. Distributed System Relationships 393 This section identifies the relationships that exist in a 394 distributed replication and caching environment. Having defined 395 these relationships, later sections describe the communication 396 protocols used in each relationship. 398 3.1 Replication Relationships 400 The following sections describe relationships between clients and 401 replicas and between replicas themselves. 403 3.1.1 Client to Replica 405 A client may communicate with one or more replica origin servers, as 406 well as with master origin servers. (In the absence of replica 407 servers the client interacts directly with the origin server as is 408 the normal case.) 410 ------------------ ----------------- ------------------ 411 | Replica Origin | | Master Origin | | Replica Origin | 412 | Server | | Server | | Server | 413 ------------------ ----------------- ------------------ 414 \ | / 415 \ | / 416 ----------------------------------------- 417 | Client to 418 ----------------- Replica Server 419 | Client | 420 ----------------- 422 Protocols used to enable the client to use one of the replicas can 423 be found in Section 4. 425 3.1.2 Inter-Replica 427 This is the relationship between master origin server(s) and replica 428 origin servers, to replicate data sets that are accessed by clients 429 in the relationship shown in Section 3.1.1. 431 ------------------ ----------------- ------------------ 432 | Replica Origin |-----| Master Origin |-----| Replica Origin | 433 | Server | | Server | | Server | 434 ------------------ ----------------- ------------------ 436 Protocols used in this relationship can be found in Section 5. 438 3.2 Proxy Relationships 440 There are a variety of ways in which (caching) proxies and cache 441 servers communicate with each other, and with user agents. 443 3.2.1 Client to Non-Interception Proxy 445 A client may communicate with zero or more proxies for some or all 446 requests. Where the result of communication results in no proxy 447 being used, the relationship is between client and (replica) origin 448 server (see Section 3.1.1). 450 ----------------- ----------------- ----------------- 451 | Local | | Local | | Local | 452 | Proxy | | Proxy | | Proxy | 453 ----------------- ----------------- ----------------- 454 \ | / 455 \ | / 456 ----------------------------------------- 457 | 458 ----------------- 459 | Client | 460 ----------------- 462 In addition, a user agent may interact with an additional server - 463 operated on behalf of a proxy for the purpose of automatic user 464 agent proxy configuration. 466 Schemes and protocols used in these relationships can be found in 467 Section 6. 469 3.2.2 Client to Surrogate to Origin Server 471 A client may communicate with zero or more surrogates for requests 472 intended for one or more origin servers. Where a surrogate is not 473 used, the client communicates directly with an origin server. Where 474 a surrogate is used the client communicates as if with an origin 475 server. The surrogate fulfills the request from its internal cache, 476 or acts as a gateway or tunnel to the origin server. 478 -------------- -------------- -------------- 479 | Origin | | Origin | | Origin | 480 | Server | | Server | | Server | 481 -------------- -------------- -------------- 482 \ | / 483 \ | / 484 ----------------- 485 | Surrogate | 486 | | 487 ----------------- 488 | 489 | 490 ------------ 491 | Client | 492 ------------ 494 3.2.3 Inter-Proxy 496 Inter-Proxy relationships exist as meshes (loosely coupled) and 497 clusters (tightly coupled). 499 3.2.3.1 (Caching) Proxy Meshes 501 Within a loosely coupled mesh of (caching) proxies, communication 502 can happen at the same level between peers, and with one or more 503 parents. 505 --------------------- --------------------- 506 -----------| Intermediate | | Intermediate | 507 | | Caching Proxy (D) | | Caching Proxy (E) | 508 |(peer) --------------------- --------------------- 509 -------------- | (parent) / (parent) 510 | Cache | | ------/ 511 | Server (C) | | / 512 -------------- | / 513 (peer) | ----------------- --------------------- 514 -------------| Local Caching |-------| Intermediate | 515 | Proxy (A) | (peer)| Caching Proxy (B) | 516 ----------------- --------------------- 517 | 518 | 519 ---------- 520 | Client | 521 ---------- 523 Client included for illustration purposes only 525 An inbound request may be routed to one of a number of intermediate 526 (caching) proxies based on a determination of whether that parent is 527 better suited to resolving the request. 529 For example, in the above figure, Cache Server C and Intermediate 530 Caching Proxy B are peers of the Local Caching Proxy A, and may only 531 be used when the resource requested by A already exists on either B 532 or C. Intermediate Caching Proxies D & E are parents of A, and it is 533 A's choice of which to use to resolve a particular request. 535 The relationship between A & B only makes sense in a caching 536 environment, while the relationships between A & D and A & E are 537 also appropriate where D or E are non-caching proxies. 539 Protocols used in these relationships can be found in Section 7.1. 541 3.2.3.2 (Caching) Proxy Arrays 543 Where a user agent may have a relationship with a proxy, it is 544 possible that it may instead have a relationship with an array of 545 proxies arranged in a tightly coupled mesh. 547 ---------------------- 548 ---------------------- | 549 --------------------- | | 550 | (Caching) Proxy | |----- 551 | Array |----- ^ ^ 552 --------------------- ^ ^ | | 553 ^ ^ | |--- | 554 | |----- | 555 -------------------------- 557 Protocols used in this relationship can be found in Section 7.2. 559 3.2.4 Network Element to Caching Proxy 561 A network element performing traffic interception may choose to 562 redirect requests from a client to a specific proxy within an array. 563 (It may also choose not to redirect the traffic, in which case the 564 relationship is between client and (replica) origin server, see 565 Section 3.1.1.) 566 ----------------- ----------------- ----------------- 567 | Caching Proxy | | Caching Proxy | | Caching Proxy | 568 | Array | | Array | | Array | 569 ----------------- ----------------- ----------------- 570 \ | / 571 ----------------------------------------- 572 | 573 -------------- 574 | Network | 575 | Element | 576 -------------- 577 | 578 /// 579 | 580 ------------ 581 | Client | 582 ------------ 584 The interception proxy may be directly in-line of the flow of 585 traffic - in which case the intercepting network element and 586 interception proxy form parts of the same hardware system - or may 587 be out-of-path, requiring the intercepting network element to 588 redirect traffic to another network segment. In this latter case, 589 communication protocols enable the intercepting network element to 590 stop and start redirecting traffic when the interception proxy 591 becomes (un)available. Details of these protocols can be found in 592 Section 8. 594 4. Replica Selection 596 This section describes the schemes and protocols used in the 597 cooperation and communication between client and replica origin web 598 servers. The ideal situation is to discover an optimal replica 599 origin server for clients to communicate with. Optimality is a 600 policy based decision, often based upon proximity, but may be based 601 on other criteria such as load. 603 4.1 Navigation Hyperlinks 605 Authoritative reference: 606 This memo. 608 Description: 609 The simplest of client to replica communication mechanisms. This 610 utilizes hyperlink URIs embedded in web pages that point to the 611 individual replica origin servers. The content consumer manually 612 selects the link of the replica origin server they wish to use. 614 Security: 615 Relies on the protocol security associated with the appropriate 616 URI scheme. 618 Deployment: 619 Probably the most commonly deployed client to replica 620 communication mechanism. Ubiquitous interoperability with humans. 622 Submitter: 623 Document editors. 625 4.2 HTTP Redirection 627 Authoritative reference: 628 This memo. 630 Description: 631 A simple and commonly used mechanism to connect clients with 632 replica origin servers is to use HTTP redirection. Clients are 633 redirected to an optimal replica origin server via the use of the 634 HTTP[1] protocol response codes, e.g. 302 "Found", or 307 635 "Temporary Redirect". A client establishes HTTP communication 636 with one of the replica origin servers. The initially contacted 637 replica origin server can then either choose to accept the 638 service or redirect the client again. Refer to section 10.3 in 639 HTTP/1.1[1] for information on HTTP response codes. 641 Security: 642 Relies entirely upon HTTP security. 644 Deployment: 645 Observed at a number of large web sites. Extent of usage in the 646 Internet is unknown. 648 Submitter: 649 Document editors. 651 4.3 DNS Redirection 653 Authoritative reference: 655 * RFC1794 DNS Support for Load Balancing Proximity[15] 657 * This memo 659 Description: 660 The Domain Name Service (DNS) provides a more sophisticated 661 client to replica communication mechanism. This is accomplished 662 by DNS servers that sort resolved IP addresses based upon quality 663 of service policies. When a client resolves the name of an origin 664 server, the enhanced DNS server sorts the available IP addresses 665 of the replica origin servers starting with the most optimal 666 replica and ending with the least optimal replica. 668 Security: 669 Relies entirely upon DNS security, and other protocols that may 670 be used in determining the sort order. 672 Deployment: 673 Observed at a number of large web sites and large ISP web hosted 674 services. Extent of usage in the Internet is unknown, but is 675 believed to be increasing. 677 Submitter: 678 Document editors. 680 5. Inter-Replica Communication 682 This section describes the cooperation and communication between 683 master- and replica- origin servers. Used in replicating data sets 684 between origin servers. 686 5.1 Batch Driven Replication 688 Authoritative reference: 689 This memo. 691 Description: 692 The replica origin server to be updated initiates communication 693 with a master origin server. The communication is established at 694 intervals based upon queued transactions which are scheduled for 695 deferred processing. The scheduling mechanism policies vary, but 696 generally are re-occurring at a specified time. Once 697 communication is established, data sets are copied to the 698 initiating replica origin server. 700 Security: 701 Relies upon the protocol being used to transfer the data set. 702 FTP[10] and RDIST are the most common protocols observed. 704 Deployment: 705 Very common for synchronization of mirror sites in the Internet. 707 Submitter: 708 Document editors. 710 5.2 Demand Driven Replication 712 Authoritative reference: 713 This memo. 715 Description: 716 Replica origin servers acquire content as needed due to client 717 demand. When a client requests a resource that is not in the 718 data set of the replica origin server/surrogate, an attempt is 719 made to resolve the request by acquiring the resource from the 720 master origin server, returning it to the requesting client. 722 Security: 723 Relies upon the protocol being used to transfer the resources. 724 FTP[10], Gopher[11], HTTP[1] and ICP[5] are the most common 725 protocols observed. 727 Deployment: 728 Observed at several large web sites. Extent of usage in the 729 Internet is unknown. 731 Submitter: 732 Document editors. 734 5.3 Synchronized Replication 736 Authoritative reference: 737 This memo. 739 Ed note: there is no IETF protocol specified at this time. The 740 editors are aware of at least two open source protocols, AFS 741 and CODA, along with one expired IETF draft 742 and one proprietary protocol 743 Novell NRS; none of which can be considered an authoritative 744 reference. 746 Description: 747 Replicated origin servers cooperate using synchronized strategies 748 and specialized replica protocols to keep the replica data sets 749 coherent. Synchronization strategies range from tightly coherent 750 (a few minutes) to loosely coherent (a few or more hours). 751 Updates occur between replicas based upon the synchronization 752 time constraints of the coherency model employed and are 753 generally in the form of deltas only. 755 Security: 756 All of the known protocols utilize strong cryptographic key 757 exchange methods, which are either based upon the Kerberos shared 758 secret model or the public/private key RSA model. 760 Deployment: 761 Observed at a few sites, primarily at university campuses. 763 Submitter: 764 Document editors. 766 6. User Agent to Proxy Configuration 768 This section describes the configuration, cooperation and 769 communication between user agents and proxies. 771 6.1 Manual Proxy Configuration 773 Authoritative reference: 774 This memo. 776 Description: 777 Each user must configure her user agent by supplying information 778 pertaining to proxied protocols and local policies. 780 Security: 781 The potential for doing wrong is high; each user individually 782 sets preferences. 784 Deployment: 785 Widely deployed, used in all current browsers. Most browsers also 786 support additional options. 788 Submitter: 789 Document editors. 791 6.2 Proxy Auto Configuration (PAC) 793 Authoritative reference: 794 No RFC, no Internet-Draft; Navigator Proxy Auto-Config File 795 Format[2]. 797 Description: 798 A JavaScript script retrieved from a web server is executed for 799 each URL accessed to determine the appropriate proxy (if any) to 800 be used to access the resource. User agents must be configured to 801 request this script upon startup. There is no bootstrap 802 mechanism, manual configuration is necessary. 804 Despite manual configuration, the process of proxy configuration 805 is simplified by centralizing it within a script at a single 806 location. 808 Security: 809 Common policy per organization possible but still requires 810 initial manual configuration. PAC is better than "manual proxy 811 configuration" since PAC administrators may update the proxy 812 configuration without further user intervention. 814 Interoperability of PAC files is not high, since different 815 browsers have slightly different interpretations of the same 816 script, possibly leading to undesired effects. 818 Deployment: 819 Implemented in Netscape Navigator and Microsoft Internet Explorer. 821 Submitter: 822 Document editors. 824 6.3 Cache Array Routing Protocol (CARP) v1.0 826 Authoritative reference: 827 Expired Internet-Draft: draft-vinod-carp-v1-03.txt[4] 829 Note: Reference kept since there is known implementation. 831 Description: 832 User agents may use CARP directly as a hash function based proxy 833 selection mechanism. They need to be configured with the location 834 of the cluster information. 836 Security: 837 Security considerations are not covered in the specification 838 drafts. 840 Deployment: 841 Implemented in Microsoft Proxy Server, Squid. Implemented in user 842 agents via PAC scripts. 844 Submitter: 845 Document editors. 847 6.4 Web Proxy Auto-Discovery Protocol (WPAD) 849 Authoritative reference: 850 Expired Internet-Draft: draft-ietf-wrec-wpad-01.txt[3] 852 Description: 853 WPAD uses a collection of pre-existing Internet resource 854 discovery mechanisms to perform web proxy auto-discovery. 856 The only goal of WPAD is to locate the PAC URL[2]. WPAD does not 857 specify which proxies will be used. WPAD supplies the PAC URL, 858 and the PAC script then operates as defined above to choose 859 proxies per resource request. 861 The WPAD protocol specifies the following: 863 * how to use each mechanism for the specific purpose of web 864 proxy auto-discovery 866 * the order in which the mechanisms should be performed 868 * the minimal set of mechanisms which must be attempted by a 869 WPAD compliant user agent 871 The resource discovery mechanisms utilized by WPAD are as 872 follows: 874 * Dynamic Host Configuration Protocol DHCP 876 * Service Location Protocol SLP 878 * "Well Known Aliases" using DNS A records 880 * DNS SRV records 882 * "service: URLs" in DNS TXT records 884 Security: 885 Relies upon DNS and HTTP security. 887 Deployment: 888 Implemented in user agents and caching proxy servers. More than 889 two independent implementations. 891 Submitter: 892 Josh Cohen, Microsoft, joshco@microsoft.com 894 7. Inter-Proxy Communication 896 7.1 Loosely coupled Inter-Proxy Communication 898 This section describes the cooperation and communication between 899 caching proxies. 901 7.1.1 Internet Cache Protocol (ICP) 903 Authoritative reference: 904 RFC2186 Internet Cache Protocol (ICP), version 2[5] 906 Description: 907 ICP is used by proxies to query other (caching) proxies about web 908 resources, to see if the requested resource is present on the 909 other system. 911 ICP uses UDP. Since UDP is an uncorrected network transport 912 protocol, an estimate of network congestion and availability may 913 be calculated by ICP loss. This rudimentary loss measurement 914 provides, together with round trip times, a load balancing method 915 for caches. 917 Security: 918 See RFC2187[6] 920 ICP does not convey information about HTTP headers associated 921 with resources. HTTP headers may include access control and cache 922 directives. Since proxies ask for the availability of resources, 923 and subsequently retrieve them using HTTP, false cache hits may 924 occur (object present in cache, but not accessible to a sibling 925 is one example). 927 ICP suffers from all the security problems of UDP. 929 Deployment: 930 Widely deployed. Most current caching proxy implementations 931 support ICP in some form. 933 Submitter: 934 Document editors. 936 See also Internet-Draft draft-lovric-icp-ext-02.txt[7], ICP 937 development Web page[8], ICP1.4 specification[9]. 939 7.1.2 Hyper Text Caching Protocol 941 Authoritative reference: 942 RFC2756 Hyper Text Caching Protocol (HTCP/0.0)[18] 944 Description: 945 HTCP is a protocol for discovering HTTP caching proxies and 946 cached data, managing sets of HTTP caching proxies, and 947 monitoring cache activity. 949 HTCP requests include HTTP header material, while ICPv2 does not, 950 enabling HTCP replies to more accurately describe the behaviour 951 that would occur as a result of a subsequent HTTP request for the 952 same resource. 954 Security: 955 Optionally uses HMAC-MD5[20] shared secret authentication. 956 Protocol is subject to attack if authentication is not used. 958 Deployment: 959 HTCP is implemented in Squid[24] and the Web Gateway 960 Interceptor[25]. 962 Submitter: 963 Document editors. 965 7.1.3 Cache Digest 967 Authoritative reference: 969 * No RFC, no Internet-Draft; Cache Digest specification - 970 version 5[17] 972 * Summary Cache[19](see note) 974 Description: 975 Cache Digests are a response to the problems of latency and 976 congestion associated with previous inter-cache communication 977 mechanisms such as the Internet Cache Protocol (ICP)[5] and the 978 Hyper Text Cache Protocol[18]. Unlike these protocols, Cache 979 Digests support peering between caching proxies and cache servers 980 without a request-response exchange taking place for each inbound 981 request. Instead, a summary of the contents in cache (the Digest) 982 is fetched by other systems that peer with it. Using Cache 983 Digests it is possible to determine with a relatively high degree 984 of accuracy whether a given resource is cached by a particular 985 system. 987 Cache Digests are both an exchange protocol and a data format [17] 989 Security: 990 If the contents of a Digest are sensitive, they should be 991 protected. Any methods which would normally be applied to secure 992 an HTTP connection can be applied to Cache Digests. 994 A 'Trojan horse' attack is currently possible in a mesh: System A 995 A can build a fake peer Digest for system B and serve it to B's 996 peers if requested. This way A can direct traffic toward/from B. 997 The impact of this problem is minimized by the 'pull' model of 998 transferring Cache Digests from one system to another. 1000 Cache Digests provide knowledge about peer cache content on a URL 1001 level. Hence, they do not dictate a particular level of policy 1002 management and can be used to implement various policies on any 1003 level (user, organization, etc.). 1005 Deployment: 1006 Cache Digests are supported in Squid. 1008 Cache Meshes: 1010 * NLANR Mesh[26] 1012 * TF-CACHE mesh[27] (European Academic networks) 1014 Submitter: 1015 Alex Rousskov, NLANR, rousskov@nlanr.net for [17] 1016 Pei Cao for [19] 1018 Note: The technology of Summary Cache[19]is patent pending by the 1019 University of Wisconsin-Madison. 1021 7.1.4 Cache Pre-filling 1023 Authoritative reference: 1024 Internet-Draft: draft-lovric-francetelecom-satellites-01.txt[16] 1026 Description: 1027 Cache pre-filling is a push-caching implementation. It is 1028 particularly well adapted to IP-multicast networks because it 1029 allows preselected resources to be simultaneously inserted into 1030 caches within the targeted multicast group. Different 1031 implementations of cache pre-filling already exist, especially in 1032 satellite contexts. However, there is still no standard for this 1033 kind of push-caching and vendors propose solutions either based 1034 on dedicated equipment or public domain caches extended with a 1035 pre-filling module. 1037 Security: 1038 Relies on the inter-cache protocols being employed. 1040 Deployment: 1041 Observed in two commercial content distribution service providers. 1043 Submitter: 1044 Ivan Lovric, France Telecom, ivan.lovric@cnet.francetelecom.fr 1046 7.2 Tightly Coupled Inter-Cache Communication 1048 7.2.1 Cache Array Routing Protocol (CARP) v1.0 1050 Also see Section 6.3 1052 Authoritative reference: 1053 Expired Internet-Draft: draft-vinod-carp-v1-03.txt[4] 1055 Note: Reference kept since there is known deployment. 1057 Description: 1058 CARP is a hashing function for dividing URL-space among a cluster 1059 of proxies. Included in CARP is the definition of a Proxy Array 1060 Membership Table, and ways to download this information. 1062 A user agent which implements CARP v1.0 can allocate and 1063 intelligently route requests for the URLs to any member of the 1064 Proxy Array. Due to the resulting sorting of requests through 1065 these proxies, duplication of cache contents is eliminated and 1066 global cache hit rates may be improved. 1068 Security: 1069 Security considerations are not covered in the specification 1070 drafts. 1072 Deployment: 1073 Implemented in caching proxy servers. More than two independent 1074 implementations. 1076 Submitter: 1077 Document editors. 1079 8. Network Element Communication 1081 This section describes the cooperation and communication between 1082 proxies and network elements. Examples of such network elements 1083 include routers and switches. Generally used for deploying 1084 interception proxies and/or diffused arrays. 1086 8.1 Web Cache Control Protocol (WCCP) 1088 Authoritative reference: 1089 Expired Internet-Draft: draft-ietf-wrec-web-pro-00.txt[13] 1091 Description: 1092 WCCP V1 runs between a router functioning as a redirecting 1093 network element and out-of-path interception proxies. The 1094 protocol allows one or more proxies to register with a single 1095 router to receive redirected traffic. It also allows one of the 1096 proxies, the designated proxy, to dictate to the router how 1097 redirected traffic is distributed across the array. 1099 Security: 1100 WCCP V1 has no security features. 1102 Deployment: 1103 Network elements: WCCP V1 is deployed on a wide range of Cisco 1104 routers. 1105 Caching proxies: WCCP V1 is deployed on a number of vendors' 1106 caching proxies. 1108 Submitter: 1109 David Forster, CISCO, dforster@cisco.com 1111 8.2 Network Element Control Protocol (NECP) 1113 Authoritative reference: 1114 draft-cerpa-necp-02.txt[21] 1116 Description: 1117 NECP provides methods for network elements to learn about server 1118 capabilities, availability, and hints as to which flows can and 1119 cannot be serviced. This allows network elements to perform load 1120 balancing across a farm of servers, redirection to interception 1121 proxies, and cut-through of flows that cannot be served by the 1122 farm. 1124 Security: 1125 Optionally uses HMAC-SHA-1[20] shared secret authentication along 1126 with complex sequence numbers to provide moderately strong 1127 security. Protocol is subject to attack if authentication is not 1128 used. 1130 Deployment: 1131 NECP is a new protocol being implemented by more than two network 1132 element vendors and by more than two caching proxy vendors. It is 1133 anticipated to be broadly deployed in the Internet during the 1134 year 2000. 1136 Submitter: 1137 Gary Tomlinson, Novell, garyt@novell.com 1139 8.3 SOCKS 1141 Authoritative reference: 1142 RFC1928 SOCKS Protocol Version 5[14] 1144 Description: 1145 SOCKS is primarily used as a caching proxy to firewall protocol. 1146 Although firewalls don't conform to the narrowly defined network 1147 element definition above, they are a integral part of the network 1148 infrastructure. When used in conjunction with a firewall, SOCKS 1149 provides a authenticated tunnel between the caching proxy and the 1150 firewall. 1152 Security: 1153 An extensive framework provides for multiple authentication 1154 methods. Currently, SSL, CHAP, DES, 3DES are known to be 1155 available. 1157 Deployment: 1158 SOCKS is been widely deployed in the Internet. 1160 Submitter: 1161 Document editors. 1163 9. Security Considerations 1165 This document provides a taxonomy for web caching and replication. 1166 Recommended practice, architecture and protocols are not described 1167 in detail. 1169 By definition, replication and caching involve the copying of 1170 resources. There are legal implications of making and keeping 1171 transient or permanent copies; these are not covered here. 1173 Information on security of each protocol referred to by this memo is 1174 provided in the preceding sections, and in their accompanying 1175 documentation. HTTP security is discussed in section 15 of 1176 RFC2616[1], the HTTP/1.1 specification, and to a lesser extent in 1177 RFC1945[12], the HTTP/1.0 specification. RFC2616 contains security 1178 considerations for HTTP proxies. 1180 Caching proxies have the same security issues as other application 1181 level proxies. Application level proxies are not covered in these 1182 security considerations. IP number based authentication is 1183 problematic when a proxy is involved in the communications. Details 1184 are not discussed here. 1186 9.1 Authentication 1188 Requests for web resources, and responses to such requests, may be 1189 directed to replicas and/or may flow through intermediate proxies. 1190 The integrity of communication needs to be preserved to ensure 1191 protection from both loss of access and from unintended change. 1193 9.1.1 Man in the middle attacks 1195 HTTP proxies are men-in-the-middle, the perfect place for a 1196 man-in-the-middle-attack. A discussion of this is found in section 1197 15 of RFC2616[1]. 1199 9.1.2 Trusted third party 1201 A proxy must either be trusted to act on behalf of the origin server 1202 and/or client, or it must act as a tunnel. When presenting cached 1203 objects to clients, the clients need to trust the caching proxy to 1204 act on behalf on the origin server. 1206 A replica may get accreditation from the origin server. 1208 9.1.3 Authentication based on IP number 1210 Authentication based on the client's IP number is problematic when 1211 connecting through a proxy, since the authenticating device only has 1212 access to the proxy's IP number. One (problematic) solution to this 1213 is for the proxy to spoof the client's IP number for inbound 1214 requests. 1216 Authentication based on IP number assumes that the end-to-end 1217 properties of the Internet are preserved. This is typically not the 1218 case for environments containing interception proxies. 1220 9.2 Privacy 1222 9.2.1 Trusted third party 1224 When using a replication service, one must trust both the replica 1225 origin server and the replica selection system. 1227 Redirection of traffic - either by automated replica selection 1228 methods, or within proxies - may introduce third parties the end 1229 user and/or origin server must to trust. In the case of interception 1230 proxies, such third parties are often unknown to both end points of 1231 the communication. Unknown third parties may have security 1232 implications. 1234 Both proxies and replica selection services may have access to 1235 aggregated access information. A proxy typically knows about 1236 accesses by each client using it, information that is more sensitive 1237 than the information held by a single origin server. 1239 9.2.2 Logs and legal implications 1241 Logs from proxies should be kept secure, since they provide 1242 information about users and their patterns of behaviour. A proxy's 1243 log is even more sensitive than a web server log, as every request 1244 from the user population goes through the proxy. Logs from replica 1245 origin servers may need to be amalgamated to get aggregated 1246 statistics from a service, and transporting logs across borders may 1247 have legal implications. Log handling is restricted by law in some 1248 countries. 1250 Requirements for object security and privacy are the same in a web 1251 replication and caching system as it is in the Internet at large. 1252 The only reliable solution is strong cryptography. End-to-end 1253 encryption frequently makes resources uncacheable, as in the case of 1254 SSL encrypted web sessions. 1256 9.3 Service security 1257 9.3.1 Denial of service 1259 Any redirection of traffic is susceptible to denial of service 1260 attacks at the redirect point, and both proxies and replica 1261 selection services may redirect traffic. 1263 By attacking a proxy, access to all servers may be denied for a 1264 large set of clients. 1266 It has been argued that introduction of an interception proxy is a 1267 denial of service attack, since the end-to-end nature of the 1268 Internet is destroyed without the content consumer's knowledge. 1270 9.3.2 Replay attack 1272 A caching proxy is by definition a replay attack. 1274 9.3.3 Stupid configuration of proxies 1276 It is quite easy to have a stupid configuration which will harm 1277 service for content consumers. This is the most common security 1278 problem with proxies. 1280 9.3.4 Copyrighted transient copies 1282 The legislative forces of the world are considering the question of 1283 transient copies, like those kept in replication and caching system, 1284 being legal. The legal implications of replication and caching are 1285 subject to local law. 1287 Caching proxies need to preserve the protocol output, including 1288 headers. Replication services need to preserve the source of the 1289 objects. 1291 9.3.5 Application level access 1293 Caching proxies are application level components in the traffic flow 1294 path, and may give intruders access to information that was 1295 previously only available at the network level in a proxy-free 1296 world. Some network level equipment may have required physical 1297 access to get sensitive information. Introduction of application 1298 level components may require additional system security. 1300 10. Acknowledgements 1302 The editors would like to thank the following for their assistance: 1303 David Forster, Alex Rousskov, Josh Cohen, John Martin, John Dilley, 1304 Ivan Lovric, Joe Touch, Henrik Nordstrom, Patrick McManus, Duane 1305 Wessels, Wojtek Sylwestrzak, Ted Hardie, Misha Rabinovich, Larry 1306 Masinter, Keith Moore, Roy Fielding, Patrick Faltstrom, Hilarie 1307 Orman, Mark Nottingham and Oskar Batuner. 1309 References 1311 [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 1312 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol 1313 -- HTTP/1.1", RFC 2616, June 1999, 1314 . 1316 [2] Netscape, Inc., "Navigator Proxy Auto-Config File Format", 1317 March 1996, 1318 . 1321 [3] Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web 1322 Proxy Auto-Discovery Protocol", draft-ietf-wrec-wpad-01.txt 1323 (work in progress), July 1999, 1324 . 1326 [4] Valloppillil, V. and K.W. Ross, "Cache Array Routing 1327 Protocol", draft-vinod-carp-v1-03.txt (work in progress), 1328 February 1998, 1329 . 1331 [5] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), 1332 Version 2", RFC 2186, September 1997, 1333 . 1335 [6] Wessels, D. and K. Claffy, "Application of Internet Cache 1336 Protocol (ICP), Version 2", RFC 2187, September 1997, 1337 . 1339 [7] Lovric, I., "Internet Cache Protocol Extension", 1340 draft-lovric-icp-ext-02.txt (work in progress), October 1999, 1341 . 1343 [8] Wessels, D., "ICP Home Page", July 1999, 1344 . 1346 [9] University of Southern California and University of 1347 Colorado-Boulder, "Internet Cache Protocol Specification 1.4", 1348 September 1994, 1349 . 1351 [10] Postel, J. and J.K. Reynolds, "File Transfer Protocol (FTP)", 1352 RFC 959, Oct 1985, 1353 . 1355 [11] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., 1356 Torrey, D. and B. Alberti, "The Internet Gopher Protocol", RFC 1357 1436, Mar 1993, 1358 . 1360 [12] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext 1361 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996, 1362 . 1364 [13] Cieslak, M. and D. Forster, "Cisco Web Cache Control Protocol 1365 V1.0", draft-ietf-wrec-web-pro-00.txt (work in progress), June 1366 1999, 1367 . 1369 [14] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. 1370 Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996, 1371 . 1373 [15] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1374 1995, 1375 . 1377 [16] Goutard, C., Lovric, I. and E. Maschio-Esposito, "Pre-filling 1378 a cache - A satellite overview", 1379 draft-lovric-francetelecom-satellites-01.txt (work in 1380 progress), February 2000, 1381 . 1384 [17] Hamilton, M., Rousskov, A. and D. Wessels, "Cache Digest 1385 specification - version 5", December 1998, 1386 . 1389 [18] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol 1390 (HTCP/0.0)", RFC 2756, January 2000, 1391 . 1393 [19] Fan, L., Cao, P., Almeida, J. and A. Broder, "Summary Cache: A 1394 Scalable Wide-Area Web Cache Sharing Protocol", Proceedings of 1395 ACM SIGCOMM'98 pp. 254-265, September 1998, 1396 . 1398 [20] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 1399 for Message Authentication", RFC 2104, February 1997, 1400 . 1402 [21] Cerpa, A., Elson, J., Beheshti, H., Chankhunthod, A., Danzig, 1403 P., Jalan, R., Neerdaels, C., Shroeder, T. and G. Tomlinson, 1404 "NECP: The Network Element Control Protocol", 1405 draft-cerpa-necp-02.txt (work in progress), February 2000, 1406 . 1409 [22] FOLDOC, "Free Online Dictionary of Computing: Replication", 1410 December 1997, 1411 . 1413 [23] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", 1414 draft-ietf-wrec-known-prob-02.txt (work in progress), July 1415 2000, 1416 . 1419 [24] 1421 [25] 1423 [26] 1425 [27] 1427 Authors' Addresses 1429 Ian Cooper 1430 Mirror Image Internet, Inc. 1431 49 Dragon Court 1432 Woburn, MA 01801 1433 USA 1435 Phone: +1 781 376 1109 1436 EMail: ian.cooper@mirror-image.com 1438 Ingrid Melve 1439 UNINETT 1440 Tempeveien 22 1441 Trondheim N-7465 1442 Norway 1444 Phone: +47 73 55 79 07 1445 EMail: Ingrid.Melve@uninett.no 1446 Gary Tomlinson 1447 Novell Inc. 1448 122 East 1700 South 1449 Provo, Utah 84606 1450 USA 1452 Phone: +1 801 861 7021 1453 EMail: garyt@novell.com 1455 Full Copyright Statement 1457 Copyright (C) The Internet Society (2000). All Rights Reserved. 1459 This document and translations of it may be copied and furnished to 1460 others, and derivative works that comment on or otherwise explain it 1461 or assist in its implementation may be prepared, copied, published 1462 and distributed, in whole or in part, without restriction of any 1463 kind, provided that the above copyright notice and this paragraph 1464 are included on all such copies and derivative works. However, this 1465 document itself may not be modified in any way, such as by removing 1466 the copyright notice or references to the Internet Society or other 1467 Internet organizations, except as needed for the purpose of 1468 developing Internet standards in which case the procedures for 1469 copyrights defined in the Internet Standards process must be 1470 followed, or as required to translate it into languages other than 1471 English. 1473 The limited permissions granted above are perpetual and will not be 1474 revoked by the Internet Society or its successors or assigns. 1476 This document and the information contained herein is provided on an 1477 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1478 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1479 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1480 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1481 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1483 Acknowledgement 1485 Funding for the RFC editor function is currently provided by the 1486 Internet Society.