rfc3040.txt

最新的RFC

   requests.

   Authentication based on IP number assumes that the end-to-end
   properties of the Internet are preserved.  This is typically not the
   case for environments containing interception proxies.

9.2 Privacy

9.2.1 Trusted third party

   When using a replication service, one must trust both the replica
   origin server and the replica selection system.





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


   Redirection of traffic - either by automated replica selection
   methods, or within proxies - may introduce third parties the end user
   and/or origin server must to trust.  In the case of interception
   proxies, such third parties are often unknown to both end points of
   the communication.  Unknown third parties may have security
   implications.

   Both proxies and replica selection services may have access to
   aggregated access information.  A proxy typically knows about
   accesses by each client using it, information that is more sensitive
   than the information held by a single origin server.

9.2.2 Logs and legal implications

   Logs from proxies should be kept secure, since they provide
   information about users and their patterns of behaviour.  A proxy's
   log is even more sensitive than a web server log, as every request
   from the user population goes through the proxy.  Logs from replica
   origin servers may need to be amalgamated to get aggregated
   statistics from a service, and 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
   frequently makes resources uncacheable, as in the case of SSL
   encrypted web sessions.

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 replica selection
   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 an interception proxy is a
   denial of service attack, since the end-to-end nature of the Internet
   is destroyed without the content consumer's knowledge.

9.3.2 Replay attack

   A caching proxy is by definition a replay attack.




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


9.3.3 Stupid configuration of proxies

   It is quite easy to have a stupid configuration which will harm
   service for content consumers.  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.  The legal implications of replication and caching are
   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
   previously only available at the network level in a proxy-free world.
   Some network level equipment may have required physical access to get
   sensitive information.  Introduction of application level components
   may require additional system security.

10. Acknowledgements

   The editors would like to thank the following for their assistance:
   David Forster, Alex Rousskov, Josh Cohen, John Martin, John Dilley,
   Ivan Lovric, Joe Touch, Henrik Nordstrom, Patrick McManus, Duane
   Wessels, Wojtek Sylwestrzak, Ted Hardie, Misha Rabinovich, Larry
   Masinter, Keith Moore, Roy Fielding, Patrik Faltstrom, Hilarie Orman,
   Mark Nottingham and Oskar Batuner.

References

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

   [2]   Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
         Version 2", RFC 2186, September 1997.

   [3]   Wessels, D. and K. Claffy, "Application of Internet Cache
         Protocol (ICP), Version 2", RFC 2187, September 1997.





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


   [4]   Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD
         9, RFC 959, October 1985.

   [5]   Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
         D. and B. Alberti, "The Internet Gopher Protocol", RFC 1436,
         March 1993.

   [6]   Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
         Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [7]   Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L.
         Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.

   [8]   Brisco, T., "DNS Support for Load Balancing", RFC 1794, April
         1995.

   [9]   Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
         (HTCP/0.0)", RFC 2756, January 2000.

   [10]  Fan, L., Cao, P., Almeida, J. and A. Broder, "Summary Cache: A
         Scalable Wide-Area Web Cache Sharing Protocol", Proceedings of
         ACM SIGCOMM'98 pp. 254-265, September 1998.

   [11]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", RFC 2104, February 1997.

   [12]  Netscape, Inc., "Navigator Proxy Auto-Config File Format",
         March 1996,
         <URL:http://www.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-
         live.html>.

   [13]  Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web
         Proxy Auto-Discovery Protocol", Work in Progress.

   [14]  Valloppillil, V. and K. Ross, "Cache Array Routing Protocol",
         Work in Progress.

   [15]  Microsoft Corporation, "Cache Array Routing Protocol (CARP)
         v1.0 Specifications, Technical Whitepaper", August 1999,
         <URL:http://www.microsoft.com/Proxy/Guide/carpspec.asp>.

   [16]  Microsoft Corporation, "Cache Array Routing Protocol and
         Microsoft Proxy Server 2.0, Technical White Paper", August
         1998,
         <URL:http://www.microsoft.com/proxy/documents/CarpWP.exe>.

   [17]  Lovric, I., "Internet Cache Protocol Extension", Work in
         Progress.



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


   [18]  Cieslak, M. and D. Forster, "Cisco Web Cache Coordination
         Protocol V1.0", Work in Progress.

   [19]  Cieslak, M., Forster, D., Tiwana, G. and R. Wilson, "Cisco Web
         Cache Coordination Protocol V2.0", Work in Progress.

   [20]  Goutard, C., Lovric, I. and E. Maschio-Esposito, "Pre-filling a
         cache - A satellite overview", Work in Progress.

   [21]  Hamilton, M., Rousskov, A. and D. Wessels, "Cache Digest
         specification - version 5", December 1998,
         <URL:http://www.squid-cache.org/CacheDigest/cache-digest-
         v5.txt>.

   [22]  Cerpa, A., Elson, J., Beheshti, H., Chankhunthod, A., Danzig,
         P., Jalan, R., Neerdaels, C., Shroeder, T. and G. Tomlinson,
         "NECP: The Network Element Control Protocol", Work in Progress.

   [23]  Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems",
         Work in Progress.































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


Authors' Addresses

   Ian Cooper
   Equinix, Inc.
   2450 Bayshore Parkway
   Mountain View, CA  94043
   USA

   Phone: [phone]
   EMail: [e-mail]


   Ingrid Melve
   UNINETT
   Tempeveien 22
   Trondheim  N-7465
   Norway

   Phone: [phone]
   EMail: [e-mail]


   Gary Tomlinson
   CacheFlow Inc.
   12034 134th Ct. NE, Suite 201
   Redmond, WA  98052
   USA

   Phone: [phone]
   EMail: [e-mail]





















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


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.



















Cooper, et al.               Informational                     [Page 32]