Network Working Group I. Melve Internet-Draft UNINETT Expires: April 19, 2000 G. Tomlinson Novell I. Cooper Mirror Image October 20, 1999 Internet Web Replication and Caching Taxonomy draft-ietf-wrec-taxonomy-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2000. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo specifies standard terminology and the current taxonomy of web replication and caching infrastructure deployed today. It introduces standard concepts and protocols uses today within this application domain. Currently deployed solutions employing this technologies are presented to establish a standard taxonomy. Research issues and HTTP proxy caching known problems are covered in two accompanying document, and are not part of this document. This document presents open protocols and points to published RFCs for each protocol. Melve, et. al. Expires April 19, 2000 [Page 1] Internet-Draft WREC Taxonomy October 1999 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Base Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 First order derivative terms . . . . . . . . . . . . . . . 7 2.3 Second order derivatives . . . . . . . . . . . . . . . . . 7 2.4 Topological terms . . . . . . . . . . . . . . . . . . . . 8 2.5 Automatic use of proxies . . . . . . . . . . . . . . . . . 8 3. Distributed System Relationships . . . . . . . . . . . . . 10 3.1 Replication Relationships . . . . . . . . . . . . . . . . 10 3.1.1 Client to Replica . . . . . . . . . . . . . . . . . . . . 10 3.1.2 Inter-Replica . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Proxy Relationships . . . . . . . . . . . . . . . . . . . 11 3.2.1 Client to Non-Network Transparent Proxy . . . . . . . . . 11 3.2.2 Reverse Proxy to Origin Server . . . . . . . . . . . . . . 11 3.2.3 Inter-Cache . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3.1 (Caching) Proxy Meshes . . . . . . . . . . . . . . . . . . 12 3.2.3.2 (Caching) Proxy Clusters . . . . . . . . . . . . . . . . . 13 3.2.4 Network Element to Caching Proxy . . . . . . . . . . . . . 14 4. Client to Replica Communication . . . . . . . . . . . . . 15 4.1 Navigation Hyperlinks . . . . . . . . . . . . . . . . . . 15 4.2 URL Redirection . . . . . . . . . . . . . . . . . . . . . 15 4.3 DNS Redirection . . . . . . . . . . . . . . . . . . . . . 16 5. Inter-Replica Communication . . . . . . . . . . . . . . . 17 5.1 Batch Driven Mirror Replication . . . . . . . . . . . . . 17 5.2 Demand Driven Mirror Replication . . . . . . . . . . . . . 17 5.3 Synchronized Replication . . . . . . . . . . . . . . . . . 18 6. Client to Proxy Configuration . . . . . . . . . . . . . . 19 6.1 Manual Proxy Configuration . . . . . . . . . . . . . . . . 19 6.2 Proxy Auto Configuration (PAC) . . . . . . . . . . . . . . 19 6.3 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 20 6.4 Web Proxy Auto-Discovery Protocol (WPAD) . . . . . . . . . 20 7. Inter-Cache Communication . . . . . . . . . . . . . . . . 22 7.1 Loosely coupled Inter-Cache Communication . . . . . . . . 22 7.1.1 Internet Cache Protocol (ICP) . . . . . . . . . . . . . . 22 7.1.2 Hyper Text Caching Protocol (HTCP/0.0) . . . . . . . . . . 22 7.1.3 Cache Digest . . . . . . . . . . . . . . . . . . . . . . . 23 7.1.4 Cache Pre-filling . . . . . . . . . . . . . . . . . . . . 24 7.2 Tightly Coupled Inter-Cache Communication . . . . . . . . 25 7.2.1 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 25 8. Network Element Communication . . . . . . . . . . . . . . 26 8.1 Web Cache Coordination Protocol (WCCP) . . . . . . . . . . 26 8.2 SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . 28 9.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 28 9.1.1 Man in the middle attacks . . . . . . . . . . . . . . . . 28 9.1.2 Trusted third party . . . . . . . . . . . . . . . . . . . 28 9.1.3 Authentication based on IP number . . . . . . . . . . . . 29 Melve, et. al. Expires April 19, 2000 [Page 2] Internet-Draft WREC Taxonomy October 1999 9.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.2.1 Trusted third party . . . . . . . . . . . . . . . . . . . 29 9.2.2 Logs and legal implications . . . . . . . . . . . . . . . 29 9.3 Service security . . . . . . . . . . . . . . . . . . . . . 30 9.3.1 Denial of service . . . . . . . . . . . . . . . . . . . . 30 9.3.2 Replay attack . . . . . . . . . . . . . . . . . . . . . . 30 9.3.3 Stupid configuration of proxies . . . . . . . . . . . . . 30 9.3.4 Copyrighted transient copies . . . . . . . . . . . . . . . 30 9.3.5 Application level access . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 31 References . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 33 Full Copyright Statement . . . . . . . . . . . . . . . . . 35 Melve, et. al. Expires April 19, 2000 [Page 3] Internet-Draft WREC Taxonomy October 1999 1. Introduction Since its introduction in 1990, the World-Wide Web has evolved from a simple client server model into a sophisticated distributed architecture. This evolution has been driven largely due to the scaling problems associated with exponential growth. Distinct paradigms and solutions have emerged to satisfy specific requirements. Two core infrastructural components being employed to meet the demands of this growth are replication and caching. In man cases, there is a need for web caches and replicated services to be able to coexist. There are many protocols, both open and proprietary, employed in web replication and caching today. A majority of the open protocols include DNS[19], CacheDigest[22], CARP[9], HTTP[6], ICP[10], PAC[7], SOCKS[17], TPACT[20], WPAD[8], and WCCP[16]. Additional protocols are being planned to address emerging solution requirements. This memo specifies standard terminology and the current taxonomy of web replication and caching infrastructure deployed in the Internet today. The principal goal of this document is to establish a common understanding and reference point of this application domain. We also expect that this document will be used in the creation of a standard architectural framework for efficient, reliable, and predictable service in a web which includes both replicas and caches. Melve, et. al. Expires April 19, 2000 [Page 4] Internet-Draft WREC Taxonomy October 1999 2. Terminology The following terminology provides definitions of common terms used within the IETF WREC working group documents. Base terms are taken, where possible, from [5][6] and are included here for reference. From these base terms we describe first- and second-order derivatives as well as terms that describe common structural language used within the community. We highlight those terms that have become used colloquially to mean something other than the definitions given in this document, and strongly caution against such colloquial use in the future. 2.1 Base Terms The majority of these terms are taken as-is from RFC 2616[6], and are included here for reference. client (as given in [6]) A program that establishes connections for the purpose of sending requests. server (as given in [6]) An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request. proxy (as given in [6]) An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies. Note: The term "transparent proxy" refers to a semantically Melve, et. al. Expires April 19, 2000 [Page 5] Internet-Draft WREC Taxonomy October 1999 transparent proxy as described in [6], not what is commonly understood within the caching community. We recommend that the term "transparent proxy" is always prefixed to avoid confusion (e.g. "network transparent proxy"). The above condition requiring implementation of both the server and client requirements of HTTP/1.1 is only appropriate for a non-transparent proxy. cache (as given in [6]) A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. Note: The term "cache" used alone often is meant as "caching proxy". Ed.Note;IAN: This is the actual definition from RFC2616, but now excludes consideration of a reduction in server load. Do we wish to comment on that, is is response time related to server load in such a way that the comment is unnecessary? cacheable (as given in [6]) A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in section 13. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request. tunnel (as given in [6]) An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed. Ed.Note;IAN: Should consider comments from Joe Touch on whether we should distinguish types of tunnels replica [ TBC ] replication [ TBC ] inbound/outbound (as given in [6]) Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", Melve, et. al. Expires April 19, 2000 [Page 6] Internet-Draft WREC Taxonomy October 1999 and "outbound" means "traveling toward the user agent". network element A network device that introduces multiple paths between source and destination, transparent to HTTP. 2.2 First order derivative terms The following terms are constructed taking the above base terms as foundation. origin server (as given in [6]) The server on which a given resource resides or is to be created. user agent (as given in [6]) The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools. caching proxy A proxy with a cache, acting as a server to clients, and a client to servers. Caching proxies are often referred to as "proxy caches" or simply "caches". The term "proxy" is also observed to be used for caching proxies. surrogate (a.k.a. "reverse proxies", "server accelerators") An intermediary program which acts as a server or tunnel for the purpose of responding to requests on behalf of one or more origin servers. Requests are serviced internally from a cache or by tunneling them on to origin servers. The implementation requirements for surrogates have not been standardized; depending on the implementation, surrogates may or may not respond to the cache directives defined in [6]. Surrogates are also known as "reverse proxies" and "(origin) server accelerators". replica origin server / mirror [ TBC ] 2.3 Second order derivatives The following terms further build on first order derivatives authoritative reference The owner of data; content production system; possibly an origin server; the overall master copy of the content, if any. content consumer The user or system that initiates requests of an origin server (which may in turn be handled by a proxy). Melve, et. al. Expires April 19, 2000 [Page 7] Internet-Draft WREC Taxonomy October 1999 browser A special instance of a user agent that acts as a content presentation device for content consumers. 2.4 Topological terms The following definitions are added to describe caching device topology: user agent cache The cache within the user agent program. local caching proxy The caching proxy a user agent connects to. [Ed note; IAN: should this be renamed 'primary proxy'?] intermediate caching proxy Seen from the content consumer's view, all caches participating in the caching mesh that are not the user agent's local caching proxy cache server A server to requests made by local and intermediate caching proxies, but which does not act as a proxy cache array A cluster of caching proxies, acting logically as one service and partitioning the URL name space across the array. Also known as "diffused array" or "cache cluster". caching mesh a loosely coupled set of co-operating proxy- or caching- servers, or clusters, acting independently but sharing cacheable content between themselves using inter-cache communication protocols (see Section 7). 2.5 Automatic use of proxies Network administrators may wish to facilitate the use of proxies (typically caching proxies) by clients, enabling such configuration within the network itself or within automatic systems within user agents such that the user need not be aware of any such configuration issues. The terms that describe such configurations are given below. automatic user-agent proxy configuration The technique of discovering the availability of one or more proxies and the automated configuration of the client to use Melve, et. al. Expires April 19, 2000 [Page 8] Internet-Draft WREC Taxonomy October 1999 them. The use of a proxy is transparent to the user but not to the client. traffic interception The process of using a network element to examine network traffic to determine whether it should be redirected. traffic redirection Redirection of client requests from a network element performing traffic interception to a proxy. Used to deploy (caching) proxies without the need to manually reconfigure individual user agents, or to force the use of a proxy where such use would not otherwise occur. The use of any proxy is transparent to both user and client. (network) transparent proxy A proxy that receives traffic as a result of network traffic redirection. The term "transparent proxy" is typically used to refer to a network transparent proxy and the additional systems that perform traffic redirection. The use of this type of proxy is transparent to both user and client. Due to a conflicting definition in [6], caution should be exercised when referring to a "transparent proxy". As stated above, it is recommended that the phrase "transparent proxy" is prepended with appropriate terminology to avoid confusion. Melve, et. al. Expires April 19, 2000 [Page 9] Internet-Draft WREC Taxonomy October 1999 3. Distributed System Relationships This section identifies the relationships that exist in a distributed replication and caching environment. Having defined these relationships, later sections describe the communication protocols used in each relationship. 3.1 Replication Relationships [Ed note; describe the replication system relationship domain] 3.1.1 Client to Replica A client may communicate with one or more replica origin servers, as well as with master origin servers. (In the absense of replica servers the client interacts directly with the origin server as is the normal case.) Persistent Domain Complete Idem-Potent Set Replication ------------------ ----------------- ------------------ | Replica Origin | | Master Origin | | Replica Origin | | Server | | Server | | Server | ------------------ ----------------- ------------------ \ | / \ | / ----------------------------------------- | Client to ----------------- Replica Server | Client | | | ----------------- Protocols used to enable the client to use one of the replicas can be found in Section 4. 3.1.2 Inter-Replica This is the relationship between master origin server(s) ["authoritative reference"] and replica origin servers, to replicate data sets that are accessed by clients as shown in Section 3.1.1. Melve, et. al. Expires April 19, 2000 [Page 10] Internet-Draft WREC Taxonomy October 1999 Persistent Domain Complete Idem-Potent Set Replication ------------------ ----------------- ------------------ | Replica Origin |-----| Master Origin |-----| Replica Origin | | Server | | Server | | Server | ------------------ ----------------- ------------------ Protocols used in this relationship can be found in Section 5. 3.2 Proxy Relationships There are a variety of ways in which (caching) proxies and cache servers communicate with each other, and with clients. 3.2.1 Client to Non-Network Transparent Proxy A client may communicate with zero or more proxies for some or all requests. Where the result of communication results in no proxy being used the relationship is between cache and origin server or replica origin server (see Section 3.1.1). Temporal Domain Sparse Working Set Cache ----------------- ----------------- ----------------- | Local | | Local | | Local | | Proxy | | Proxy | | Proxy | ----------------- ----------------- ----------------- \ | / \ | / ----------------------------------------- | ----------------- | Client | ----------------- Protocols used in this relationship can be found in Section 6. 3.2.2 Reverse Proxy to Origin Server [Ed note; describe the accelerator relationship] [Ed note; needs to be recast as relationship between surrogate and origin server] A client or proxy may communicate with zero or more surrogates for requests intended for one or more origin servers. Where a surrogate is not available, the client may communicate directly with an origin server. Melve, et. al. Expires April 19, 2000 [Page 11] Internet-Draft WREC Taxonomy October 1999 ----------------- | Client | | | ----------------- | | ----------------- | Surrogate | | | ----------------- / | \ / | \ / | \ / | \ / | \ / | \ ------------------ ----------------- ------------------ | Origin | | Origin | | Origin | | Server | | Server | | Server | ------------------ ----------------- ------------------ 3.2.3 Inter-Cache [Ed note; recast this as relationship not the definition which follows in section 7] Inter-Cache: cooperation and communication between caching proxies. Inter-(caching)Proxy relationships exist in loosely coupled (mesh) relationships, and tightly coupled (cluster) relationships. 3.2.3.1 (Caching) Proxy Meshes Within a loosely coupled mesh of (caching) proxies, communication can happen at the same level, between siblings, and with one or more parents. Melve, et. al. Expires April 19, 2000 [Page 12] Internet-Draft WREC Taxonomy October 1999 [Ed note; Diagram needs updating] Temporal Domain Sparse Working Set Cache ----------------- | Top-Level | | Caching Proxy | ----------------- / \ / \ ----------------- ----------------- | Upper-Level |-----------| Upper-Level | | Caching Proxy | | Caching Proxy | ----------------- ----------------- / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ ----------------- ----------------- ----------------- | First Level |-----| First Level |-------| First Level | | Caching Proxy | | Caching Proxy | | Caching Proxy | ----------------- ----------------- ----------------- An outbound request from a local (caching) proxy may be routed to one of a number of intermediate (caching) proxies based on a determination of whether that parent is better suited to resolving the request. Protocols used in this relationship can be found in Section 7.1. 3.2.3.2 (Caching) Proxy Clusters [Ed note; is this really an inter-cache relationship?] +--------------------+ +--------------------+ | +-------------------+ | | | (Caching) Proxy | |----+ | Array |----+ ^ ^ +-------------------+ ^ ^ | | ^ ^ | |--+ | | +----+ | +------------------------+ Protocols used in this relationship can be found in Section 7.2. Melve, et. al. Expires April 19, 2000 [Page 13] Internet-Draft WREC Taxonomy October 1999 3.2.4 Network Element to Caching Proxy [Ed note; recast this as relationship not the definition which follows in section 8] Network Element to Proxy Cache: cooperation and communication between caching proxy and network elements. Examples include routes and switches. Generally used for transparent caching and/or diffused arrays. A network element performing traffic interception may choose to redirect requests from a client to a specific proxy within an array. (It may also choose not to redirect the traffic, in which case the relationship is between client and origin server or replica origin server, see Section 3.1.1.) Temporal Domain Sparse Working Set Cache ----------------- ----------------- ----------------- | Caching Proxy | | Caching Proxy | | Caching Proxy | | Array | | Array | | Array | ----------------- ----------------- ----------------- \ | / \ | / ----------------------------------------- | -------------- | Network | | Element | -------------- | | ------------ | Client | ------------ The network transparent (caching) proxy may be directly in-line of the flow of traffic - in which case the intercepting network element and network transparent proxy form parts of the same hardware system - or may be out-of-path, requiring the intercepting network element to redirect traffic over another network segment. In this latter case, communication protocols enable the intercepting network element to stop and start redirecting traffic when the network transparent proxy becomes (un)available. Details of these protocols can be found in Section 8. Melve, et. al. Expires April 19, 2000 [Page 14] Internet-Draft WREC Taxonomy October 1999 4. Client to Replica Communication This section describes the cooperation and communication between clients (both user agents and proxy caches) and replica origin web servers. Used to discover a optimal web origin server replica for a web client to establish service with. Optimality is a policy based decision, often based upon proximity, but may be based on other criteria such as load. 4.1 Navigation Hyperlinks Authoritative reference: This memo. Description: The simplest of client to replica communication mechanisms. This utilizes hyperlink URLs embedded in web pages that point to the mirror sites. The human user manually selects the link of the replica origin server they wish to use. Security: Relies on the protocol security associated with the URL scheme. Deployment: Probably the most commonly deployed client to replica communication mechanism. Ubiquitous interoperability with humans. Submitter: Document editors. 4.2 URL Redirection Authoritative reference: This memo. Description: A simple and commonly used mechanism to connect web clients with origin server replicas is to use URL redirection. Clients are redirected to a optimal web server replica via the use of the HTTP[6] protocol response code 307 Temporary Redirect. A web client establishes HTTP communication with one of the web server replicas. The initially contacted replica origin web server can either choose to accept the service or redirect the client to the proper replica. Refer to section 10.3.8 in HTTP/1.1 RFC2616 for information on HTTP response code 307. Security: Relies entirely upon HTTP security. Melve, et. al. Expires April 19, 2000 [Page 15] Internet-Draft WREC Taxonomy October 1999 Deployment: Observed at a number of large web sites. Extent of usage in the Internet is unknown at this time. Submitter: Document editors. [Ed note; Is this too specific for describing what Akamai etc. currently do?] 4.3 DNS Redirection [Ed note; it would have been nice to cite SONAR, but draft has expired] Authoritative reference: Load balancing: RFC1794 DNS Support for Load Balancing Proximity[19]: This memo Description: The Domain Name Service (DNS) provides a more sophisticated client to replica communication mechanism. This is accomplished by DNS servers that implement order of addresses based upon quality of service policies. When a web client resolves the name of a web server, the enhanced DNS server orders the IP addresses of the web server starting with the most optimal replica and ending with the least optimal replica. Security: Relies entirely upon DNS security. Deployment: Observed at a number of large web sites and large ISP web hosted services. Extent of usage in the Internet is unknown at this time. Submitter: Document editors. Melve, et. al. Expires April 19, 2000 [Page 16] Internet-Draft WREC Taxonomy October 1999 5. Inter-Replica Communication This section describes the cooperation and communication between replica origin servers. Used in replicating data sets between origin servers. 5.1 Batch Driven Mirror Replication Authoritative reference: This memo. Description: In this model, the replica web server to be updated initiates communication with a master origin web server. The communication is established at intervals based upon queued transactions which are scheduled for deferred processing. The scheduling mechanism policies vary, but generally are reoccuring at a specified time. Once communication is established, data sets are copied to the initiating replica web server. Security: Relies upon the protocol being used to transfer the data set. FTP and RDIST are the most common protocols observed. Deployment: Very common for mirror synchronization in the Internet. Submitter: Document editors. 5.2 Demand Driven Mirror Replication Authoritative reference: This memo. Description: In this model, the replica web server acquires the content as needed due to demand. This is generally done by web server accelerators (reverse proxy) operating as origin server replicas. When a web client requests a URL that is not in the data set or the replica origin server, the replica server attempts to acquire it from a master origin server and forwarded on to the requesting web client. Security: Relies upon the protocol being used to transfer the URLs. FTP, Gopher, HTTP and ICP are the most common protocols observed. Deployment: Melve, et. al. Expires April 19, 2000 [Page 17] Internet-Draft WREC Taxonomy October 1999 Observed at several large web sites. Extent of usage in the Internet is unknown at this time. Submitter: Document editors. 5.3 Synchronized Replication Authoritative reference: This memo. Ed note: there is no IETF protocol specified at this time. The editors are aware of at least two open source protocols, AFS and CODA, along with one expired IETF draft and one proprietary protocol Novell NRS; none of which can be considered an authoritative reference Description: In this model, the replicated origin servers cooperate using synchronized strategies and specialized replica protocols to keep the replica data sets coherent. Synchronization strategies range from tightly coherent (a few minutes) to loosely coherent (a few or more hours). Updates occur between replicas based upon the synchronization time constraints of the coherency model employed and are generally in the form of deltas only. Security: All of the known protocols utilize strong cryptographic key exchange methods, which are either based upon the Kerberos shared secret model or the public/private key RSA model. Deployment: Observed at a few sites, primarily at university campuses. Submitter: Document editors. Melve, et. al. Expires April 19, 2000 [Page 18] Internet-Draft WREC Taxonomy October 1999 6. Client to Proxy Configuration This section describes the configuration, cooperation and communication between end user clients (browsers and applications) a proxy. 6.1 Manual Proxy Configuration Authoritative reference: This memo. Description: Each user needs to configure its web client by typing in information pertaining to proxied protocols and local policies. Security: The potential for doing wrong is high, as each user individually sets preferences. Deployment: Widely deployed, used in all current browsers. Most browsers support other options as well. Submitter: Document editors. 6.2 Proxy Auto Configuration (PAC) Authoritative reference: No RFC published, no Internet-Draft; Navigator Proxy Auto-Config File Format[7]. Description: A JavaScript page on a web server hands out information on where to find proxies. Clients need to point at the URL of this page. No bootstrap mechanism, manual configuration necessary. Manual configuration is made easier by centralizing the script to one URL. Security: Common policy per organization possible. Does still require manual configuration. PAC is better than "manual proxy configuration" because with PAC administrators can update the proxy configuration without user intervention. Interoperability of PAC files is not as good as wanted, since more popular browsers have slightly different interpretation of the script, and this may lead to undesired effects. Deployment: Melve, et. al. Expires April 19, 2000 [Page 19] Internet-Draft WREC Taxonomy October 1999 Implemented in most web clients. Submitter: Document editors. 6.3 Cache Array Routing Protocol (CARP) v1.0 Authoritative reference: Expired Internet-Draft: draft-vinod-carp-v1-03.txt[9] Note: Reference kept since there is known deployment. Description: Clients may use CARP directly as a hash function based proxy selection mechanism. They need to be configured with the location of the cluster information. Security: Deployment: Submitter: Document editors. 6.4 Web Proxy Auto-Discovery Protocol (WPAD) Authoritative reference: Internet-Draft: draft-ietf-wrec-wpad-00.txt[8] Description: WPAD uses a collection of pre-existing Internet resource discovery mechanisms to perform web proxy auto-discovery. The only goal of WPAD is to locate the PAC URL. WPAD does not specify which proxies will be used. WPAD gets you to the PAC URL, and the PAC script chooses the proxies for you. The WPAD protocol specifies the following: * how to use each mechanism for the specific purpose of web proxy auto-discovery * the order in which the mechanisms should be performed * the minimal set of mechanisms which must be attempted by a WPAD compliant web client The resource discovery mechanisms utilized by WPAD are as follows: * Dynamic Host Configuration Protocol DHCP * Service Location Protocol SLP Melve, et. al. Expires April 19, 2000 [Page 20] Internet-Draft WREC Taxonomy October 1999 * "Well Known Aliases" using DNS A records * DNS SRV records * "service: URLs" in DNS TXT records Security: Relies upon DNS and HTTP security. Deployment: Implemented in web clients and caching proxy servers. More than two independent implementations. Submitter: Josh Cohen, Microsoft, joshco@microsoft.com Melve, et. al. Expires April 19, 2000 [Page 21] Internet-Draft WREC Taxonomy October 1999 7. Inter-Cache Communication [Ed note: INGRID. Review and chase submissions (push Duane)] 7.1 Loosely coupled Inter-Cache Communication This section describes the cooperation and communication between caching proxies. 7.1.1 Internet Cache Protocol (ICP) See RFC2186[10],Expired Internet-Draft draft-lovric-icp-ext-01.txt[12], ICP development[13], ICP1.4 specification[14]. Authoritative reference: RFC 2186 Internet Cache Protocol (ICP), version 2[10] Description: ICP is used by caches to query other caches about web objects, to see if a web object is present at the other cache. ICP uses UDP. Since UDP is an uncorrected network transport protocol, an estimate of network congestion and availability may be calculated by ICP loss. This rudimentary loss measurement does, together with round trip times provide a load balancing method for caches. Security: ICP does not convey information about HTTP headers associated with a web object. HTTP headers may include access control and cache directives, Since caches ask for objects, and then download the objects using HTTP, false cache hits may occur (object present in cache, but not accessible for sibling cache is one example). ICP suffer from all the security problems of UDP. Deployment: Widely deployed. Most current cache implementations support ICP in one form or the other. Submitter: Document editors. 7.1.2 Hyper Text Caching Protocol (HTCP/0.0) [Ed note: Based upon reviewers comments, the editors would like to drop this protocol from current Taxonomy consideration, due to its experimental nature] Melve, et. al. Expires April 19, 2000 [Page 22] Internet-Draft WREC Taxonomy October 1999 Authoritative reference: Internet-Draft: draft-vixie-htcp-proto-05.txt[23] Description: HTCP is a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. HTCP includes HTTP headers, while ICPv2 does not. HTTP headers are vital information for web proxy caches. Security: Optionally uses the MD5 shared secret authentication. Lack of authentication option make protocol subject to attack. Deployment: Implemented in caching proxies (two independent implementations) Submitter: Document editors. 7.1.3 Cache Digest See [22] [Ed note: Does it really need to be submitted for Informational RFC?] Authoritative reference: No RFC published, no Internet-Draft; Cache Digest specification http://squid.nlanr.net/Squid/CacheDigest/cache-digest-v5.txt[22], Squid Digest FAQ entry http://squid.nlanr.net/Squid/FAQ/FAQ-16.html Description: Cache Digests are a response to the problems of latency and congestion associated with previous inter-cache communications mechanisms such as the Internet Cache Protocol (ICP) [10][11] and the HyperText Cache Protocol[23]. Unlike most of these protocols, Cache Digests support peering between cache servers without a request-response exchange taking place. Instead, a summary of the contents of the server (the Digest) is fetched by other servers which peer with it. Using Cache Digests it is possible to determine with a relatively high degree of accuracy whether a given URL is cached by a particular server. Cache Digests are both an exchange protocol and a data format [22]. Security: If the contents of a Digest is sensitive, it should be protected from access by The Wrong People. Any methods which would normally be applied to secure an HTTP connection can be applied to Cache Melve, et. al. Expires April 19, 2000 [Page 23] Internet-Draft WREC Taxonomy October 1999 Digests. A 'Trojan horse' attack is currently possible in a cache mesh: Cache A can build a fake peer Digest for cache B and serve it to B's peers if requested. This way A can direct traffic toward/from B. The impact of this problem is minimized by the 'pull' model of transferring Cache Digests from one server to another. Cache Digests provide knowledge about peer cache content on a URL level. Hence, they do not dictate a particular level of policy management and can be used to implement various policies on any level (user, organization, etc.). Deployment: Cache Digests are supported in Squid; several commercial vendors are looking into Digest support. Cache Meshes: * NLANR Mesh * TF-CACHE mesh (European Academic networks) Submitter: Alex Rousskov, NLANR, rousskov@nlanr.net 7.1.4 Cache Pre-filling Authoritative reference: Expired Internet-Draft: draft-lovric-francetelecom-satellites-00.txt[21] Description: Cache pre-filling is a push-caching implementation. It is particularly well adapted to IP-multicast networks because it allows preselected URLs to be inserted in one single time within all the caches that belong to the targeted multicast group. Different implementations of cache pre-filling already exist, especially in satellite contexts. However, there is still no standard for this kind of push-caching and vendors propose solutions either based on dedicated equipments or public domain caches extended with a pre-filling module. Security: Relies on the inter cache protocols being employed. Deployment: Observed in two commercial content distribution service providers. Submitter: Ivan Lovric, France Telecom, ivan.lovric@cnet.francetelecom.fr Melve, et. al. Expires April 19, 2000 [Page 24] Internet-Draft WREC Taxonomy October 1999 7.2 Tightly Coupled Inter-Cache Communication 7.2.1 Cache Array Routing Protocol (CARP) v1.0 Authoritative reference: Expired Internet-Draft: draft-vinod-carp-v1-03.txt[9] Note: Reference kept since there is known deployment. Description: CARP is a hashing function for dividing URL-space among a cluster of proxy caches. Included in CARP is the definition of a Proxy Array Membership Table, and ways to download this information. An HTTP client agent (either a proxy server or a client browser) which implements CARP v1.0 can allocate and intelligently route requests for the correct URLs to any member of the Proxy Array. Due to the resulting sorting of requests through these proxies, duplication of cache contents is eliminated and global cache hit rates may be improved. Security: Deployment: Implemented in caching proxy servers. More than two independent implementations. Submitter: Melve, et. al. Expires April 19, 2000 [Page 25] Internet-Draft WREC Taxonomy October 1999 8. Network Element Communication This section describes the cooperation and communication between caching proxy and network elements. Examples include routers and switches. Generally used for transparent caching and/or diffused arrays. 8.1 Web Cache Coordination Protocol (WCCP) Authoritative reference: Internet-Draft: draft-ietf-wrec-web-pro-00.txt[16] Description: WCCP V1 runs between a router functioning as a redirecting network element and out-of-path transparent caching proxies. The protocol allows one or more caching proxies to register themselves with a single router to receive redirected web traffic. It also allows one of the proxies, the designated proxy, to dictate to the router how redirected web traffic is distributed across the caching proxies. Security: WCCP V1 has no security features. Deployment: Network elements: WCCP V1 is deployed on a wide range of Cisco routers. Caching proxies: WCCP V1 is deployed on a number of vendors' caches. Submitter: David Forster, CISCO, dforster@cisco.com 8.2 SOCKS Authoritative reference: RFC1928 SOCKS Protocol Version 5[17] Description: SOCKS is primarily used as a proxy cache to firewall protocol. Although, firewalls don't conform to the narrowly defined network element definition of routers and switches, they are a integral part of the network infrastructure. When used in conjunction with a firewall, SOCKS provides a authenticated tunnel between the proxy cache and the firewall. Security: A extensive framework provides for multiple authentication methods. Currently, SSL, CHAP, DES, 3DES are known to be Melve, et. al. Expires April 19, 2000 [Page 26] Internet-Draft WREC Taxonomy October 1999 available. Deployment: SOCKS is been widely deployed in the Internet. Submitter: Document editors. Melve, et. al. Expires April 19, 2000 [Page 27] Internet-Draft WREC Taxonomy October 1999 9. Security Considerations This document is provides a taxonomy for web caching and replication. Recommended practice, architecture and protocols are not described in detail. Replication and caching means copying objects. There are legal implication of making and keeping transient or permanent copies, these are not covered in the security considerations. Information on security in each protocol is provided in the description of the protocol, and in the accompanying documentation of each protocol. HTTP security is discussed in section 15 of RFC2616[6], the HTTP/1.1 specification, and to a lesser extent in RFC1945[15], the HTTP/1.0 specification. RFC2616 contains security consideration for HTTP proxies. Caching proxies have the same security issues as other application level proxies. Application level proxies are not covered in these security considerations. Authentication based on client IP number is problematic when connecting through a proxy, details are not discussed here. 9.1 Authentication Requests for web objects and responses to such requests may go to replicas and/or flow through proxies. The integrity of the communication needs to be preserved, to ensure protection of access to the communication and protect the communication exchange from unintended change. In the case of security breach, the culprit needs to be identified 9.1.1 Man in the middle attacks HTTP proxies are men-in-the-middle, the perfect place for a man-in-the-middle-attack. A discussion of this is found in section 15 of RFC2616[6]. 9.1.2 Trusted third party A proxy must either be trusted to act on behalf of server and/or client, or it must act as a tunnel. When presenting cached objects to clients, the clients need to trust the caching proxy to act on behalf on the origin server. A replica may get accreditation from the origin server. Melve, et. al. Expires April 19, 2000 [Page 28] Internet-Draft WREC Taxonomy October 1999 9.1.3 Authentication based on IP number Authentication based on client IP number is problematic when connecting through a proxy, as the authenticating server sees the proxy's IP number. One (not recommended) solution to this is spoofing the client's IP number. Authentication based on IP number assumes that the end-to-end properties of the Internet are preserved. This is typically not the case for a network transparent proxy. 9.2 Privacy 9.2.1 Trusted third party When using a replication service, you need to trust both the replica and the object location service. A object location service is used to find the replicated object. Current examples include DNS round robin, manual mirror lists, URNs, HTTP redirecting. Redirection of traffic, either by redirecting to replicas or by redirection done by proxies, may introduce third parties the end user and/or origin server need to trust. In the case of network transparent proxies, such trusted third parties are often unknown to both end points of the communication. Unknown trusted third parties may have security implications. Both proxies and location services may have access to aggregated access information. A proxy typically knows about all access by all the clients using it, information that is more sensitive than the information held by one origin server. 9.2.2 Logs and legal implications Logs from proxies need to be kept secure, as they provide information about users and end user patterns. A proxy log is even more sensitive than a web server log, as all requests from the user population goes through the proxy. Logs from replication servers may need to be amalgamated to get aggregated statistics from a service, transporting logs across borders may have legal implications. Log handling is restricted by law in some countries. Requirements for object security and privacy are the same in a web replication and caching system as it is in the Internet at large. The only reliable solution is strong cryptography. End to end encryption does not necessarily make objects cacheable, as is the case of SSL encrypted web sessions. Melve, et. al. Expires April 19, 2000 [Page 29] Internet-Draft WREC Taxonomy October 1999 9.3 Service security 9.3.1 Denial of service Any redirection of traffic is susceptible to denial of service attacks at the redirect point, and both proxies and location services may redirect traffic. By attacking a proxy, access to all servers may be denied for a large set of clients. It has been argued that introduction of a network transparent proxy is denial of service since the end to end nature of the Internet is destroyed without the end users knowledge. 9.3.2 Replay attack A caching proxy is by definition a replay attack. 9.3.3 Stupid configuration of proxies It is quite easy to have a stupid configuration which will harm service for end users. This is the most common security problem with proxies. 9.3.4 Copyrighted transient copies The legislative forces of the world are considering the question of transient copies, like those kept in replication and caching system, being legal. Legal implications of replication and caching is subject to local law. Caching proxies need to preserve the protocol output, including headers. Replication services need to preserve the source of the objects. 9.3.5 Application level access Caching proxies are application level components in the traffic flow path, and may give intruders access to information that was only available at network level equipment in a proxy-free world. Some network level equipment may have required physical access to get sensitive information, and introducing application level components may require additional system security. Melve, et. al. Expires April 19, 2000 [Page 30] Internet-Draft WREC Taxonomy October 1999 10. Acknowledgements [Ed note: No decision made on authors list. Submitters of individual entries are acknowledged in the text. Need to sort out how to give credits where they are due.] David Forster, Cisco, dforster@cisco.com provided info on Out-of-path Transparent Caching Proxies. Alex Rousskov, David Forster, Josh Cohen and John Martin for protocol information. John Dilley, Ivan Lovric and Joe Touch for terminology and taxonomy information. David Forster, Josh Cohen, Henrik Nordstrom and Patrick McManus for their help in defining proxy transparency. Melve, et. al. Expires April 19, 2000 [Page 31] Internet-Draft WREC Taxonomy October 1999 References [1] Wessels, D., "Squid FAQ: Transparent Caching/Proxying.", External resource http://www.squid-cache.org/Doc/FAQ/FAQ-17.html, October 1999. [2] Danzig, P. and K.L. Swartz, "Transparent, Scalable, Failsafe Web Caching", External reference http://www.netapp.com/technology/level3/3033.html, October 1999. [3] Williams, B., "Transparent Web Caching Solutions.", External reference available from Alteon Networks, May 1999. [4] Hain, T., "Architectural Implications of NAT", Internet Draft draft-iab-nat-implementations-04.txt, April 1999. [5] Melve, I., Slettjord, L., Verschuren, T. and H. Bekker, "Web caching architecture; Technical report European Union RE1004-M4.3", January 1999. [6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [7] Netscape, Inc., "Navigator Proxy Auto-Config File Format", External reference http://www.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html , March 1996. [8] Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web Proxy Auto-Discovery Protocol", Internet Draft draft-ietf-wrec-wpad-01.txt, July 1999. [9] Valloppillil, V. and K.W. Ross, "Cache Array Routing Protocol", Internet Draft draft-vinod-carp-v1-03.txt, January 1999. [10] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), Version 2", RFC 2186, September 1997. [11] Wessels, D. and K. Claffy, "Application of Internet Cache Protocol (ICP), Version 2", RFC 2187, September 1997. [12] Lovric, I., "Internet Cache Protocol Extension", Internet Draft draft-lovric-icp-ext-01.txt, January 1999. [13] Wessels, D., "ICP Home Page", External reference http://ircache.nlanr.net/Cache/ICP/, July 1999. [14] University of Southern California and University of Melve, et. al. Expires April 19, 2000 [Page 32] Internet-Draft WREC Taxonomy October 1999 Colorado-Boulder, "Internet Cache Protocol Specification 1.4", External reference http://excalibur.usc.edu/icpdoc/icp.html, September 1994. [15] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [16] Cisco Systems, "Cisco Web Cache Coordination Protocol V1.0", Internet Draft draft-ietf-wrec-web-pro-00.txt, June 1999. [17] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [18] Moore, K., "On the use of HTTP as a Substrate for Other Protocols", Internet Draft draft-iesg-using-http-00.txt, January 1999. [19] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995. [20] "Transparent Proxy Agent Control Protocol", Internet Draft draft-ietf-wrec-tpact-00.txt, January 1999. [21] Goutard, C., Lovric, I. and E. Maschio-Esposito, "Pre-filling a cache - A satellite overview", Internet Draft draft-lovric-francetelecom-satellites-00.txt, February 1999. [22] Hamilton, M., Rousskov, A. and D. Wessels, "Cache Digest specification - version 5", External reference http://squid.nlanr.net/CacheDigest/cache-digest-v5.txt, December 1998. [23] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol (HTCP/0.0)", Internet Draft draft-vixie-htcp-proto-05.txt, August 1999. Authors' Addresses Ingrid Melve UNINETT Tempeveien 22 Trondheim Norway Phone: +47 73 55 79 07 EMail: Ingrid.Melve@uninett.no Melve, et. al. Expires April 19, 2000 [Page 33] Internet-Draft WREC Taxonomy October 1999 Gary Tomlinson Novell Inc. 122 East 1700 South Provo, Utah 84606 USA Phone: +1 801 861 7021 EMail: garyt@novell.com Ian Cooper Mirror Image Internet, Inc. 49 Dragon Court 2nd floor Woburn, MA 01801 USA Phone: +1 781 939 0735 EMail: ian@mirror-image.com Melve, et. al. Expires April 19, 2000 [Page 34] Internet-Draft WREC Taxonomy October 1999 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Melve, et. al. Expires April 19, 2000 [Page 35]