rfc2187.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

9.1.  Inserting Bogus ICP Queries

   Processing an ICP_OP_QUERY message has no known security
   implications, so long as the requesting address is granted access to
   the cache.

9.2.  Inserting Bogus ICP Replies

   Here we are concerned with a third party generating ICP reply
   messages which are returned to the querying cache before the real
   reply arrives, or before any replies arrive.  The third party may
   insert bogus ICP replies which appear to come from legitimate
   neighbors.  There are three vulnerabilities:

   o    Preventing a certain neighbor from being used

        If a third-party could send an ICP_OP_MISS_NOFETCH reply back
        before the real reply arrived, the (falsified) neighbor would
        not be used.

        A third-party could blast a cache with ICP_OP_DENIED messages
        until the threshold described in section 5.3.1 is reached,
        thereby causing the neighbor relationship to be temporarily
        terminated.

   o    Forcing a certain neighbor to be used

        If a third-party could send an ICP_OP_HIT reply back before the
        real reply arrived, the (falsified) neighbor would be used.
        This may violate the terms of a sibling relationship; ICP_OP_HIT
        replies mean a subsequent HTTP request will also be a hit.

        Similarly, if bogus ICP_OP_SECHO messages can be generated, the
        cache would retrieve requests directly from the origin server.

o    Cache poisoning

        The ICP_OP_HIT_OBJ message is especially sensitive to security
        issues since it contains actual object data.  In combination
        with IP address spoofing, this option opens up the likely
        possibility of having the cache polluted with invalid objects.










Wessels & Claffy             Informational                     [Page 19]

RFC 2187                          ICP                     September 1997


9.3.  Eavesdropping

   Multicasting ICP queries provides a very simple method for others to
   "snoop" on ICP messages.  If enabling multicast, cache administrators
   should configure the application to use the minimum required
   multicast TTL, using a tool such as mtrace[6].  Note that the IP
   Encapsulating Security Payload [7,9] mechanism can be used to provide
   protection against eavesdropping of ICP messages.

   Eavesdropping on ICP traffic can provide third parties with a list of
   URLs being browsed by cache users.  Because the Requestor Host
   Address is zero-filled by Squid and Harvest, the URLs cannot be
   mapped back to individual host systems.

   By default, Squid and Harvest do not send ICP messages for URLs
   containing `cgi-bin' or `?'.  These URLs sometimes contain sensitive
   information as argument parameters.  Cache administrators need to be
   aware that altering the configuration to make ICP queries for such
   URLs may expose sensitive information to outsiders, especially when
   multicast is used.

9.4.  Blocking ICP Messages

   Intentionally blocked (or discarded) ICP queries or replies will
   appear to reflect link failure or congestion, and will prevent the
   use of a neighbor as well as lead to timeouts (see section 5.1.4).
   If all messages are blocked, the cache will assume the neighbor is
   down and remove it from the selection algorithm.  However, if, for
   example, every other query is blocked, the neighbor will remain
   "alive," but every other request will suffer the ICP timeout.

9.5.  Delaying ICP Messages

   The neighbor selection algorithm normally waits for all ICP MISS
   replies to arrive.  Delaying queries or replies, so that they arrive
   later than they normally would, will cause additional delay for the
   subsequent HTTP request.  Of course, if messages are delayed so that
   they arrive after the timeout, the behavior is the same as "blocking"
   above.

9.6.  Denial of Service

   A denial-of-service attack, where the ICP port is flooded with a
   continuous stream of bogus messages has three vulnerabilities:

   o    The application may log every bogus ICP message and eventually
        fill up a disk partition.




Wessels & Claffy             Informational                     [Page 20]

RFC 2187                          ICP                     September 1997


   o    The socket receive queue may fill up, causing legitimate
        messages to be dropped.

   o    The host may waste some CPU cycles receiving the bogus messages.

9.7.  Altering ICP Fields

   Here we assume a third party is able to change one or more of the ICP
   reply message fields.

   Opcode

      Changing the opcode field is much like inserting bogus messages
      described above.  Changing a hit to a miss would prevent the peer
      from being used.  Changing a miss to a hit would force the peer to
      be used.

   Version

      Altering the ICP version field may have unpredictable consequences
      if the new version number is recognized and supported.  The
      receiving application should ignore messages with invalid version
      numbers.  At the time of this writing, both version numbers 2 and
      3 are in use.  These two versions use some fields (e.g. Options)
      in a slightly different manner.

   Message Length

      An incorrect message length should be detected by the receiving
      application as an invalid ICP message.

   Request Number

      The request number is often used as a part of the cache key.
      Harvest does not use the request number.  Squid uses the request
      number in conjunction with the URL to create a cache key.
      Altering the request number will cause a lookup of the cache key
      to fail.  This is similar to blocking the ICP reply altogether.













Wessels & Claffy             Informational                     [Page 21]

RFC 2187                          ICP                     September 1997


      There is no requirement that a cache use both the URL and the
      request number to locate HTTP requests with outstanding ICP
      queries (however both Squid and Harvest do).  The request number
      must always be the same in the query and the reply.  However, if
      the querying cache uses only the request number to locate pending
      requests, there is some possibility that a replying cache might
      increment the request number in the reply to give the false
      impression that the two caches are closer than they really are.
      In other words, assuming that there are a few ICP requests "in
      flight" at any given time, incrementing the reply request number
      trick the querying cache into seeing a smaller round-trip time
      than really exists.

   Options

      There is little risk in having the Options bitfields altered.  Any
      option bit must only be set in a reply if it was also set in a
      query.  Changing a bit from clear to set is detectable by the
      querying cache, and such a message must be ignored.  Changing a
      bit from set to clear is allowed and has no negative side effects.

   Option Data

      ICP_FLAG_SRC_RTT is the only option which uses the Option Data
      field.  Altering the RTT values returned here can affect the
      neighbor selection algorithm, either forcing or preventing the use
      of a neighbor.

   URL

      The URL and Request Number are used to generate the cache key.
      Altering the URL will cause a lookup of the cache key to fail, and
      the ICP reply to be entirely ignored.  This is similar to blocking
      the ICP reply altogether.

9.8.  Summary

   o    ICP_OP_HIT_OBJ is particularly vulnerable to security problems
        because it includes object data.  For this, and other reasons,
        its use is discouraged.

   o    Falsifying, altering, inserting, or blocking ICP messages can
        cause an HTTP request to fail only in two situations:

        -    If the cache is behind a firewall and cannot directly
             connect to the origin server.





Wessels & Claffy             Informational                     [Page 22]

RFC 2187                          ICP                     September 1997


        -    If a false ICP_OP_HIT reply causes the HTTP request to be
             forwarded to a sibling, where the request is a cache miss
             and the sibling refuses to continue forwarding the request
             on behalf of the originating cache.

   o    Falsifying, altering, inserting, or blocking ICP messages can
        easily cause HTTP requests to be forwarded (or not forwarded) to
        certain neighbors.  If the neighbor cache has also been
        compromised, then it could serve bogus content and pollute a
        cache hierarchy.

   o    Blocking or delaying ICP messages can cause HTTP request to be
        further delayed, but still satisfied.


10.  References

   [1] Fielding, R., et. al, "Hypertext Transfer Protocol -- HTTP/1.1",
   RFC 2068, UC Irvine, January 1997.

   [2] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource
   Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota,
   December 1994.

   [3] Bowman M., Danzig P., Hardy D., Manber U., Schwartz M., and
   Wessels D., "The Harvest Information Discovery and Access System",
   Internet Research Task Force - Resource Discovery,
   http://harvest.transarc.com/.

   [4] Wessels D., Claffy K., "ICP and the Squid Web Cache", National
   Laboratory for Applied Network Research,
   http://www.nlanr.net/~wessels/Papers/icp-squid.ps.gz.

   [5] Wessels D., "The Squid Internet Object Cache", National
   Laboratory for Applied Network Research,
   http://squid.nlanr.net/Squid/

   [6] mtrace, Xerox PARC, ftp://ftp.parc.xerox.com/pub/net-
   research/ipmulti/.

   [7] Atkinson, R., "Security Architecture for the Internet Protocol",
   RFC 1825, NRL, August 1995.

   [8] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, August
   1995.

   [9] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC
   1827, NRL, August 1995.



Wessels & Claffy             Informational                     [Page 23]

RFC 2187                          ICP                     September 1997


11.  Acknowledgments

   The authors wish to thank Paul A Vixie <[e-mail]> for providing
   excellent feedback on this document, Martin Hamilton
   <[e-mail]> for pushing the development of multicast ICP,
   Eric Rescorla <[e-mail]> and Randall Atkinson <[e-mail]>
   for assisting with security issues, and especially Allyn Romanow for
   keeping us on the right track.


12.  Authors' Addresses

   Duane Wessels
   National Laboratory for Applied Network Research
   10100 Hopkins Drive
   La Jolla, CA 92093

   EMail: [e-mail]


   K. Claffy
   National Laboratory for Applied Network Research
   10100 Hopkins Drive
   La Jolla, CA 92093

   EMail: [e-mail]

























Wessels & Claffy             Informational                     [Page 24]