Ian,
How does the following look as text for 3.2.2?
Ted
3.2.2 Client or Proxy to Surrogate
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.
-----------------
| Client |
| |
-----------------
|
|
-----------------
| Surrogate |
| |
-----------------
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
------------------ ----------------- ------------------
| Origin | | Origin | | Origin |
| Server | | Server | | Server |
------------------ ----------------- ------------------
>
>
> ----=_szX+N5Vkph66KxjcrC2aZpPs4RI1.MFSBCHJLHS
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> OK folks, here's a complete copy of the current working copy of the
> draft.
>
> I'm aware that there are still issues in the terminology section.
>
> Right now I'm a little more interested in getting some comments on
> section 3. I'd rather you pointed out issues of which I and the other
> editors are aware of rather than keeping quiet: this list has been
> awfully quiet of late.
>
> Some time ago John Dilley suggested using a non-graphical method of
> representing the relationships. As I've dived into this stuff over the
> past few days it's become obvious that we really need this to help
> lock down the relationships. Some of the diagrams work and are easily
> drawn. Others are not. If anyone has suggestions on how we can do
> this (examples definitions for 3.2.1 [including where a client may not
> use any proxy] and 3.2.3 would be useful if you're not going to do all
> of them) I'd be grateful.
>
> I'd also be grateful if a proponent of surrogates would send something
> to get us started in section 3.2.2
>
>
> Ian
>
> ----=_szX+N5Vkph66KxjcrC2aZpPs4RI1.MFSBCHJLHS
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Content-Description: draft-ietf-wrec-taxonomy-02e.txt
> Content-Disposition: inline
>
>
>
> Network Working Group I. Melve
> Internet-Draft UNINETT
> Expires: April 7, 2000 G. Tomlinson
> Novell
> I. Cooper
> Mirror Image
> October 8, 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 7, 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 7, 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 Awaiting action . . . . . . . . . . . . . . . . . . . . . 8
> 2.5 Topological terms . . . . . . . . . . . . . . . . . . . . 8
> 2.6 Automatic use of proxies . . . . . . . . . . . . . . . . . 9
> 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 . . . . . . . . . . . . . . . . . . . . . . . 11
> 3.2.3.1 (Caching) Proxy Meshes . . . . . . . . . . . . . . . . . . 12
> 3.2.3.2 (Caching) Proxy Clusters . . . . . . . . . . . . . . . . . 12
> 3.2.4 Network Element to Caching Proxy . . . . . . . . . . . . . 13
> 3.2.4.1 Caching Proxies with Transparency . . . . . . . . . . . . 14
> 3.2.4.2 Out-of-path Transparent Caching Proxies . . . . . . . . . 15
> 4. Client to Replica Communication . . . . . . . . . . . . . 16
> 4.1 Navigation Hyperlinks . . . . . . . . . . . . . . . . . . 16
> 4.2 URL Redirection . . . . . . . . . . . . . . . . . . . . . 16
> 4.3 DNS Redirection . . . . . . . . . . . . . . . . . . . . . 17
> 5. Inter-Replica Communication . . . . . . . . . . . . . . . 18
> 5.1 Batch Driven Mirror Replication . . . . . . . . . . . . . 18
> 5.2 Demand Driven Mirror Replication . . . . . . . . . . . . . 18
> 5.3 Synchronized Replication . . . . . . . . . . . . . . . . . 19
> 6. Client to Proxy Configuration . . . . . . . . . . . . . . 20
> 6.1 Manual Proxy Configuration . . . . . . . . . . . . . . . . 20
> 6.2 Proxy Auto Configuration (PAC) . . . . . . . . . . . . . . 20
> 6.3 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 21
> 6.4 Web Proxy Auto-Discovery Protocol (WPAD) . . . . . . . . . 21
> 7. Inter-Cache Communication . . . . . . . . . . . . . . . . 23
> 7.1 Loosely coupled Inter-Cache Communication . . . . . . . . 23
> 7.1.1 Internet Cache Protocol (ICP) . . . . . . . . . . . . . . 23
> 7.1.2 Hyper Text Caching Protocol (HTCP/0.0) . . . . . . . . . . 23
> 7.1.3 Cache Digest . . . . . . . . . . . . . . . . . . . . . . . 24
> 7.1.4 Cache Pre-filling . . . . . . . . . . . . . . . . . . . . 25
> 7.2 Tightly Coupled Inter-Cache Communication . . . . . . . . 26
> 7.2.1 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 26
> 8. Network Element Communication . . . . . . . . . . . . . . 27
> 8.1 Web Cache Coordination Protocol (WCCP) . . . . . . . . . . 27
> 8.2 Transparent Proxy Agent Control Protocol (TPACT) . . . . . 27
> 8.3 SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . 28
> 9. Security Considerations . . . . . . . . . . . . . . . . . 29
>
>
> Melve, et. al. Expires April 7, 2000 [Page 2]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> 9.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 29
> 9.1.1 Man in the middle attacks . . . . . . . . . . . . . . . . 29
> 9.1.2 Trusted third party . . . . . . . . . . . . . . . . . . . 29
> 9.1.3 Authentication based on IP number . . . . . . . . . . . . 30
> 9.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 30
> 9.2.1 Trusted third party . . . . . . . . . . . . . . . . . . . 30
> 9.2.2 Logs and legal implications . . . . . . . . . . . . . . . 30
> 9.3 Service security . . . . . . . . . . . . . . . . . . . . . 31
> 9.3.1 Denial of service . . . . . . . . . . . . . . . . . . . . 31
> 9.3.2 Replay attack . . . . . . . . . . . . . . . . . . . . . . 31
> 9.3.3 Stupid configuration of proxies . . . . . . . . . . . . . 31
> 9.3.4 Copyrighted transient copies . . . . . . . . . . . . . . . 31
> 9.3.5 Application level access . . . . . . . . . . . . . . . . . 31
> 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32
> References . . . . . . . . . . . . . . . . . . . . . . . . 33
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . 34
> Full Copyright Statement . . . . . . . . . . . . . . . . . 36
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Melve, et. al. Expires April 7, 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 7, 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 7, 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 7, 2000 [Page 6]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> and "outbound" means "traveling toward the user agent"
>
> 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
>
> The following colloquial terms are also used to refer to caching
> proxies:
>
> * proxy
>
> * cache
>
> 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).
>
> browser
>
>
> Melve, et. al. Expires April 7, 2000 [Page 7]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> A special instance of a user agent that acts as a content
> presentation device for content consumers.
>
> 2.4 Awaiting action
>
> A placeholder for terms that need to be considered/deleted/moved
>
> network element
> A network device that introduces multiple paths between source
> and destination, transparent to HTTP.
> [Ed note; IAN: This term probably needs a better name.]
>
> 2.5 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
>
> * 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)
>
>
>
>
>
> Melve, et. al. Expires April 7, 2000 [Page 8]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> 2.6 Automatic use of proxies
>
> Moves to insert proxies into the network in a manner such at the
> content consumer is unaware of their presence has created a set of
> terms whose definitions may not be consistent with other uses. This
> section references prior definitions but also gives their meaning in
> the realm of Web caching.
>
> proxy discovery
> The discovery and configuration for use of a proxy in an
> environment where the content consumer may be unaware of the
> proxy's existence. The use of the proxy is transparent to the
> content consumer, but not to the client.
>
> [Ed note; IAN: should we consider the ability of proxies to discover
> each other? Would this be better titled as "transparent proxy
> configuration"?
>
> traffic interception
> The process of using a network element to examine network traffic
> to determine whether it should be redirected
>
> traffic redirection
> Redirection of traffic from a user agent or network element to a
> specific proxy, following its interception. Used to deploy
> Web-caching without the need to manually reconfigure individual
> user agents, or to force the use of a proxy where such use would
> not otherwise occur
>
> (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 the 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
> avoide confusion.
>
>
>
>
>
>
>
>
>
>
>
>
> Melve, et. al. Expires April 7, 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 (or in a non-replicated
> environment directly with the origin server).
>
>
> Persistent Domain
> Complete Idem-Potent Set Replication
> ------------------ ----------------- ------------------
> | Replica Origin | | Master Origin | | Replica Origin |
> | Server | | Server | | Server |
> ------------------ ----------------- ------------------
> \ | /
> \ | /
> -----------------------------------------
> | Client to
> ----------------- Replica Server
> | Client |
> | |
> -----------------
>
> Protocols used in this relationship 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.
>
>
> Persistent Domain
> Complete Idem-Potent Set Replication
> ------------------ ----------------- ------------------
> | Replica Origin |-----| Master Origin |-----| Replica Origin |
> | Server | | Server | | Server |
> ------------------ ----------------- ------------------
>
>
>
> Melve, et. al. Expires April 7, 2000 [Page 10]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> 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]
>
> 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.
>
>
>
>
>
> Melve, et. al. Expires April 7, 2000 [Page 11]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> 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.
>
> [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?]
>
>
>
>
>
>
>
>
>
> Melve, et. al. Expires April 7, 2000 [Page 12]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> +--------------------+
> +--------------------+ |
> +-------------------+ | |
> | (Caching) Proxy | |----+
> | Array |----+ ^ ^
> +-------------------+ ^ ^ | |
> ^ ^ | |--+ |
> | +----+ |
> +------------------------+
>
>
> Protocols used in this relationship can be found in Section 7.2.
>
> 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.)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Melve, et. al. Expires April 7, 2000 [Page 13]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> [Ed note; Should this diagram be re-drawn to show a proper "array"?]
>
>
> Temporal Domain
> Sparse Working Set Cache
> ----------------- ----------------- -----------------
> | Caching Proxy | | Caching Proxy | | Caching Proxy |
> | Array | | Array | | Array |
> ----------------- ----------------- -----------------
> \ | /
> \ | /
> -----------------------------------------
> |
> --------------
> | Network |
> | Element |
> --------------
> |
> |
> ------------
> | Client |
> ------------
>
> Protocols used in this relationship can be found in Section 8.
>
> 3.2.4.1 Caching Proxies with Transparency
>
> [Ed note: Currently contains citations from NetApp document, need
> rewording to avoid specific products and concentrate on generic
> properties. Explain network elements and NATs and other ways
> interception may happen. Intro to usage and "normal" setup.]
>
> Reference [1][2][3][4] for introduction to caching proxies with
> transparency.
>
> The goal of intercepting web traffic is to provide a transparent web
> proxy, thus avoiding the hassle of individually configuring each
> client.
>
> Transparency means that the user does not need to be aware of the
> proxy.
>
> The origin server see connections coming from the proxy, not from
> the individual end user. Authentication based on client IP address
> do not work if there is a transparent proxy cache in the way to the
> web server.
>
> A web cache is said to be transparent if clients can access the
> cache without the need to configure their browsers, using either a
>
>
> Melve, et. al. Expires April 7, 2000 [Page 14]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> proxy auto-configuration URL or a manual proxy setting. Transparent
> caches appear as a seamless part of the network infrastructure,
> rather than a set of discrete proxy servers, and function much like
> a transparent firewall. Many ISPs and carriers desire transparent
> caches because it lets them retrofit their network with caching
> without action at the client. However, when deployed transparently,
> a web cache must be as fail-safe and scalable as the rest of the
> network. [2]
>
> A transparent cache acts much like a gateway or firewall -- it
> effectively sits between the users and the network. The advantage of
> transparent caching is that it eliminates the need to configure
> browsers to use caching. Another strength (and sometimes a weakness)
> is that it is impossible to bypass caching. [2]
>
> Conceptually, transparency works by modifying the TCP/IP stack of a
> cache so that it operates in "promiscuous mode" and effectively
> binds itself to all possible IP addresses. [2]
>
> We need to give a far more abstract definition which includes the
> way that router and switch redirection, and within-router action,
> operate.
>
> Comment on some of the problems:
>
> o limited number of ports which can be captured
>
> o due to "unexpected" data on other ports (or even on well known
> ports), as experienced by setting up various services on port 80
>
> o well known problems with use of HTTP for transport[18]
>
> 3.2.4.2 Out-of-path Transparent Caching Proxies
>
> An Out-of-path Transparent Caching Proxy performs the same proxy and
> caching functions as a Transparent Caching Proxy and is similarly
> transparent to the client. However it does not lie on the forwarding
> path between a client and a server and does not perform web traffic
> interception. Instead it relies upon a redirecting network element
> in the path between client and server to intercept and redirect web
> traffic to it. One advantage of this method of transparent caching
> is that in the case of cache failure the network element can,
> providing it monitors the state of the caches, revert to forwarding
> web traffic direct to the server. It is also possible for the
> network element to distribute the web traffic load across a group of
> caches. This method of transparent caching generally requires a
> protocol to be run between the redirecting network element and the
> cache or caches.
>
>
>
> Melve, et. al. Expires April 7, 2000 [Page 15]
>
> 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 7, 2000 [Page 16]
>
> 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 7, 2000 [Page 17]
>
> 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 7, 2000 [Page 18]
>
> 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
> <draft-leach-cifs-v1-spec-01.txt> 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 7, 2000 [Page 19]
>
> 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)
>
> [Ed note: Does it really need to be submitted for Informational RFC?]
>
> Authoritative reference:
> No RFC published, no Internet-Draft Navigator Proxy Auto-Config
> File Format[7]. Available from
> http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html[24]
>
> 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
>
>
> Melve, et. al. Expires April 7, 2000 [Page 20]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> the script, and this may lead to undesired effects.
>
> Deployment:
> Implemented in most web clients.
>
> Submitter:
> Document editors.
>
> 6.3 Cache Array Routing Protocol (CARP) v1.0
>
> [Ed note: Current draft expired. A new draft must submitted and this
> section completed for this protocol to be considered in the Taxonomy]
>
> Authoritative reference:
> Expired Internet-Draft draft-vinod-carp-v1-03.txt Work in
> progress.
>
> 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:
>
> 6.4 Web Proxy Auto-Discovery Protocol (WPAD)
>
> Authoritative reference:
> Internet Draft <draft-ietf-wrec-wpad-00.txt> [Ed note; I-D
> submission anticipated by 6/25/99] Work in progress.
>
> 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
>
>
> Melve, et. al. Expires April 7, 2000 [Page 21]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> The resource discovery mechanisms utilized by WPAD are as follows:
>
> * Dynamic Host Configuration Protocol DHCP
>
> * Service Location Protocol SLP
>
> * "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 7, 2000 [Page 22]
>
> 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 [10][11][12][13][14]
>
> Authoritative reference:
> RFC 2186 Internet Cache Protocol (ICP), version 2
>
> 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 unreliable, 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)
>
> See [23]
>
> [Ed note: Based upon reviewers comments, the editors would like to
> drop this protocol from current Taxonomy consideration, due to its
> experimental nature]
>
> Authoritative reference:
>
>
> Melve, et. al. Expires April 7, 2000 [Page 23]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> Internet Draft draft-vixie-htcp-proto-05.txt, Work in Progress
>
> 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
> 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
> Digests.
>
>
> Melve, et. al. Expires April 7, 2000 [Page 24]
>
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> 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
>
> See [21]
>
> Authoritative reference:
> Internet Draft <draft-lovric-francetelecom-satellites-00.txt>
> Work in progress.
>
> 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 7, 2000 [Page 25]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> 7.2 Tightly Coupled Inter-Cache Communication
>
> 7.2.1 Cache Array Routing Protocol (CARP) v1.0
>
> [9]
>
> [Ed note: Current draft expired. A new draft must submitted and this
> section completed for this protocol to be considered in the Taxonomy]
>
> Authoritative reference:
> Work in Progress: Internet-Draft draft-vinod-carp-v1-03.txt
>
> 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 7, 2000 [Page 26]
>
> 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] Work in
> progress.
>
> 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 Transparent Proxy Agent Control Protocol (TPACT)
>
> Authoritative reference: [Ed note; anticipated submission]
> Internet Draft <draft-ietf-wrec-tpact-00.txt> [20] [Ed note; I-D
> submission anticipated by 6/25/99] Work in progress.
>
> Description:
> TPACT runs between a network elements (router or switch)
> 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 network
> element to receive redirected web traffic. All of the
> participating caching proxies operate as a quorum in the
> diectating of web traffic distribution across the group.
>
>
>
> Melve, et. al. Expires April 7, 2000 [Page 27]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> Security:
> MD5 is optionally employed for authentication. Sequence numbers
> are employed as security against replay attacks.
>
> Deployment:
> Network elements: TPACT is prototyped and being evaluated on
> multiple vendor L4 switches. Caching proxies: TPACT is
> prototyped and being evaluated on multiple vendor caches.
>
> Submitter:
> John Martin, Network Appliance, jmartin@netapp.com
>
> 8.3 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
> available.
>
> Deployment:
> SOCKS is been widely deployed in the Internet.
>
> Submitter:
> Document editors.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Melve, et. al. Expires April 7, 2000 [Page 28]
>
> 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 7, 2000 [Page 29]
>
> 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 7, 2000 [Page 30]
>
> 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 7, 2000 [Page 31]
>
> 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 7, 2000 [Page 32]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> References
>
> [1] Wessels, D., "Squid FAQ: Transparent Caching/Proxying.", July
> 1999.
>
> [2] Danzig, P. and K.L. Swartz, "Transparent, Scalable, Failsafe
> Web Caching", July 1999.
>
> [3] Williams, B., "Transparent Web Caching Solutions.", July 1999.
>
> [4] Hain, T., "Architectural Implications of NAT (Work in
> Progress).", July 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.",
> July 1999.
>
> [8] Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web
> Proxy Auto-Discovery Protocol (work in progress)", June 1999.
>
> [9] Valloppppillil, V. and K.W. Ross, "Cache Array Routing Protocol
> (work in progress)", 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 (work in
> progress)", January 1999.
>
> [13] Wessels, D., "ICP Home Page", January 1999.
>
> [14] University of Southern California and , "Internet Cache
> Protocol Specification 1.4", 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
> (work in progress)", January 1999.
>
>
> Melve, et. al. Expires April 7, 2000 [Page 33]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> [17] "SOCKS Protocol Version 5", RFC 1928, January 1999.
>
> [18] Moore, K., "On the use of HTTP as a Substrate for Other
> Protocols (work in progress)", January 1999.
>
> [19] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
> January 1999.
>
> [20] "Transparent Proxy Agent Control Protocol (work in progress)",
> January 1999.
>
> [21] "Pre-filling a cache - A satellite overview (work in
> progress).", January 1999.
>
> [22] Hamilton, M., Rousskov, A. and D. Wessels, "Cache Digest
> specification - version 5", December 1998.
>
> [23] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
> (HTCP/0.0) (work in progress)", August 1999.
>
> [24] http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html
>
> Authors' Addresses
>
> Ingrid Melve
> UNINETT
> Tempeveien 22
> Trondheim
> Norway
>
> Phone: +47 73 55 79 07
> EMail: Ingrid.Melve@uninett.no
>
> Gary Tomlinson
> Novell Inc.
> 122 East 1700 South
> Provo, Utah 84606
> USA
>
> Phone: +1 801 861 7021
> EMail: garyt@novell.com
>
>
>
>
>
>
>
>
>
>
> Melve, et. al. Expires April 7, 2000 [Page 34]
>
> Internet-Draft WREC Taxonomy October 1999
>
>
> Ian Cooper
> Mirror Image Internet, Inc.
> 18 Commerce Way
> Suite 4800
> Woburn, MA 01801
> USA
>
> Phone: +1 781 939 0735
> EMail: ian@mirror-image.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Melve, et. al. Expires April 7, 2000 [Page 35]
>
> 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 7, 2000 [Page 36]
>
>
> ----=_szX+N5Vkph66KxjcrC2aZpPs4RI1.MFSBCHJLHS--
>
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST