RFC 2187                          ICP                     September 1997


8.3.  Different Roles of ICP

   There are two different understandings of what exactly the role of
   ICP is in a cache mesh.  One understanding is that ICP's role is only
   object location, specifically, to provide hints about whether or not
   a named object exists in a neighbor cache.  An implied assumption is
   that cache hits are highly desirable, and ICP is used to maximize the
   chance of getting them.  If an ICP message is lost due to congestion,
   then nothing significant is lost; the request will be satisfied
   regardless.

   ICP is increasingly being tasked to fill a more complex role:
   conveying cache usage policy.  For example, many organizations (e.g.
   universities) will install a Web cache on the border of their
   network.  Such organizations may be happy to establish sibling
   relationships with other, nearby caches, subject to the following
   terms:

   o    Any of the organization's customers or users may request any
        object (cached or not).

   o    Anyone may request an object already in the cache.

   o    Anyone may request any object from the organization's servers
        behind the cache.

   o    All other requests are denied; specifically, the organization
        will not provide transit for requests in which neither the
        client nor the server falls within its domain.

   To successfully convey policy the ICP exchange must very accurately
   predict the result (hit, miss) of a subsequent HTTP request.  The
   result may often depend on other request fields, such as Cache-
   Control.  So it's not possible for ICP to accurately predict the
   result without more, or perhaps all, of the HTTP request.

8.4.  Protocol Design Flaws of ICPv2

   We recognize certain flaws with the original design of ICP, and make
   note of them so that future versions can avoid the same mistakes.

   o    The NULL-terminated URL in the payload field requires stepping
        through the message an octet at a time to find some of the
        fields (i.e. the beginning of object data in an ICP_OP_HIT_OBJ
        message).







 
RFC 2187                          ICP                     September 1997


   o    Two fields (Sender Host Address and Requester Host Address) are
        IPv4 specific.  However, neither of these fields are used in
        practice; they are normally zero-filled.  If IP addresses have a
        role in the ICP message, there needs to be an address family
        descriptor for each address, and clients need to be able to say
        whether they want to hear IPv6 responses or not.

   o    Options are limited to 32 option flags and 32 bits of option
        data.  This should be more like TCP, with an option descriptor
        followed by option data.

   o    Although currently used as the cache key, the URL string no
        longer serves this role adequately.  Some HTTP responses now
        vary according to the requestor's User-Agent and other headers.
        A cache key must incorporate all non-transport headers present
        in the client's request.  All non-hop-by-hop request headers
        should be sent in an ICP query.

   o    ICPv2 uses different opcode values for queries and responses.
        ICP should use the same opcode for both sides of a two-sided
        transaction, with a "query/response" indicator telling which
        side is which.

   o    ICPv2 does not include any authentication fields.

9.  Security Considerations

   Security is an issue with ICP over UDP because of its connectionless
   nature.  Below we consider various vulnerabilities and methods of
   attack, and their implications.

   Our first line of defense is to check the source IP address of the
   ICP message, e.g. as given by recvfrom(2).  ICP query messages should
   be processed if the access control rules allow the querying address
   access to the cache.  However, ICP reply messages must only be
   accepted from known neighbors; a cache must ignore replies from
   unknown addresses.

   Because we trust the validity of an address in an IP packet, ICP is
   susceptible to IP address spoofing.  In this document we address some
   consequences of IP address spoofing.  Normally, spoofed addresses can