home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2187 < prev    next >
Text File  |  1997-09-05  |  52KB  |  1,348 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          D. Wessels
  8. Request for Comments: 2187                                      K. Claffy
  9. Category: Informational                   National Laboratory for Applied
  10.                                                     Network Research/UCSD
  11.                                                            September 1997
  12.  
  13.         Application of Internet Cache Protocol (ICP), version 2
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    This document describes the application of ICPv2 (Internet Cache
  24.    Protocol version 2, RFC2186) to Web caching.  ICPv2 is a lightweight
  25.    message format used for communication among Web caches.  Several
  26.    independent caching implementations now use ICP[3,5], making it
  27.    important to codify the existing practical uses of ICP for those
  28.    trying to implement, deploy, and extend its use.
  29.  
  30.    ICP queries and replies refer to the existence of URLs (or objects)
  31.    in neighbor caches.  Caches exchange ICP messages and use the
  32.    gathered information to select the most appropriate location from
  33.    which to retrieve an object.  A companion document (RFC2186)
  34.    describes the format and syntax of the protocol itself.  In this
  35.    document we focus on issues of ICP deployment, efficiency, security,
  36.    and interaction with other aspects of Web traffic behavior.
  37.  
  38. Table of Contents
  39.  
  40.    1.   Introduction.................................................  2
  41.    2.   Web Cache Hierarchies........................................  3
  42.    3.   What is the Added Value of ICP?..............................  5
  43.    4.   Example Configuration of ICP Hierarchy.......................  5
  44.      4.1. Configuring the `proxy.customer.org' cache.................  6
  45.      4.2. Configuring the `cache.isp.com' cache......................  6
  46.    5.   Applying the Protocol........................................  7
  47.      5.1. Sending ICP Queries........................................  8
  48.      5.2. Receiving ICP Queries and Sending Replies.................. 10
  49.      5.3. Receiving ICP Replies...................................... 11
  50.      5.4. ICP Options................................................ 13
  51.    6.   Firewalls.................................................... 14
  52.    7.   Multicast.................................................... 14
  53.    8.   Lessons Learned.............................................. 16
  54.      8.1. Differences Between ICP and HTTP........................... 16
  55.  
  56.  
  57.  
  58. Wessels & Claffy             Informational                      [Page 1]
  59.  
  60. RFC 2187                          ICP                     September 1997
  61.  
  62.  
  63.      8.2. Parents, Siblings, Hits and Misses......................... 16
  64.      8.3. Different Roles of ICP..................................... 17
  65.      8.4. Protocol Design Flaws of ICPv2............................. 17
  66.    9.   Security Considerations...................................... 18
  67.      9.1. Inserting Bogus ICP Queries................................ 19
  68.      9.2. Inserting Bogus ICP Replies................................ 19
  69.      9.3. Eavesdropping.............................................. 20
  70.      9.4. Blocking ICP Messages...................................... 20
  71.      9.5. Delaying ICP Messages...................................... 20
  72.      9.6. Denial of Service.......................................... 20
  73.      9.7. Altering ICP Fields........................................ 21
  74.      9.8. Summary.................................................... 22
  75.    10.  References................................................... 23
  76.    11.  Acknowledgments.............................................. 24
  77.    12.  Authors' Addresses........................................... 24
  78.  
  79. 1.  Introduction
  80.  
  81.    ICP is a lightweight message format used for communicating among Web
  82.    caches.  ICP is used to exchange hints about the existence of URLs in
  83.    neighbor caches.  Caches exchange ICP queries and replies to gather
  84.    information for use in selecting the most appropriate location from
  85.    which to retrieve an object.
  86.  
  87.    This document describes the implementation of ICP in software.  For a
  88.    description of the protocol and message format, please refer to the
  89.    companion document (RFC2186).  We avoid making judgments about
  90.    whether or how ICP should be used in particular Web caching
  91.    configurations.  ICP may be a "net win" in some situations, and a
  92.    "net loss" in others.  We recognize that certain practices described
  93.    in this document are suboptimal. Some of these exist for historical
  94.    reasons.  Some aspects have been improved in later versions.  Since
  95.    this document only serves to describe current practices, we focus on
  96.    documenting rather than evaluating.  However, we do address known
  97.    security problems and other shortcomings.
  98.  
  99.    The remainder of this document is written as follows.  We first
  100.    describe Web cache hierarchies, explain motivation for using ICP, and
  101.    demonstrate how to configure its use in cache hierarchies.  We then
  102.    provide a step-by-step description of an ICP query-response
  103.    transaction.  We then discuss ICP interaction with firewalls, and
  104.    briefly touch on multicasting ICP.  We end with lessons with have
  105.    learned during the protocol development and deployement thus far, and
  106.    the canonical security considerations.
  107.  
  108.    ICP was initially developed by Peter Danzig, et. al.  at the
  109.    University of Southern California as a central part of hierarchical
  110.    caching in the Harvest research project[3].
  111.  
  112.  
  113.  
  114. Wessels & Claffy             Informational                      [Page 2]
  115.  
  116. RFC 2187                          ICP                     September 1997
  117.  
  118.  
  119. 2.  Web Cache Hierarchies
  120.  
  121.    A single Web cache will reduce the amount of traffic generated by the
  122.    clients behind it.  Similarly, a group of Web caches can benefit by
  123.    sharing another cache in much the same way.  Researchers on the
  124.    Harvest project envisioned that it would be important to connect Web
  125.    caches hierarchically.  In a cache hierarchy (or mesh) one cache
  126.    establishes peering relationships with its neighbor caches.  There
  127.    are two types of relationship: parent and sibling.  A parent cache is
  128.    essentially one level up in a cache hierarchy.  A sibling cache is on
  129.    the same level.  The terms "neighbor" and "peer" are used to refer to
  130.    either parents or siblings which are a single "cache-hop" away.
  131.    Figure 1 shows a simple hierarchy configuration.
  132.  
  133.    But what does it mean to be "on the same level" or "one level up?"
  134.    The general flow of document requests is up the hierarchy.  When a
  135.    cache does not hold a requested object, it may ask via ICP whether
  136.    any of its neighbor caches has the object.  If any of the neighbors
  137.    does have the requested object (i.e., a "neighbor hit"), then the
  138.    cache will request it from them.  If none of the neighbors has the
  139.    object (a "neighbor miss"), then the cache must forward the request
  140.    either to a parent, or directly to the origin server.  The essential
  141.    difference between a parent and sibling is that a "neighbor hit" may
  142.    be fetched from either one, but a "neighbor miss" may NOT be fetched
  143.    from a sibling.  In other words, in a sibling relationship, a cache
  144.    can only ask to retrieve objects that the sibling already has cached,
  145.    whereas the same cache can ask a parent to retrieve any object
  146.    regardless of whether or not it is cached.  A parent cache's role is
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Wessels & Claffy             Informational                      [Page 3]
  171.  
  172. RFC 2187                          ICP                     September 1997
  173.  
  174.  
  175.      T H E   I N T E R N E T
  176.    ===========================
  177.        |          ||
  178.        |          ||
  179.        |          ||
  180.        |          ||
  181.        |      +----------------------+
  182.        |      |                      |
  183.        |      |        PARENT        |
  184.        |      |        CACHE         |
  185.        |      |                      |
  186.        |      +----------------------+
  187.        |          ||
  188.      DIRECT       ||
  189.    RETRIEVALS     ||
  190.        |          ||
  191.        |         HITS
  192.        |         AND
  193.        |        MISSES
  194.        |       RESOLVED
  195.        |          ||
  196.        |          ||
  197.        |          ||
  198.        V          \/
  199.    +------------------+                    +------------------+
  200.    |                  |                    |                  |
  201.    |      LOCAL       |/--------HITS-------|     SIBLING      |
  202.    |      CACHE       |\------RESOLVED-----|      CACHE       |
  203.    |                  |                    |                  |
  204.    +------------------+                    +------------------+
  205.       |  |  |  |  |
  206.       |  |  |  |  |
  207.       |  |  |  |  |
  208.       V  V  V  V  V
  209.    ===================
  210.       CACHE CLIENTS
  211.  
  212.    FIGURE 1: A Simple Web cache hierarchy.  The local cache can retrieve
  213.    hits from sibling caches, hits and misses from parent caches, and
  214.    some requests directly from origin servers.
  215.  
  216.    to provide "transit" for the request if necessary, and accordingly
  217.    parent caches are ideally located within or on the way to a transit
  218.    Internet service provider (ISP).
  219.  
  220.    Squid and Harvest allow for complex hierarchical configurations.  For
  221.    example, one could specify that a given neighbor be used for only a
  222.    certain class of requests, such as URLs from a specific DNS domain.
  223.  
  224.  
  225.  
  226. Wessels & Claffy             Informational                      [Page 4]
  227.  
  228. RFC 2187                          ICP                     September 1997
  229.  
  230.  
  231.    Additionally, it is possible to treat a neighbor as a sibling for
  232.    some requests and as a parent for others.
  233.  
  234.    The cache hierarchy model described here includes a number of
  235.    features to prevent top-level caches from becoming choke points.  One
  236.    is the ability to restrict parents as just described previously (by
  237.    domains).  Another optimization is that the cache only forwards
  238.    cachable requests to its neighbors.  A large class of Web requests
  239.    are inherently uncachable, including: requests requiring certain
  240.    types of authentication, session-encrypted data, highly personalized
  241.    responses, and certain types of database queries.  Lower level caches
  242.    should handle these requests directly rather than burdening parent
  243.    caches.
  244.  
  245. 3.  What is the Added Value of ICP?
  246.  
  247.    Although it is possible to maintain cache hierarchies without using
  248.    ICP, the lack of ICP or something similar prohibits the existence of
  249.    sibling meta-communicative relationships, i.e., mechanisms to query
  250.    nearby caches about a given document.
  251.  
  252.    One concern over the use of ICP is the additional delay that an ICP
  253.    query/reply exchange contributes to an HTTP transaction.  However, if
  254.    the ICP query can locate the object in a nearby neighbor cache, then
  255.    the ICP delay may be more than offset by the faster delivery of the
  256.    data from the neighbor.  In order to minimize ICP delays, the caches
  257.    (as well as the protocol itself) are designed to return ICP requests
  258.    quickly.  Indeed, the application does minimal processing of the ICP
  259.    request, most ICP-related delay is due to transmission on the
  260.    network.
  261.  
  262.    ICP also serves to provide an indication of neighbor reachability.
  263.    If ICP replies from a neighbor fail to arrive, then either the
  264.    network path is congested (or down), or the cache application is not
  265.    running on the ICP-queried neighbor machine.  In either case, the
  266.    cache should not use this neighbor at this time.  Additionally,
  267.    because an idle cache can turn around the replies faster than a busy
  268.    one, all other things being equal, ICP provides some form of load
  269.    balancing.
  270.  
  271. 4.  Example Configuration of ICP Hierarchy
  272.  
  273.    Configuring caches within a hierarchy requires establishing peering
  274.    relationships, which currently involves manual configuration at both
  275.    peering endpoints.  One cache must indicate that the other is a
  276.    parent or sibling.  The other cache will most likely have to add the
  277.    first cache to its access control lists.
  278.  
  279.  
  280.  
  281.  
  282. Wessels & Claffy             Informational                      [Page 5]
  283.  
  284. RFC 2187                          ICP                     September 1997
  285.  
  286.  
  287.    Below we show some sample configuration lines for a hypothetical
  288.    situation.  We have two caches, one operated by an ISP, and another
  289.    operated by a customer.  First we describe how the customer would
  290.    configure his cache to peer with the ISP.  Second, we describe how
  291.    the ISP would allow the customer access to its cache.
  292.  
  293. 4.1.  Configuring the `proxy.customer.org' cache
  294.  
  295.    In Squid, to configure parents and siblings in a hierarchy, a
  296.    `cache_host' directive is entered into the configuration file.  The
  297.    format is:
  298.  
  299.        cache_host hostname type http-port icp-port [options]
  300.  
  301.    Where type is either `parent', `sibling', or `multicast'.  For our
  302.    example, it would be:
  303.  
  304.        cache_host cache.isp.com parent 8080 3130
  305.  
  306.    This configuration will cause the customer cache to resolve most
  307.    cache misses through the parent (`cgi-bin' and non-GET requests would
  308.    be resolved directly).  Utilizing the parent may be undesirable for
  309.    certain servers, such as servers also in the customer.org domain.  To
  310.    always handle such local domains directly, the customer would add
  311.    this to his configuration file:
  312.  
  313.        local_domain customer.org
  314.  
  315.    It may also be the case that the customer wants to use the ISP cache
  316.    only for a specific subset of DNS domains.  The need to limit
  317.    requests this way is actually more common for higher levels of cache
  318.    hierarchies, but it is illustrated here nonetheless.  To limit the
  319.    ISP cache to a subset of DNS domains, the customer would use:
  320.  
  321.        cache_host_domain cache.isp.com com net org
  322.  
  323.    Then, any requests which are NOT in the .com, .net, or .org domains
  324.    would be handled directly.
  325.  
  326. 4.2.  Configuring the `cache.isp.com' cache
  327.  
  328.    relationship one uses access lists, similar to those used in routing
  329.    peers.  The access lists support a large degree of customization in
  330.    the peering relationship.  If there are no access lines present, the
  331.    cache allows the request by default.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Wessels & Claffy             Informational                      [Page 6]
  339.  
  340. RFC 2187                          ICP                     September 1997
  341.  
  342.  
  343.    Note that the cache.isp.com cache need not explicitly specify the
  344.    customer cache as a peer, nor is the type of relationship encoded
  345.    within the ICP query itself.  The access control entries regulate the
  346.    relationships between this cache and its neighbors.  For our example,
  347.    the ISP would use:
  348.  
  349.        acl src Customer  proxy.customer.org
  350.        http_access allow Customer
  351.        icp_access  allow Customer
  352.  
  353.    This defines an access control entry named `Customer' which specifies
  354.    a source IP address of the customer cache machine.  The customer
  355.    cache would then be allowed to make any request to both the HTTP and
  356.    ICP ports (including cache misses).  This configuration implies that
  357.    the ISP cache is a parent of the customer.
  358.  
  359.    If the ISP wanted to enforce a sibling relationship, it would need to
  360.    deny access to cache misses.  This would be done as follows:
  361.  
  362.        miss_access deny Customer
  363.  
  364.    Of course the ISP should also communicate this to the customer, so
  365.    that the customer will change his configuration from parent to
  366.    sibling.  Otherwise, if the customer requests an object not in the
  367.    ISP cache, an error message is generated.
  368.  
  369. 5.  Applying the Protocol
  370.  
  371.    The following sections describe the ICP implementation in the
  372.    Harvest[3] (research version) and Squid Web cache[5] packages.  In
  373.    terms of version numbers, this means version 1.4pl2 for Harvest and
  374.    version 1.1.10 for Squid.
  375.  
  376.    The basic sequence of events in an ICP transaction is as follows:
  377.  
  378.    1.   Local cache receives an HTTP[1] request from a cache client.
  379.  
  380.    2.   The local cache sends ICP queries (section 5.1).
  381.  
  382.    3.   The peer cache(s) receive the queries and send ICP replies
  383.         (section 5.2).
  384.  
  385.    4.   The local cache receives the ICP replies and decides where to
  386.         forward the request (section 5.3).
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Wessels & Claffy             Informational                      [Page 7]
  395.  
  396. RFC 2187                          ICP                     September 1997
  397.  
  398.  
  399. 5.1.  Sending ICP Queries
  400.  
  401. 5.1.1.  Determine whether to use ICP at all
  402.  
  403.    Not every HTTP request requires an ICP query to be sent.  Obviously,
  404.    cache hits will not need ICP because the request is satisfied
  405.    immediately.  For origin servers very close to the cache, we do not
  406.    want to use any neighbor caches.  In Squid and Harvest, the
  407.    administrator specifies what constitutes a `local' server with the
  408.    `local_domain' and `local_ip' configuration options.  The cache
  409.    always contacts a local server directly, never querying a peer cache.
  410.  
  411.    There are other classes of requests that the cache (or the
  412.    administrator) may prefer to forward directly to the origin server.
  413.    In Squid and Harvest, one such class includes all non-GET request
  414.    methods.  A Squid cache can also be configured to not use peers for
  415.    URLs matching the `hierarchy_stoplist'.
  416.  
  417.    In order for an HTTP request to yield an ICP transaction, it must:
  418.  
  419.    o    not be a cache hit
  420.  
  421.    o    not be to a local server
  422.  
  423.    o    be a GET request, and
  424.  
  425.    o    not match the `hierarchy_stoplist' configuration.
  426.  
  427.    We call this a "hierarchical" request.  A "non-hierarchical" request
  428.    is one that doesn't generate any ICP traffic.  To avoid processing
  429.    requests that are likely to lower cache efficiency, one can configure
  430.    the cache to not consult the hierarchy for URLs that contain certain
  431.    strings (e.g. `cgi_bin').
  432.  
  433. 5.1.2.  Determine which peers to query
  434.  
  435.    By default, a cache sends an ICP_OP_QUERY message to each peer,
  436.    unless any one of the following are true:
  437.  
  438.    o    Restrictions prevent querying a peer for this request, based on
  439.         the configuration directive `cache_host_domain', which specifies
  440.         a set of DNS domains (from the URLs) for which the peer should
  441.         or should not be queried.  In Squid, a more flexible directive
  442.         ('cache_host_acl') supports restrictions on other parts of the
  443.         request (method, port number, source, etc.).
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Wessels & Claffy             Informational                      [Page 8]
  451.  
  452. RFC 2187                          ICP                     September 1997
  453.  
  454.  
  455.    o    The peer is a sibling, and the HTTP request includes a "Pragma:
  456.         no-cache" header.  This is because the sibling would be asked to
  457.         transit the request, which is not allowed.
  458.  
  459.    o    The peer is configured to never be sent ICP queries (i.e. with
  460.         the `no-query' option).
  461.  
  462.    If the determination yields only one queryable ICP peer, and the
  463.    Squid configuration directive `single_parent_bypass' is set, then one
  464.    can bypass waiting for the single ICP response and just send the HTTP
  465.    request directly to the peer cache.
  466.  
  467.    The Squid configuration option `source_ping' configures a Squid cache
  468.    to send a ping to the original source simultaneous with its ICP
  469.    queries, in case the origin is closer than any of the caches.
  470.  
  471. 5.1.3.  Calculate the expected number of ICP replies
  472.  
  473.    Harvest and Squid want to maximize the chance to get a HIT reply from
  474.    one of the peers.  Therefore, the cache waits for all ICP replies to
  475.    be received.  Normally, we expect to receive an ICP reply for each
  476.    query sent, except:
  477.  
  478.    o    When the peer is believed to be down.  If the peer is down Squid
  479.         and Harvest continue to send it ICP queries, but do not expect
  480.         the peer to reply.  When an ICP reply is again received from the
  481.         peer, its status will be changed to up.
  482.  
  483.         The determination of up/down status has varied a little bit as
  484.         the Harvest and Squid software evolved.  Both Harvest and Squid
  485.         mark a peer down when it fails to reply to 20 consecutive ICP
  486.         queries.  Squid also marks a peer down when a TCP connection
  487.         fails, and up again when a diagnostic TCP connection succeeds.
  488.  
  489.    o    When sending to a multicast address.  In this case we'll
  490.         probably expect to receive more than one reply, and have no way
  491.         to definitively determine how many to expect.  We discuss
  492.         multicast issues in section 7 below.
  493.  
  494.  
  495. 5.1.4.  Install timeout event
  496.  
  497.    Because ICP uses UDP as underlying transport, ICP queries and replies
  498.    may sometimes be dropped by the network.  The cache installs a
  499.    timeout event in case not all of the expected replies arrive.  By
  500.    default Squid and Harvest use a two-second timeout.  If object
  501.    retrieval has not commenced when the timeout occurs, a source is
  502.    selected as described in section 5.3.9 below.
  503.  
  504.  
  505.  
  506. Wessels & Claffy             Informational                      [Page 9]
  507.  
  508. RFC 2187                          ICP                     September 1997
  509.  
  510.  
  511. 5.2.  Receiving ICP Queries and Sending Replies
  512.  
  513.    When an ICP_OP_QUERY message is received, the cache examines it and
  514.    decides which reply message is to be sent.  It will send one of the
  515.    following reply opcodes, tested for use in the order listed:
  516.  
  517. 5.2.1.  ICP_OP_ERR
  518.  
  519.    The URL is extracted from the payload and parsed.  If parsing fails,
  520.    an ICP_OP_ERR message is returned.
  521.  
  522. 5.2.2.  ICP_OP_DENIED
  523.  
  524.    The access controls are checked.  If the peer is not allowed to make
  525.    this request, ICP_OP_DENIED is returned.  Squid counts the number of
  526.    ICP_OP_DENIED messages sent to each peer.  If more than 95% of more
  527.    than 100 replies have been denied, then no reply is sent at all.
  528.    This prevents misconfigured caches from endlessly sending unnecessary
  529.    ICP messages back and forth.
  530.  
  531. 5.2.3.  ICP_OP_HIT
  532.  
  533.    If the cache reaches this point without already matching one of the
  534.    previous  opcodes, it means the request is allowed and we must
  535.    determine if it will be HIT or MISS, so we check if the URL exists in
  536.    the local cache.  If so, and if the cached entry is fresh for at
  537.    least the next 30 seconds, we can return an ICP_OP_HIT message.  The
  538.    stale/fresh determination uses the local refresh (or TTL) rules.
  539.  
  540.    Note that a race condition exists for ICP_OP_HIT replies to sibling
  541.    peers.  The ICP_OP_HIT means that a subsequent HTTP request for the
  542.    named URL would result in a cache hit.  We assume that the HTTP
  543.    request will come very quickly after the ICP_OP_HIT.  However, there
  544.    is a slight chance that the object might be purged from this cache
  545.    before the HTTP request is received.  If this happens, and the
  546.    replying peer has applied Squid's `miss_access' configuration then
  547.    the user will receive a very confusing access denied message.
  548.  
  549. 5.2.3.1.  ICP_OP_HIT_OBJ
  550.  
  551.    Before returning the ICP_OP_HIT message, we see if we can send an
  552.    ICP_OP_HIT_OBJ message instead.  We can use ICP_OP_HIT_OBJ if:
  553.  
  554.    o    The ICP_OP_QUERY message had the ICP_FLAG_HIT_OBJ flag set.
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Wessels & Claffy             Informational                     [Page 10]
  563.  
  564. RFC 2187                          ICP                     September 1997
  565.  
  566.  
  567.    o    The entire object (plus URL) will fit in an ICP message.  The
  568.         maximum ICP message size is 16 Kbytes, but an application may
  569.         choose to set a smaller maximum value for ICP_OP_HIT_OBJ
  570.         replies.
  571.  
  572.    Normally ICP replies are sent immediately after the query is
  573.    received, but the ICP_OP_HIT_OBJ message cannot be sent until the
  574.    object data is available to copy into the reply message.  For Squid
  575.    and Harvest this means the object must be "swapped in" from disk if
  576.    it is not already in memory.  Therefore, on average, an
  577.    ICP_OP_HIT_OBJ reply will have higher latency than ICP_OP_HIT.
  578.  
  579. 5.2.4.  ICP_OP_MISS_NOFETCH
  580.  
  581.    At this point we have a cache miss.  ICP has two types of miss
  582.    replies.  If the cache does not want the peer to request the object
  583.    from it, it sends an ICP_OP_MISS_NOFETCH message.
  584.  
  585. 5.2.5.  ICP_OP_MISS
  586.  
  587.    Finally, an ICP_OP_MISS reply is returned as the default.  If the
  588.    replying cache is a parent of the querying cache, the ICP_OP_MISS
  589.    indicates an invitation to fetch the URL through the replying cache.
  590.  
  591. 5.3.  Receiving ICP Replies
  592.  
  593.    Some ICP replies will be ignored; specifically, when any of the
  594.    following are true:
  595.  
  596.    o    The reply message originated from an unknown peer.
  597.  
  598.    o    The object named by the URL does not exist.
  599.  
  600.    o    The object is already being fetched.
  601.  
  602. 5.3.1.  ICP_OP_DENIED
  603.  
  604.    If more than 95% of more than 100 replies from a peer cache have been
  605.    ICP_OP_DENIED, then such a high denial rate most likely indicates a
  606.    configuration error, either locally or at the peer.  For this reason,
  607.    no further queries will be sent to the peer for the duration of the
  608.    cache process.
  609.  
  610. 5.3.2.  ICP_OP_HIT
  611.  
  612.    Object retrieval commences immediately from the replying peer.
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Wessels & Claffy             Informational                     [Page 11]
  619.  
  620. RFC 2187                          ICP                     September 1997
  621.  
  622.  
  623. 5.3.3.  ICP_OP_HIT_OBJ
  624.  
  625.    The object data is extracted from the ICP message and the retrieval
  626.    is complete.  If there is some problem with the ICP_OP_HIT_OBJ
  627.    message (e.g. missing data) the reply will be treated like a standard
  628.    ICP_OP_HIT.
  629.  
  630. 5.3.4.  ICP_OP_SECHO
  631.  
  632.    Object retrieval commences immediately from the origin server because
  633.    the ICP_OP_SECHO reply arrived prior to any ICP_OP_HIT's.  If an
  634.    ICP_OP_HIT had arrived prior, this ICP_OP_SECHO reply would be
  635.    ignored because the retrieval has already started.
  636.  
  637. 5.3.5.  ICP_OP_DECHO
  638.  
  639.    An ICP_OP_DECHO reply is handled like an ICP_OP_MISS.  Non-ICP peers
  640.    must always be configured as parents; a non-ICP sibling makes no
  641.    sense.  One serious problem with the ICP_OP_DECHO feature is that
  642.    since it bounces messages off the peer's UDP echo port, it does not
  643.    indicate that the peer cache is actually running -- only that network
  644.    connectivity exists between the pair.
  645.  
  646. 5.3.6.  ICP_OP_MISS
  647.  
  648.    If the peer is a sibling, the ICP_OP_MISS reply is ignored.
  649.    Otherwise, the peer may be "remembered" for future use in case no HIT
  650.    replies are received later (section 5.3.9).
  651.  
  652.    Harvest and Squid remember the first parent to return an ICP_OP_MISS
  653.    message.  With Squid, the parents may be weighted so that the "first
  654.    parent to miss" may not actually be the first reply received.  We
  655.    call this the FIRST_PARENT_MISS.  Remember that sibling misses are
  656.    entirely ignored, we only care about misses from parents.  The parent
  657.    miss RTT's can be weighted because sometimes the closest parent is
  658.    not the one people want to use.
  659.  
  660.    Also, recent versions of Squid may remember the parent with the
  661.    lowest RTT to the origin server, using the ICP_FLAG_SRC_RTT option.
  662.    We call this the CLOSEST_PARENT_MISS.
  663.  
  664. 5.3.7.  ICP_OP_MISS_NOFETCH
  665.  
  666.    This reply is essentially ignored.  A cache must not forward a
  667.    request to a peer that returns ICP_OP_MISS_NOFETCH.
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Wessels & Claffy             Informational                     [Page 12]
  675.  
  676. RFC 2187                          ICP                     September 1997
  677.  
  678.  
  679. 5.3.8.  ICP_OP_ERR
  680.  
  681.    Silently ignored.
  682.  
  683. 5.3.9.  When all peers MISS.
  684.  
  685.    For ICP_OP_HIT and ICP_OP_SECHO the request is forwarded immediately.
  686.    For ICP_OP_HIT_OBJ there is no need to forward the request.  For all
  687.    other reply opcodes, we wait until the expected number of replies
  688.    have been received.  When we have all of the expected replies, or
  689.    when the query timeout occurs, it is time to forward the request.
  690.  
  691.    Since MISS replies were received from all peers, we must either
  692.    select a parent cache or the origin server.
  693.  
  694.    o    If the peers are using the ICP_FLAG_SRC_RTT feature, we forward
  695.         the request to the peer with the lowest RTT to the origin
  696.         server.  If the local cache is also measuring RTT's to origin
  697.         servers, and is closer than any of the parents, the request is
  698.         forwarded directly to the origin server.
  699.  
  700.    o    If there is a FIRST_PARENT_MISS parent available, the request
  701.         will be forwarded there.
  702.  
  703.    o    If the ICP query/reply exchange did not produce any appropriate
  704.         parents, the request will be sent directly to the origin server
  705.         (unless firewall restrictions prevent it).
  706.  
  707. 5.4.  ICP Options
  708.  
  709.    The following options were added to Squid to support some new
  710.    features while maintaining backward compatibility with the Harvest
  711.    implementation.
  712.  
  713. 5.4.1.  ICP_FLAG_HIT_OBJ
  714.  
  715.    This flag is off by default and will be set in an ICP_OP_QUERY
  716.    message only if these three criteria are met:
  717.  
  718.    o    It is enabled in the cache configuration file with `udp_hit_obj
  719.         on'.
  720.  
  721.    o    The peer must be using ICP version 2.
  722.  
  723.    o    The HTTP request must not include the "Pragma: no-cache" header.
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Wessels & Claffy             Informational                     [Page 13]
  731.  
  732. RFC 2187                          ICP                     September 1997
  733.  
  734.  
  735. 5.4.2.  ICP_FLAG_SRC_RTT
  736.  
  737.    This flag is off by default and will be set in an ICP_OP_QUERY
  738.    message only if these two criteria are met:
  739.  
  740.    o    It is enabled in the cache configuration file with `query_icmp
  741.         on'.
  742.  
  743.    o    The peer must be using ICP version 2.
  744.  
  745.  
  746. 6.  Firewalls
  747.  
  748.    Operating a Web cache behind a firewall or in a private network poses
  749.    some interesting problems.  The hard part is figuring out whether the
  750.    cache is able to connect to the origin server.  Harvest and Squid
  751.    provide an `inside_firewall' configuration directive to list DNS
  752.    domains on the near side of a firewall.  Everything else is assumed
  753.    to be on the far side of a firewall.  Squid also has a `firewall_ip'
  754.    directive so that inside hosts can be specified by IP addresses as
  755.    well.
  756.  
  757.    In a simple configuration, a Squid cache behind a firewall will have
  758.    only one parent cache (which is on the firewall itself).  In this
  759.    case, Squid must use that parent for all servers beyond the firewall,
  760.    so there is no need to utilize ICP.
  761.  
  762.    In a more complex configuration, there may be a number of peer caches
  763.    also behind the firewall.  Here, ICP may be used to check for cache
  764.    hits in the peers.  Occasionally, when ICP is being used, there may
  765.    not be any replies received.  If the cache were not behind a
  766.    firewall, the request would be forwarded directly to the origin
  767.    server.  But in this situation, the cache must pick a parent cache,
  768.    either randomly or due to configuration information.  For example,
  769.    Squid allows a parent cache to be designated as a default choice when
  770.    no others are available.
  771.  
  772. 7.  Multicast
  773.  
  774.    For efficient distribution, a cache may deliver ICP queries to a
  775.    multicast address, and neighbor caches may join the multicast group
  776.    to receive such queries.
  777.  
  778.    Current practice is that caches send ICP replies only to unicast
  779.    addresses, for several reasons:
  780.  
  781.    o    Multicasting ICP replies would not reduce the number of packets
  782.         sent.
  783.  
  784.  
  785.  
  786. Wessels & Claffy             Informational                     [Page 14]
  787.  
  788. RFC 2187                          ICP                     September 1997
  789.  
  790.  
  791.    o    It prevents other group members from receiving unexpected
  792.         replies.
  793.  
  794.    o    The reply should follow unicast routing paths to indicate
  795.         (unicast) connectivity between the receiver and the sender since
  796.         the subsequent HTTP request will be unicast routed.
  797.  
  798.    Trust is an important aspect of inter-cache relationships.  A Web
  799.    cache should not automatically trust any cache which replies to a
  800.    multicast ICP query.  Caches should ignore ICP messages from
  801.    addresses not specifically configured as neighbors.  Otherwise, one
  802.    could easily pollute a cache mesh by running an illegitimate cache
  803.    and having it join a group, return ICP_OP_HIT for all requests, and
  804.    then deliver bogus content.
  805.  
  806.    When sending to multicast groups, cache administrators must be
  807.    careful to use the minimum multicast TTL required to reach all group
  808.    members.  Joining a multicast group requires no special privileges
  809.    and there is no way to prevent anyone from joining "your" group.  Two
  810.    groups of caches utilizing the same multicast address could overlap,
  811.    which would cause a cache to receive ICP replies from unknown
  812.    neighbors.  The unknown neighbors would not be used to retrieve the
  813.    object data, but the cache would constantly receive ICP replies that
  814.    it must always ignore.
  815.  
  816.    To prevent an overlapping cache mesh, caches should thus limit the
  817.    scope of their ICP queries with appropriate TTLs; an application such
  818.    as mtrace[6] can determine appropriate multicast TTLs.
  819.  
  820.    As mentioned in section 5.1.3, we need to estimate the number of
  821.    expected replies for an ICP_OP_QUERY message.  For unicast we expect
  822.    one reply for each query if the peer is up.  However, for multicast
  823.    we generally expect more than one reply, but have no way of knowing
  824.    exactly how many replies to expect.  Squid regularly (every 15
  825.    minutes) sends out test ICP_OP_QUERY messages to only the multicast
  826.    group peers.  As with a real ICP query, a timeout event is installed
  827.    and the replies are counted until the timeout occurs.  We have found
  828.    that the received count varies considerably.  Therefore, the number
  829.    of replies to expect is calculated as a moving average, rounded down
  830.    to the nearest integer.
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Wessels & Claffy             Informational                     [Page 15]
  843.  
  844. RFC 2187                          ICP                     September 1997
  845.  
  846.  
  847. 8.  Lessons Learned
  848.  
  849. 8.1.  Differences Between ICP and HTTP
  850.  
  851.    ICP is notably different from HTTP.  HTTP supports a rich and
  852.    sophisticated set of features.  In contrast, ICP was designed to be
  853.    simple, small, and efficient.  HTTP request and reply headers consist
  854.    of lines of ASCII text delimited by a CRLF pair, whereas ICP uses a
  855.    fixed size header and represents numbers in binary.  The only thing
  856.    ICP and HTTP have in common is the URL.
  857.  
  858.    Note that the ICP message does not even include the HTTP request
  859.    method.  The original implementation assumed that only GET requests
  860.    would be cachable and there would be no need to locate non-GET
  861.    requests in neighbor caches.  Thus, the current version of ICP does
  862.    not accommodate non-GET requests, although the next version of this
  863.    protocol will likely include a field for the request method.
  864.  
  865.    HTTP defines features that are important for caching but not
  866.    expressible with the current ICP protocol.  Among these are Pragma:
  867.    no-cache, If-Modified-Since, and all of the Cache-Control features of
  868.    HTTP/1.1.  An ICP_OP_HIT_OBJ message may deliver an object which may
  869.    not obey all of the request header constraints.  These differences
  870.    between ICP and HTTP are the reason we discourage the use of the
  871.    ICP_OP_HIT_OBJ feature.
  872.  
  873. 8.2.  Parents, Siblings, Hits and Misses
  874.  
  875.    Note that the ICP message does not have a field to indicate the
  876.    intent of the querying cache.  That is, nowhere in the ICP request or
  877.    reply does it say that the two caches have a sibling or parent
  878.    relationship.  A sibling cache can only respond with HIT or MISS, not
  879.    "you can retrieve this from me" or "you can not retrieve this from
  880.    me."  The querying cache must apply the HIT or MISS reply to its
  881.    local configuration to prevent it from resolving misses through a
  882.    sibling cache.  This constraint is awkward, because this aspect of
  883.    the relationship can be configured only in the cache originating the
  884.    requests, and indirectly via the access controls configured in the
  885.    queried cache as described earlier in section 4.2.
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Wessels & Claffy             Informational                     [Page 16]
  899.  
  900. RFC 2187                          ICP                     September 1997
  901.  
  902.  
  903. 8.3.  Different Roles of ICP
  904.  
  905.    There are two different understandings of what exactly the role of
  906.    ICP is in a cache mesh.  One understanding is that ICP's role is only
  907.    object location, specifically, to provide hints about whether or not
  908.    a named object exists in a neighbor cache.  An implied assumption is
  909.    that cache hits are highly desirable, and ICP is used to maximize the
  910.    chance of getting them.  If an ICP message is lost due to congestion,
  911.    then nothing significant is lost; the request will be satisfied
  912.    regardless.
  913.  
  914.    ICP is increasingly being tasked to fill a more complex role:
  915.    conveying cache usage policy.  For example, many organizations (e.g.
  916.    universities) will install a Web cache on the border of their
  917.    network.  Such organizations may be happy to establish sibling
  918.    relationships with other, nearby caches, subject to the following
  919.    terms:
  920.  
  921.    o    Any of the organization's customers or users may request any
  922.         object (cached or not).
  923.  
  924.    o    Anyone may request an object already in the cache.
  925.  
  926.    o    Anyone may request any object from the organization's servers
  927.         behind the cache.
  928.  
  929.    o    All other requests are denied; specifically, the organization
  930.         will not provide transit for requests in which neither the
  931.         client nor the server falls within its domain.
  932.  
  933.    To successfully convey policy the ICP exchange must very accurately
  934.    predict the result (hit, miss) of a subsequent HTTP request.  The
  935.    result may often depend on other request fields, such as Cache-
  936.    Control.  So it's not possible for ICP to accurately predict the
  937.    result without more, or perhaps all, of the HTTP request.
  938.  
  939. 8.4.  Protocol Design Flaws of ICPv2
  940.  
  941.    We recognize certain flaws with the original design of ICP, and make
  942.    note of them so that future versions can avoid the same mistakes.
  943.  
  944.    o    The NULL-terminated URL in the payload field requires stepping
  945.         through the message an octet at a time to find some of the
  946.         fields (i.e. the beginning of object data in an ICP_OP_HIT_OBJ
  947.         message).
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Wessels & Claffy             Informational                     [Page 17]
  955.  
  956. RFC 2187                          ICP                     September 1997
  957.  
  958.  
  959.    o    Two fields (Sender Host Address and Requester Host Address) are
  960.         IPv4 specific.  However, neither of these fields are used in
  961.         practice; they are normally zero-filled.  If IP addresses have a
  962.         role in the ICP message, there needs to be an address family
  963.         descriptor for each address, and clients need to be able to say
  964.         whether they want to hear IPv6 responses or not.
  965.  
  966.    o    Options are limited to 32 option flags and 32 bits of option
  967.         data.  This should be more like TCP, with an option descriptor
  968.         followed by option data.
  969.  
  970.    o    Although currently used as the cache key, the URL string no
  971.         longer serves this role adequately.  Some HTTP responses now
  972.         vary according to the requestor's User-Agent and other headers.
  973.         A cache key must incorporate all non-transport headers present
  974.         in the client's request.  All non-hop-by-hop request headers
  975.         should be sent in an ICP query.
  976.  
  977.    o    ICPv2 uses different opcode values for queries and responses.
  978.         ICP should use the same opcode for both sides of a two-sided
  979.         transaction, with a "query/response" indicator telling which
  980.         side is which.
  981.  
  982.    o    ICPv2 does not include any authentication fields.
  983.  
  984. 9.  Security Considerations
  985.  
  986.    Security is an issue with ICP over UDP because of its connectionless
  987.    nature.  Below we consider various vulnerabilities and methods of
  988.    attack, and their implications.
  989.  
  990.    Our first line of defense is to check the source IP address of the
  991.    ICP message, e.g. as given by recvfrom(2).  ICP query messages should
  992.    be processed if the access control rules allow the querying address
  993.    access to the cache.  However, ICP reply messages must only be
  994.    accepted from known neighbors; a cache must ignore replies from
  995.    unknown addresses.
  996.  
  997.    Because we trust the validity of an address in an IP packet, ICP is
  998.    susceptible to IP address spoofing.  In this document we address some
  999.    consequences of IP address spoofing.  Normally, spoofed addresses can
  1000.    only be detected by routers, not by hosts.  However, the IP
  1001.    Authentication Header[7,8] can be used underneath ICP to provide
  1002.    cryptographic authentication of the entire IP packet containing the
  1003.    ICP protocol, thus eliminating the risk of IP address spoofing.
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Wessels & Claffy             Informational                     [Page 18]
  1011.  
  1012. RFC 2187                          ICP                     September 1997
  1013.  
  1014.  
  1015. 9.1.  Inserting Bogus ICP Queries
  1016.  
  1017.    Processing an ICP_OP_QUERY message has no known security
  1018.    implications, so long as the requesting address is granted access to
  1019.    the cache.
  1020.  
  1021. 9.2.  Inserting Bogus ICP Replies
  1022.  
  1023.    Here we are concerned with a third party generating ICP reply
  1024.    messages which are returned to the querying cache before the real
  1025.    reply arrives, or before any replies arrive.  The third party may
  1026.    insert bogus ICP replies which appear to come from legitimate
  1027.    neighbors.  There are three vulnerabilities:
  1028.  
  1029.    o    Preventing a certain neighbor from being used
  1030.  
  1031.         If a third-party could send an ICP_OP_MISS_NOFETCH reply back
  1032.         before the real reply arrived, the (falsified) neighbor would
  1033.         not be used.
  1034.  
  1035.         A third-party could blast a cache with ICP_OP_DENIED messages
  1036.         until the threshold described in section 5.3.1 is reached,
  1037.         thereby causing the neighbor relationship to be temporarily
  1038.         terminated.
  1039.  
  1040.    o    Forcing a certain neighbor to be used
  1041.  
  1042.         If a third-party could send an ICP_OP_HIT reply back before the
  1043.         real reply arrived, the (falsified) neighbor would be used.
  1044.         This may violate the terms of a sibling relationship; ICP_OP_HIT
  1045.         replies mean a subsequent HTTP request will also be a hit.
  1046.  
  1047.         Similarly, if bogus ICP_OP_SECHO messages can be generated, the
  1048.         cache would retrieve requests directly from the origin server.
  1049.  
  1050. o    Cache poisoning
  1051.  
  1052.         The ICP_OP_HIT_OBJ message is especially sensitive to security
  1053.         issues since it contains actual object data.  In combination
  1054.         with IP address spoofing, this option opens up the likely
  1055.         possibility of having the cache polluted with invalid objects.
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Wessels & Claffy             Informational                     [Page 19]
  1067.  
  1068. RFC 2187                          ICP                     September 1997
  1069.  
  1070.  
  1071. 9.3.  Eavesdropping
  1072.  
  1073.    Multicasting ICP queries provides a very simple method for others to
  1074.    "snoop" on ICP messages.  If enabling multicast, cache administrators
  1075.    should configure the application to use the minimum required
  1076.    multicast TTL, using a tool such as mtrace[6].  Note that the IP
  1077.    Encapsulating Security Payload [7,9] mechanism can be used to provide
  1078.    protection against eavesdropping of ICP messages.
  1079.  
  1080.    Eavesdropping on ICP traffic can provide third parties with a list of
  1081.    URLs being browsed by cache users.  Because the Requestor Host
  1082.    Address is zero-filled by Squid and Harvest, the URLs cannot be
  1083.    mapped back to individual host systems.
  1084.  
  1085.    By default, Squid and Harvest do not send ICP messages for URLs
  1086.    containing `cgi-bin' or `?'.  These URLs sometimes contain sensitive
  1087.    information as argument parameters.  Cache administrators need to be
  1088.    aware that altering the configuration to make ICP queries for such
  1089.    URLs may expose sensitive information to outsiders, especially when
  1090.    multicast is used.
  1091.  
  1092. 9.4.  Blocking ICP Messages
  1093.  
  1094.    Intentionally blocked (or discarded) ICP queries or replies will
  1095.    appear to reflect link failure or congestion, and will prevent the
  1096.    use of a neighbor as well as lead to timeouts (see section 5.1.4).
  1097.    If all messages are blocked, the cache will assume the neighbor is
  1098.    down and remove it from the selection algorithm.  However, if, for
  1099.    example, every other query is blocked, the neighbor will remain
  1100.    "alive," but every other request will suffer the ICP timeout.
  1101.  
  1102. 9.5.  Delaying ICP Messages
  1103.  
  1104.    The neighbor selection algorithm normally waits for all ICP MISS
  1105.    replies to arrive.  Delaying queries or replies, so that they arrive
  1106.    later than they normally would, will cause additional delay for the
  1107.    subsequent HTTP request.  Of course, if messages are delayed so that
  1108.    they arrive after the timeout, the behavior is the same as "blocking"
  1109.    above.
  1110.  
  1111. 9.6.  Denial of Service
  1112.  
  1113.    A denial-of-service attack, where the ICP port is flooded with a
  1114.    continuous stream of bogus messages has three vulnerabilities:
  1115.  
  1116.    o    The application may log every bogus ICP message and eventually
  1117.         fill up a disk partition.
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Wessels & Claffy             Informational                     [Page 20]
  1123.  
  1124. RFC 2187                          ICP                     September 1997
  1125.  
  1126.  
  1127.    o    The socket receive queue may fill up, causing legitimate
  1128.         messages to be dropped.
  1129.  
  1130.    o    The host may waste some CPU cycles receiving the bogus messages.
  1131.  
  1132. 9.7.  Altering ICP Fields
  1133.  
  1134.    Here we assume a third party is able to change one or more of the ICP
  1135.    reply message fields.
  1136.  
  1137.    Opcode
  1138.  
  1139.       Changing the opcode field is much like inserting bogus messages
  1140.       described above.  Changing a hit to a miss would prevent the peer
  1141.       from being used.  Changing a miss to a hit would force the peer to
  1142.       be used.
  1143.  
  1144.    Version
  1145.  
  1146.       Altering the ICP version field may have unpredictable consequences
  1147.       if the new version number is recognized and supported.  The
  1148.       receiving application should ignore messages with invalid version
  1149.       numbers.  At the time of this writing, both version numbers 2 and
  1150.       3 are in use.  These two versions use some fields (e.g. Options)
  1151.       in a slightly different manner.
  1152.  
  1153.    Message Length
  1154.  
  1155.       An incorrect message length should be detected by the receiving
  1156.       application as an invalid ICP message.
  1157.  
  1158.    Request Number
  1159.  
  1160.       The request number is often used as a part of the cache key.
  1161.       Harvest does not use the request number.  Squid uses the request
  1162.       number in conjunction with the URL to create a cache key.
  1163.       Altering the request number will cause a lookup of the cache key
  1164.       to fail.  This is similar to blocking the ICP reply altogether.
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Wessels & Claffy             Informational                     [Page 21]
  1179.  
  1180. RFC 2187                          ICP                     September 1997
  1181.  
  1182.  
  1183.       There is no requirement that a cache use both the URL and the
  1184.       request number to locate HTTP requests with outstanding ICP
  1185.       queries (however both Squid and Harvest do).  The request number
  1186.       must always be the same in the query and the reply.  However, if
  1187.       the querying cache uses only the request number to locate pending
  1188.       requests, there is some possibility that a replying cache might
  1189.       increment the request number in the reply to give the false
  1190.       impression that the two caches are closer than they really are.
  1191.       In other words, assuming that there are a few ICP requests "in
  1192.       flight" at any given time, incrementing the reply request number
  1193.       trick the querying cache into seeing a smaller round-trip time
  1194.       than really exists.
  1195.  
  1196.    Options
  1197.  
  1198.       There is little risk in having the Options bitfields altered.  Any
  1199.       option bit must only be set in a reply if it was also set in a
  1200.       query.  Changing a bit from clear to set is detectable by the
  1201.       querying cache, and such a message must be ignored.  Changing a
  1202.       bit from set to clear is allowed and has no negative side effects.
  1203.  
  1204.    Option Data
  1205.  
  1206.       ICP_FLAG_SRC_RTT is the only option which uses the Option Data
  1207.       field.  Altering the RTT values returned here can affect the
  1208.       neighbor selection algorithm, either forcing or preventing the use
  1209.       of a neighbor.
  1210.  
  1211.    URL
  1212.  
  1213.       The URL and Request Number are used to generate the cache key.
  1214.       Altering the URL will cause a lookup of the cache key to fail, and
  1215.       the ICP reply to be entirely ignored.  This is similar to blocking
  1216.       the ICP reply altogether.
  1217.  
  1218. 9.8.  Summary
  1219.  
  1220.    o    ICP_OP_HIT_OBJ is particularly vulnerable to security problems
  1221.         because it includes object data.  For this, and other reasons,
  1222.         its use is discouraged.
  1223.  
  1224.    o    Falsifying, altering, inserting, or blocking ICP messages can
  1225.         cause an HTTP request to fail only in two situations:
  1226.  
  1227.         -    If the cache is behind a firewall and cannot directly
  1228.              connect to the origin server.
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Wessels & Claffy             Informational                     [Page 22]
  1235.  
  1236. RFC 2187                          ICP                     September 1997
  1237.  
  1238.  
  1239.         -    If a false ICP_OP_HIT reply causes the HTTP request to be
  1240.              forwarded to a sibling, where the request is a cache miss
  1241.              and the sibling refuses to continue forwarding the request
  1242.              on behalf of the originating cache.
  1243.  
  1244.    o    Falsifying, altering, inserting, or blocking ICP messages can
  1245.         easily cause HTTP requests to be forwarded (or not forwarded) to
  1246.         certain neighbors.  If the neighbor cache has also been
  1247.         compromised, then it could serve bogus content and pollute a
  1248.         cache hierarchy.
  1249.  
  1250.    o    Blocking or delaying ICP messages can cause HTTP request to be
  1251.         further delayed, but still satisfied.
  1252.  
  1253.  
  1254. 10.  References
  1255.  
  1256.    [1] Fielding, R., et. al, "Hypertext Transfer Protocol -- HTTP/1.1",
  1257.    RFC 2068, UC Irvine, January 1997.
  1258.  
  1259.    [2] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource
  1260.    Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota,
  1261.    December 1994.
  1262.  
  1263.    [3] Bowman M., Danzig P., Hardy D., Manber U., Schwartz M., and
  1264.    Wessels D., "The Harvest Information Discovery and Access System",
  1265.    Internet Research Task Force - Resource Discovery,
  1266.    http://harvest.transarc.com/.
  1267.  
  1268.    [4] Wessels D., Claffy K., "ICP and the Squid Web Cache", National
  1269.    Laboratory for Applied Network Research,
  1270.    http://www.nlanr.net/~wessels/Papers/icp-squid.ps.gz.
  1271.  
  1272.    [5] Wessels D., "The Squid Internet Object Cache", National
  1273.    Laboratory for Applied Network Research,
  1274.    http://squid.nlanr.net/Squid/
  1275.  
  1276.    [6] mtrace, Xerox PARC, ftp://ftp.parc.xerox.com/pub/net-
  1277.    research/ipmulti/.
  1278.  
  1279.    [7] Atkinson, R., "Security Architecture for the Internet Protocol",
  1280.    RFC 1825, NRL, August 1995.
  1281.  
  1282.    [8] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, August
  1283.    1995.
  1284.  
  1285.    [9] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC
  1286.    1827, NRL, August 1995.
  1287.  
  1288.  
  1289.  
  1290. Wessels & Claffy             Informational                     [Page 23]
  1291.  
  1292. RFC 2187                          ICP                     September 1997
  1293.  
  1294.  
  1295. 11.  Acknowledgments
  1296.  
  1297.    The authors wish to thank Paul A Vixie <paul@vix.com> for providing
  1298.    excellent feedback on this document, Martin Hamilton
  1299.    <martin@mrrl.lut.ac.uk> for pushing the development of multicast ICP,
  1300.    Eric Rescorla <ekr@terisa.com> and Randall Atkinson <rja@home.net>
  1301.    for assisting with security issues, and especially Allyn Romanow for
  1302.    keeping us on the right track.
  1303.  
  1304.  
  1305. 12.  Authors' Addresses
  1306.  
  1307.    Duane Wessels
  1308.    National Laboratory for Applied Network Research
  1309.    10100 Hopkins Drive
  1310.    La Jolla, CA 92093
  1311.  
  1312.    EMail: wessels@nlanr.net
  1313.  
  1314.  
  1315.    K. Claffy
  1316.    National Laboratory for Applied Network Research
  1317.    10100 Hopkins Drive
  1318.    La Jolla, CA 92093
  1319.  
  1320.    EMail: kc@nlanr.net
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.  
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Wessels & Claffy             Informational                     [Page 24]
  1347.  
  1348.