rfc3040.txt

RFC 的详细文档！

   Security:
      See RFC 2187 [3]

      ICP does not convey information about HTTP headers associated with
      resources.  HTTP headers may include access control and cache
      directives.  Since proxies ask for the availability of resources,
      and subsequently retrieve them using HTTP, false cache hits may
      occur (object present in cache, but not accessible to a sibling is
      one example).

      ICP suffers from all the security problems of UDP.

   Deployment:
      Widely deployed.  Most current caching proxy implementations
      support ICP in some form.

   Submitter:
      Document editors.

   See also:
      "Internet Cache Protocol Extension" [17] (work in progress)

7.1.2 Hyper Text Caching Protocol

   Best known reference:
      RFC 2756 Hyper Text  Caching Protocol (HTCP/0.0) [9]

   Description:
      HTCP is a protocol for discovering HTTP caching proxies and cached
      data, managing sets of HTTP caching proxies, and monitoring cache
      activity.

      HTCP requests include HTTP header material, while ICPv2 does not,
      enabling HTCP replies to more accurately describe the behaviour
      that would occur as a result of a subsequent HTTP request for the
      same resource.




Cooper, et al.               Informational                     [Page 20]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Security:
      Optionally uses HMAC-MD5 [11] shared secret authentication.
      Protocol is subject to attack if authentication is not used.

   Deployment:
      HTCP is implemented in Squid and the "Web Gateway Interceptor".

   Submitter:
      Document editors.

7.1.3 Cache Digest

      Best known references:

      *  "Cache Digest Specification - version 5" [21]

      *  "Summary Cache: A Scalable Wide-Area Web Cache Sharing
         Protocol" [10] (see note)

   Description:
      Cache Digests are a response to the problems of latency and
      congestion associated with previous inter-cache communication
      mechanisms such as the Internet Cache Protocol (ICP) [2] and the
      Hyper Text Cache Protocol [9].  Unlike these protocols, Cache
      Digests support peering between caching proxies and cache servers
      without a request-response exchange taking place for each inbound
      request.  Instead, a summary of the contents in cache (the Digest)
      is fetched by other systems that peer with it.  Using Cache
      Digests it is possible to determine with a relatively high degree
      of accuracy whether a given resource is cached by a particular
      system.

      Cache Digests are both an exchange protocol and a data format.

      Security:
      If the contents of a Digest are sensitive, they should be
      protected.  Any methods which would normally be applied to secure
      an HTTP connection can be applied to Cache Digests.

      A 'Trojan horse' attack is currently possible in a mesh: System A
      A can build a fake peer Digest for system 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 system to another.







Cooper, et al.               Informational                     [Page 21]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


      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.

      Cache Meshes: NLANR Mesh; TF-CACHE Mesh (European Academic
      networks

   Submitter:
      Alex Rousskov for [21], Pei Cao for [10].

   Note: The technology of Summary Cache [10] is patent pending by the
   University of Wisconsin-Madison.

7.1.4 Cache Pre-filling

   Best known reference:
      "Pre-filling a cache - A satellite overview" [20] (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 resources to be simultaneously inserted into
      caches within 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 equipment 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

7.2 Tightly Coupled Inter-Cache Communication

7.2.1 Cache Array Routing Protocol (CARP) v1.0

   Also see Section 6.3



Cooper, et al.               Informational                     [Page 22]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Best known references:

      *  "Cache Array Routing Protocol" [14] (work in progress)

      *  "Cache Array Routing Protocol (CARP) v1.0 Specifications" [15]

      *  "Cache Array Routing Protocol and Microsoft Proxy Server 2.0"
         [16]

   Description:
      CARP is a hashing function for dividing URL-space among a cluster
      of proxies.  Included in CARP is the definition of a Proxy Array
      Membership Table, and ways to download this information.

      A user agent which implements CARP v1.0 can allocate and
      intelligently route requests for the 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:
      Security considerations are not covered in the specification works
      in progress.

   Deployment:
      Implemented in caching proxy servers.  More than two independent
      implementations.

   Submitter:
      Document editors.

8. Network Element Communication

   This section describes the cooperation and communication between
   proxies and network elements.  Examples of such network elements
   include routers and switches.  Generally used for deploying
   interception proxies and/or diffused arrays.

8.1 Web Cache Control Protocol (WCCP)

   Best known references:
      "Web Cache Control Protocol" [18][19] (work in progress)

      Note: The name used for this protocol varies, sometimes referred
      to as the "Web Cache Coordination Protocol", but frequently just
      "WCCP" to avoid confusion





Cooper, et al.               Informational                     [Page 23]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Description:
      WCCP V1 runs between a router functioning as a redirecting network
      element and out-of-path interception proxies.  The protocol allows
      one or more proxies to register with a single router to receive
      redirected traffic.  It also allows one of the proxies, the
      designated proxy, to dictate to the router how redirected traffic
      is distributed across the array.

      WCCP V2 additionally runs between multiple routers and the
      proxies.

   Security:
      WCCP V1 has no security features.
      WCCP V2 provides optional authentication of protocol packets.

   Deployment:
      Network elements: WCCP is deployed on a wide range of Cisco
      routers.
      Caching proxies: WCCP is deployed on a number of vendors' caching
      proxies.

   Submitter:
      David Forster
      Document editors.

8.2 Network Element Control Protocol (NECP)

   Best known reference:
      "NECP: The Network Element Control Protocol" [22] (work in
      progress)

   Description:
      NECP provides methods for network elements to learn about server
      capabilities, availability, and hints as to which flows can and
      cannot be serviced.  This allows network elements to perform load
      balancing across a farm of servers, redirection to interception
      proxies, and cut-through of flows that cannot be served by the
      farm.

   Security:
      Optionally uses HMAC-SHA-1 [11] shared secret authentication along
      with complex sequence numbers to provide moderately strong
      security.  Protocol is subject to attack if authentication is not
      used.

   Deployment:
      Unknown at present; several network element and caching proxy
      vendors have expressed intent to implement the protocol.



Cooper, et al.               Informational                     [Page 24]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Submitter:
      Gary Tomlinson

8.3 SOCKS

   Best known reference:
      RFC 1928 SOCKS Protocol Version 5 [7]

   Description:
      SOCKS is primarily used as a caching proxy to firewall protocol.
      Although firewalls don't conform to the narrowly defined network
      element definition above, they are a integral part of the network
      infrastructure.  When used in conjunction with a firewall, SOCKS
      provides a authenticated tunnel between the caching proxy and the
      firewall.

   Security:
      An extensive framework provides for multiple authentication
      methods.  Currently, SSL, CHAP, DES, 3DES are known to be
      available.

   Deployment:
      SOCKS is widely deployed in the Internet.

   Submitter:
      Document editors.

9. Security Considerations

   This document provides a taxonomy for web caching and replication.
   Recommended practice, architecture and protocols are not described in
   detail.

   By definition, replication and caching involve the copying of
   resources.  There are legal implications of making and keeping
   transient or permanent copies; these are not covered here.

   Information on security of each protocol referred to by this memo is
   provided in the preceding sections, and in their accompanying
   documentation.  HTTP security is discussed in section 15 of RFC 2616
   [1], the HTTP/1.1 specification, and to a lesser extent in RFC 1945
   [6], the HTTP/1.0 specification.  RFC 2616 contains security
   considerations for HTTP proxies.








Cooper, et al.               Informational                     [Page 25]

RFC 3040      Internet Web Replication & Caching Taxonomy   January 2001


   Caching proxies have the same security issues as other application
   level proxies.  Application level proxies are not covered in these
   security considerations.  IP number based authentication is
   problematic when a proxy is involved in the communications.  Details
   are not discussed here.

9.1 Authentication

   Requests for web resources, and responses to such requests, may be
   directed to replicas and/or may flow through intermediate proxies.
   The integrity of communication needs to be preserved to ensure
   protection from both loss of access and from unintended change.

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
   RFC 2616 [1].

9.1.2 Trusted third party

   A proxy must either be trusted to act on behalf of the origin 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.

9.1.3 Authentication based on IP number

   Authentication based on the client's IP number is problematic when
   connecting through a proxy, since the authenticating device only has
   access to the proxy's IP number.  One (problematic) solution to this
   is for the proxy to spoof the client's IP number for inbound