Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
Network Working Group D. Wessels Request for Comments: 2187 K. Claffy Category: Informational National Laboratory for Applied Network Research/UCSD September 1997 Application of Internet Cache Protocol (ICP), version 2 Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. このメモはインターネットコミュニティーに情報を提供するものです。この メモはいかなる種類のインターネットの標準も記載していません。このメモの 配布は無制限に行なって構いません。 Abstract This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFC2186) to Web caching. ICPv2 is a lightweight message format used for communication among Web caches. Several independent caching implementations now use ICP[3,5], making it important to codify the existing practical uses of ICP for those trying to implement, deploy, and extend its use. この文章は、WebキャッシュのためのICPv2 (Internet Cache Protocol version 2, RFC2186)の応用について説明しています。ICPv2はWeb キャッシュの間の通信を行なうための軽量なメッセージ形式です。 いくつかの独立したキャッシュの実装がICPを用いていて[3,5]、今ある 現実的なICPの利用法をまとめることは、それらを目的に合わせて実装し、 展開し、拡張しようとするために重要になっています。 ICP queries and replies refer to the existence of URLs (or objects) in neighbor caches. Caches exchange ICP messages and use the gathered information to select the most appropriate location from which to retrieve an object. A companion document (RFC2186) describes the format and syntax of the protocol itself. In this document we focus on issues of ICP deployment, efficiency, security, and interaction with other aspects of Web traffic behavior. ICP問合せと応答は、neighborキャッシュ中のURL（あるいはオブジェクト）の 存在を参照します。キャッシュはICPのメッセージを交換し、取得しようと しているオブジェクトを得るのに、最も適切な場所を選択するために集めた 情報を利用します。対となる文章(RFC2186)では、このプロトコル自体の フォーマットとシンタックスについて述べています。この文章では、ICPの 展開、効率、安全性、「Webのトラフィックの様子の他の局面との相互作用」 という目的に着目しています。 Table of Contents 1. Introduction................................................. 2 2. Web Cache Hierarchies........................................ 3 3. What is the Added Value of ICP?.............................. 5 4. Example Configuration of ICP Hierarchy....................... 5 4.1. Configuring the `proxy.customer.org' cache................. 6 4.2. Configuring the `cache.isp.com' cache...................... 6 5. Applying the Protocol........................................ 7 5.1. Sending ICP Queries........................................ 8 5.2. Receiving ICP Queries and Sending Replies.................. 10 5.3. Receiving ICP Replies...................................... 11 5.4. ICP Options................................................ 13 6. Firewalls.................................................... 14 7. Multicast.................................................... 14 8. Lessons Learned.............................................. 16 8.1. Differences Between ICP and HTTP........................... 16 8.2. Parents, Siblings, Hits and Misses......................... 16 8.3. Different Roles of ICP..................................... 17 8.4. Protocol Design Flaws of ICPv2............................. 17 9. Security Considerations...................................... 18 9.1. Inserting Bogus ICP Queries................................ 19 9.2. Inserting Bogus ICP Replies................................ 19 9.3. Eavesdropping.............................................. 20 9.4. Blocking ICP Messages...................................... 20 9.5. Delaying ICP Messages...................................... 20 9.6. Denial of Service.......................................... 20 9.7. Altering ICP Fields........................................ 21 9.8. Summary.................................................... 22 10. References................................................... 23 11. Acknowledgments.............................................. 24 12. Authors' Addresses........................................... 24 1. Introduction ICP is a lightweight message format used for communicating among Web caches. ICP is used to exchange hints about the existence of URLs in neighbor caches. Caches exchange ICP queries and replies to gather information for use in selecting the most appropriate location from which to retrieve an object. ICPは、Webキャッシュ間の対話に使用される軽量なメッセージフォーマット です。ICPは近所のキャシュに存在するURLに関するヒントを交換するために 使用されます。キャッシュは取得しようとして探しているオブジェクトを得る のに、最も適切な場所を選択するために用いる情報を集めるために、 ICP問合せと応答を交換します。 This document describes the implementation of ICP in software. For a description of the protocol and message format, please refer to the companion document (RFC2186). We avoid making judgments about whether or how ICP should be used in particular Web caching configurations. ICP may be a "net win" in some situations, and a "net loss" in others. We recognize that certain practices described in this document are suboptimal. Some of these exist for historical reasons. Some aspects have been improved in later versions. Since this document only serves to describe current practices, we focus on documenting rather than evaluating. However, we do address known security problems and other shortcomings. この文章は、ソフトウエア中でのICPの実装について述べています。この プロトコルの説明とメッセージ形式については、対となる文章(RFC2186)を 参照して下さい。我々は、個々のWebキャッシュの設定において、ICPが 利用されるべきかとか、どのように利用されるべきかといったことに ついては、判断することを避けています。ICPはあるシミュレーションでは、 "net win"になっても、別の場合には"net loss"となるかもしれません。 我々は、この文章に書かれているいくつかの実情が、最適ではないという ことは認識しています。それらのうちのいくつかは、歴史的な理由によって 存在しています。いくつかの状況は、後の版で改良されてきました。 この文章は現時点での実情を述べているに過ぎないので、評価よりも むしろ記録することに焦点を絞りました。しかし、我々は既知の安全性に 関する問題や、その他の欠点についても述べています。 The remainder of this document is written as follows. We first describe Web cache hierarchies, explain motivation for using ICP, and demonstrate how to configure its use in cache hierarchies. We then provide a step-by-step description of an ICP query-response transaction. We then discuss ICP interaction with firewalls, and briefly touch on multicasting ICP. We end with lessons with have learned during the protocol development and deployement thus far, and the canonical security considerations. この文章は以下のような構成になっています。はじめにWebキャッシュ階層 について述べ、ICPを用いる動機を説明し、キャッシュ階層の中でどのような 構成になっているかを実際に説明します。そして、ICPの問合せ−応答処理の 段階毎の詳細を説明します。その後、ファイアーウォールとのICPの相互作用 について議論したり、マルチキャストICPについて触れたりします。最後に このプロトコルのここまでの開発や展開の間に学んだ教訓や、模範的な 安全性に対する考慮について述べます。 ICP was initially developed by Peter Danzig, et. al. at the University of Southern California as a central part of hierarchical caching in the Harvest research project[3]. ICPは最初に南カリフォルニア大のPeter Danzigらによって、Harvest research project[3]における階層キャッシュの中心的な部分として 開発されました。 2. Web Cache Hierarchies A single Web cache will reduce the amount of traffic generated by the clients behind it. Similarly, a group of Web caches can benefit by sharing another cache in much the same way. Researchers on the Harvest project envisioned that it would be important to connect Web caches hierarchically. In a cache hierarchy (or mesh) one cache establishes peering relationships with its neighbor caches. There are two types of relationship: parent and sibling. A parent cache is essentially one level up in a cache hierarchy. A sibling cache is on the same level. The terms "neighbor" and "peer" are used to refer to either parents or siblings which are a single "cache-hop" away. Figure 1 shows a simple hierarchy configuration. 一つのWebキャッシュは、その背後にあるクライアントが引き起こす トラフィックの総量を減らすでしょう。同様に、Webキャッシュのグループが 他のキャッシュを共有することにより、全く同じ様な効果があります。 Harvestプロジェクトの研究者達は、Webキャッシュ階層の接続が大切で あると考えました。キャッシュの階層（あるいは網目構造）においては、 あるキャッシュは neighbor(隣の)キャッシュとpeer(仲間)の関係になります。 その関係はparent(親)とsibling(同僚)の２種類があります。"neighbor"や "peer"という言葉は、"cache-hop"が一つだけ離れたparentsかsiblingsを さすのに使われます。図1は単純な階層構造を表しています。 T H E I N T E R N E T =========================== | || | || | || | || | +----------------------+ | | | | | PARENT | | | CACHE | | | | | +----------------------+ | || DIRECT || RETRIEVALS || | || | HITS | AND | MISSES | RESOLVED | || | || | || V \/ +------------------+ +------------------+ | | | | | LOCAL |/--------HITS-------| SIBLING | | CACHE |\------RESOLVED-----| CACHE | | | | | +------------------+ +------------------+ | | | | | | | | | | | | | | | V V V V V =================== CACHE CLIENTS FIGURE 1: A Simple Web cache hierarchy. The local cache can retrieve hits from sibling caches, hits and misses from parent caches, and some requests directly from origin servers. 図1：単純なWebキャッシュ階層。ローカルなキャッシュはhitしたものを siblingキャッシュから取り出すことが出来、hitしたものもmisseしたものも parentキャッシュから取り出すことが出来、ある要求はものとサーバから 直接取り出すことが出来る。 But what does it mean to be "on the same level" or "one level up?" The general flow of document requests is up the hierarchy. When a cache does not hold a requested object, it may ask via ICP whether any of its neighbor caches has the object. If any of the neighbors does have the requested object (i.e., a "neighbor hit"), then the cache will request it from them. If none of the neighbors has the object (a "neighbor miss"), then the cache must forward the request either to a parent, or directly to the origin server. The essential difference between a parent and sibling is that a "neighbor hit" may be fetched from either one, but a "neighbor miss" may NOT be fetched from a sibling. In other words, in a sibling relationship, a cache can only ask to retrieve objects that the sibling already has cached, whereas the same cache can ask a parent to retrieve any object regardless of whether or not it is cached. A parent cache's role is to provide "transit" for the request if necessary, and accordingly parent caches are ideally located within or on the way to a transit Internet service provider (ISP). しかし、“同じレベル”とか“一つ上のレベル”とはどういうことでしょう？ 文章の要求は一般的にキャッシュ階層を遡って流れます。要求された オブジェクトをあるキャッシュが持っていなかった場合は、neighborキャッシュが そのオブジェクトを持っているかどうかをICPによって問い合わせるでしょう。 要求されたオブジェクトをneighborキャッシュのどれかが持っていたら（つまり、 "neighbor hit"なら）、もとのキャッシュは応答したキャッシュにその オブジェクトを要求します。どのキャッシュも要求されたオブジェクトを 持っていなければ（つまり、"neighbor miss"なら）、元のキャッシュはその 要求をparentキャッシュか、または元のデータをもつサーバに要求します。 parentとsiblingの本質的な違いは、"neighbor hit"はどちらからも取得され ますが、"neighbor miss"はsiblingからは取得され『ません』。言い替えると、 siblingの関係にある場合、あるキャッシュはsiblingが既に蓄えている オブジェクトを引き出すことのみ依頼できます。それに対し、同じキャッシュは parentに対してはそのparentキャッシュが、オブジェクトを持っているかに 関わらず、そのオブジェクトを引き出すよう依頼できます。parentキャッシュの 役割は、もし必要ならその要求について"transit"(伝送路)を提供することです。 そのため、parentキャッシュはインターネットサービスプロバイダー(ISP)の 伝送路の内部か途中にあることが望ましい。 Squid and Harvest allow for complex hierarchical configurations. For example, one could specify that a given neighbor be used for only a certain class of requests, such as URLs from a specific DNS domain. Additionally, it is possible to treat a neighbor as a sibling for some requests and as a parent for others. SquidやHarvestは、もっと複雑な階層構造を作ることが出来ます。例えば、 特定のDNSドメインからのURLといったようなあるクラスの要求のみに利用される neighborを設定することが出来ます。さらに、ある要求についてはsibling ですが、別の場合にはparentとしてneighborを取り扱うことも可能です。 The cache hierarchy model described here includes a number of features to prevent top-level caches from becoming choke points. One is the ability to restrict parents as just described previously (by domains). Another optimization is that the cache only forwards cachable requests to its neighbors. A large class of Web requests are inherently uncachable, including: requests requiring certain types of authentication, session-encrypted data, highly personalized responses, and certain types of database queries. Lower level caches should handle these requests directly rather than burdening parent caches. ここで述べたキャッシュ階層モデルは、最上位のキャッシュが隘路（チョーク ポイント）にならないようにするいくつかの特徴を含んでいます。一つは ちょうど前で述べたような（ドメインによる）parentの制限が出来ることです。 キャッシュは蓄積が可能な要求だけをそのneighborに転送するということが その他の最適化になります。Web要求の大部分は、認証やセッション毎に 暗号化されたデータ、高度に個人化された応答、ある種のデータベースへの 問合せなどを含んでいて遺伝的に蓄積が出来ません。より下層のキャッシュは その様な要求をparentキャッシュに負担させるより、むしろ直接的に取り扱う べきです。 3. What is the Added Value of ICP? Although it is possible to maintain cache hierarchies without using ICP, the lack of ICP or something similar prohibits the existence of sibling meta-communicative relationships, i.e., mechanisms to query nearby caches about a given document. ICPを用いなくてもキャッシュの階層構造を作ることは可能ではあるけれど、 ICPや他の似たような仕組みが無いと、sibling meta-communicativeな関係、 つまりある文章について近くのキャッシュに問い合わせるような仕組みの 存在の妨げとなります。 One concern over the use of ICP is the additional delay that an ICP query/reply exchange contributes to an HTTP transaction. However, if the ICP query can locate the object in a nearby neighbor cache, then the ICP delay may be more than offset by the faster delivery of the data from the neighbor. In order to minimize ICP delays, the caches (as well as the protocol itself) are designed to return ICP requests quickly. Indeed, the application does minimal processing of the ICP request, most ICP-related delay is due to transmission on the network. ICPの問合せや応答の交換がHTTPの処理に加える遅延が、ICPの使用に関して 気になります。しかしながら、ICP問合せで近くのneighborキャッシュの中に オブジェクトを見つけることが出来たなら、ICPによるの遅延はそのneighbor からのデータのより高速な伝達によって埋め合わされるでしょう。ICPによる 遅延を最小にするためには、キャッシュは（プロトコル自体も同じように） ICP要求を素早く返すように設計されなければなりません。アプリケーションは ICPの処理をなるべく小さくしますが、ICPに関係する遅延の大部分は ネットワークを通る間に起こるものです。 ICP also serves to provide an indication of neighbor reachability. If ICP replies from a neighbor fail to arrive, then either the network path is congested (or down), or the cache application is not running on the ICP-queried neighbor machine. In either case, the cache should not use this neighbor at this time. Additionally, because an idle cache can turn around the replies faster than a busy one, all other things being equal, ICP provides some form of load balancing. ICPはneighborへの到達性の指標を出すのに役に立ちます。ある隣のキャッシュ からのICP応答が到着しないのなら、ネットワークの経路が混雑している （あるいは切断されている）か、ICP問合せをおこなった隣の機械でキャッシュの アプリケーションが実行されていないということになります。どちらの場合も、 今回はそのキャッシュを使用すべきではありません。さらに、その他の条件が 同じなら、暇なキャッシュは忙しいキャッシュより速く応答を返すことが 出来るので、ICPは負荷のバランスを一定にすることが出来ます。 4. Example Configuration of ICP Hierarchy Configuring caches within a hierarchy requires establishing peering relationships, which currently involves manual configuration at both peering endpoints. One cache must indicate that the other is a parent or sibling. The other cache will most likely have to add the first cache to its access control lists. 階層中のキャッシュの設定は、仲間(peer)関係を作ることを要求しています。 そして、それは今の所peerの両端で手動で設定することが必要になっています。 あるキャッシュは、別のキャッシュをparentかsiblingと指定しなければ なりません。多くの場合、別のキャッシュの方でもコントロールリストに 元のキャッシュを付け加えなければなりません。 Below we show some sample configuration lines for a hypothetical situation. We have two caches, one operated by an ISP, and another operated by a customer. First we describe how the customer would configure his cache to peer with the ISP. Second, we describe how the ISP would allow the customer access to its cache. 仮定的な状況でのいくつかの設定の例を以下に示します。二つのキャッシュが あるとします。一つはISPが、もう一つは顧客が運用しています。まずはじめに 顧客が彼のキャッシュをISPのキャッシュと仲間の関係に設定する方法を 説明します。次にISPのキャッシュへ顧客がアクセスできるようにするには、 ISPがどのようにするかを説明します。 4.1. Configuring the `proxy.customer.org' cache In Squid, to configure parents and siblings in a hierarchy, a `cache_host' directive is entered into the configuration file. The format is: Squidでは階層の中でparentとsiblingを設定するためには、設定ファイルの中で `cache_host'に書きます。そのフォーマットは次の通りです。 cache_host hostname type http-port icp-port [options] Where type is either `parent', `sibling', or `multicast'. For our example, it would be: typeとしては`parent', `sibling', `multicast'のいづれかで、この例では 次のようになります。 cache_host cache.isp.com parent 8080 3130 This configuration will cause the customer cache to resolve most cache misses through the parent (`cgi-bin' and non-GET requests would be resolved directly). Utilizing the parent may be undesirable for certain servers, such as servers also in the customer.org domain. To always handle such local domains directly, the customer would add this to his configuration file: この設定では、顧客のキャッシュはmissしたもののほとんどをparentを通して 取得しようとします。（`cgi-bin'やnon-GET要求は直接処理されます。） 同じcustomer.orgドメイン内のサーバのように、あるサーバに関してparentの 使用が望ましくないことがあるかも知れない。そのようなローカルのドメインに ついては直接処理するように、顧客は設定ファイルに次の項目を加えるでしょう。 local_domain customer.org It may also be the case that the customer wants to use the ISP cache only for a specific subset of DNS domains. The need to limit requests this way is actually more common for higher levels of cache hierarchies, but it is illustrated here nonetheless. To limit the ISP cache to a subset of DNS domains, the customer would use: 顧客はDNSドメインの特定のサブネットについてのみISPのキャッシュを 使いたいと思うこともあるでしょう。このような要求の制限の必要性は、 キャッシュ階層のより上のレベルで実際にはさらによくあることになるでしょう。 それにも関わらずここでは説明していません。DNSドメインのサブネットで ISPのキャッシュを制限するには、顧客は以下のようにします。 cache_host_domain cache.isp.com com net org Then, any requests which are NOT in the .com, .net, or .org domains would be handled directly. つまり、.com, .net, .orgドメインに『ない』要求は直接処理されます。 4.2. Configuring the `cache.isp.com' cache To configure the query-receiving side of the cache peer relationship one uses access lists, similar to those used in routing peers. The access lists support a large degree of customization in the peering relationship. If there are no access lines present, the cache allows the request by default. キャッシュの仲間関係にあって問合せを受ける側の設定では、経路制御の 仲間関係で用いられるのに似ているアクセスリストを使います。このアクセス リストでは、仲間の関係を大規模にカスタマイズすることが出来ます。 もしアクセスに関する設定が明示されていなければ、そのキャッシュは デフォルトでアクセスを受け付けます。 Note that the cache.isp.com cache need not explicitly specify the customer cache as a peer, nor is the type of relationship encoded within the ICP query itself. The access control entries regulate the relationships between this cache and its neighbors. For our example, the ISP would use: cache.isp.comというキャッシュは、顧客のキャッシュを仲間としては 特に区別する必要がないか、そうでなければ、関係の種類はICP問合せの 中にエンコードされているとします。アクセス制御の項目は、このキャッシュと neighborキャッシュとの関係を調整します。我々の例では、このISPでは 次のようにするでしょう。 acl src Customer proxy.customer.org http_access allow Customer icp_access allow Customer This defines an access control entry named `Customer' which specifies a source IP address of the customer cache machine. The customer cache would then be allowed to make any request to both the HTTP and ICP ports (including cache misses). This configuration implies that the ISP cache is a parent of the customer. これは顧客のキャッシュのマシンのソースIPアドレスを、`Customer'と名付けた アクセス制御項目に設定することを定めています。そして、顧客のキャッシュは HTTPとICPポートのどちらとも、キャッシュのmissも含めていかなる要求を することも許可されています。この設定はISPのキャッシュが顧客のparent であることを意味しています。 If the ISP wanted to enforce a sibling relationship, it would need to deny access to cache misses. This would be done as follows: もし、ISPがsiblingな関係を強制したいのなら、キャッシュのmissのアクセスを 拒否する必要があります。それは以下のようにします。 miss_access deny Customer Of course the ISP should also communicate this to the customer, so that the customer will change his configuration from parent to sibling. Otherwise, if the customer requests an object not in the ISP cache, an error message is generated. もちろん、顧客が彼の設定をparentからsiblingに変更するように、ISPは このことを顧客に通知するべきです。そうしなければ、顧客の要求がISPの キャッシュになければ、エラーになってしまいます。 5. Applying the Protocol The following sections describe the ICP implementation in the Harvest[3] (research version) and Squid Web cache[5] packages. In terms of version numbers, this means version 1.4pl2 for Harvest and version 1.1.10 for Squid. 以下の章では、Harvest[3](研究版)とSquid Web cache[5]でのICPの実装に 関して述べています。これをバージョンでいうと、Harvestはver. 1.4pl2で、 Squidはver. 1.1.10です。 The basic sequence of events in an ICP transaction is as follows: ICP処理のイベントの基本的な流れは次のようになります。 1. Local cache receives an HTTP[1] request from a cache client. 2. The local cache sends ICP queries (section 5.1). 3. The peer cache(s) receive the queries and send ICP replies (section 5.2). 4. The local cache receives the ICP replies and decides where to forward the request (section 5.3). 1. ローカルなキャッシュが、クライアントからHTTP[1]の要求を受け取る。 2. そのローカルなキャッシュが、ICP問合せ(5.1節)を送る。 3. 仲間のキャッシュがその問合せを受け取り、ICP応答(5.2節)を返す。 4. ローカルなキャッシュがその応答を受け取り、どこにもとの要求を 送るかを決定する。 5.1. Sending ICP Queries 5.1.1. Determine whether to use ICP at all Not every HTTP request requires an ICP query to be sent. Obviously, cache hits will not need ICP because the request is satisfied immediately. For origin servers very close to the cache, we do not want to use any neighbor caches. In Squid and Harvest, the administrator specifies what constitutes a `local' server with the `local_domain' and `local_ip' configuration options. The cache always contacts a local server directly, never querying a peer cache. 全部のHTTP要求をICP問合せとして送ることはありません。言うまでもない ことですが、キャッシュにHITしたものは、要求がすぐに満たされるので ICP問合せをする必要はありません。元のサーバがそのキャッシュに非常に 近ければ、neighborキャッシュは使いたくはないでしょう。SquidやHarvest では、管理者が`local_domain'や`local_ip'の設定オプションで、`local'な サーバを設定できます。キャッシュはローカルなサーバには常に直接接続し、 仲間のキャッシュに問い合わせることはありません。 There are other classes of requests that the cache (or the administrator) may prefer to forward directly to the origin server. In Squid and Harvest, one such class includes all non-GET request methods. A Squid cache can also be configured to not use peers for URLs matching the `hierarchy_stoplist'. それ以外にもキャッシュや管理者が直接元のサーバに送りたいような要求の 種類は あります。SquidやHarvestでは、全てのnon-GETな要求手段（例えば、 POSTとかHEADね）がそのような種類に含まれます。Squidでは `hierarchy_stoplist'に一致するようなURLについては仲間のキャッシュを 使わないよう設定できます。 In order for an HTTP request to yield an ICP transaction, it must: o not be a cache hit o not be to a local server o be a GET request, and o not match the `hierarchy_stoplist' configuration. ICP処理を生じるHTTP要求になるためには、 o キャッシュにHITせず、 o ローカルなサーバではなく、 o GET要求であって、 o `hierarchy_stoplist'の設定に一致しない 必要があります。 We call this a "hierarchical" request. A "non-hierarchical" request is one that doesn't generate any ICP traffic. To avoid processing requests that are likely to lower cache efficiency, one can configure the cache to not consult the hierarchy for URLs that contain certain strings (e.g. `cgi_bin'). 我々はこれを"hierarchical"（階層的な）要求と呼びます。"non-hierarchical" （階層的でない）要求はICPトラフィックを生じません。キャッシュする 意味が無さそうな要求を処理することを防ぐために、例えば`cgi_bin'という 文字を含んだURLは階層的に処理しないようキャッシュを設定できます。 5.1.2. Determine which peers to query By default, a cache sends an ICP_OP_QUERY message to each peer, unless any one of the following are true: デフォルトでは、以下に示す項目のうちどれか一つでも当てはまることが なければ、キャッシュはそれぞれの仲間にICP_OP_QUERYメッセージを送ります。 o Restrictions prevent querying a peer for this request, based on the configuration directive `cache_host_domain', which specifies a set of DNS domains (from the URLs) for which the peer should or should not be queried. In Squid, a more flexible directive ('cache_host_acl') supports restrictions on other parts of the request (method, port number, source, etc.). o URLの中のDNSドメインによって、仲間のキャッシュに問合せをするか、 しないかを指定する`cache_host_domain'の設定項目に基づいて、その 要求を仲間のキャッシュに問い合わせることを制限が妨げている。 Squidではより自由度の高い'cache_host_acl'指定で、メソッドや ポート番号やソースなどその他の部分で要求の制限を行なうことが 出来ます。 o The peer is a sibling, and the HTTP request includes a "Pragma: no-cache" header. This is because the sibling would be asked to transit the request, which is not allowed. o 仲間のキャッシュがsiblingであって、HTTP要求に"Pragma: no-cache" ヘッダが含まれている。これはsiblingにその要求を中継するよう 要求するだけであるため、許されていません。 o The peer is configured to never be sent ICP queries (i.e. with the `no-query' option). o 仲間のキャッシュが`no-query'オプションが付いているなどで、 ICP要求が送られないような設定がされている。 If the determination yields only one queryable ICP peer, and the Squid configuration directive `single_parent_bypass' is set, then one can bypass waiting for the single ICP response and just send the HTTP request directly to the peer cache. こうした決定法によって、問合せをするICPの仲間が一つになってしまい、 Squidの設定で`single_parent_bypass'が指定されていたら、単一のICP応答を 待つことをやめて、その仲間のキャッシュに直接要求を送ることが出来ます。 The Squid configuration option `source_ping' configures a Squid cache to send a ping to the original source simultaneous with its ICP queries, in case the origin is closer than any of the caches. Squidの設定で`source_ping'を設定すると、そのSquidキャッシュは元の ソースの方が全ての仲間のキャッシュよりも近い場合に備えて、ICP問合せと 同時に元のソースにpingを送ります。 5.1.3. Calculate the expected number of ICP replies Harvest and Squid want to maximize the chance to get a HIT reply from one of the peers. Therefore, the cache waits for all ICP replies to be received. Normally, we expect to receive an ICP reply for each query sent, except: HarvestやSquidは仲間のキャッシュのうちの一つからHITの応答を受け取る機会を 最大にしたいのです。ですから、そのキャッシュは受け取るはずのICP応答を 全て待ちます。通常、次のような場合を除いて問い合わせたのと同じ数だけの 応答が得られると期待できます。 o When the peer is believed to be down. If the peer is down Squid and Harvest continue to send it ICP queries, but do not expect the peer to reply. When an ICP reply is again received from the peer, its status will be changed to up. o 相手のキャッシュが動いていないとわかっている場合。 相手のキャッシュが動いていない場合でも、Squid や Harvest は ICP 問合せを送り続けますが、その相手からの応答があることは 期待していません。その相手からの ICP 応答を再び受け取った時に、 その相手が動いているという状態に変更します。 The determination of up/down status has varied a little bit as the Harvest and Squid software evolved. Both Harvest and Squid mark a peer down when it fails to reply to 20 consecutive ICP queries. Squid also marks a peer down when a TCP connection fails, and up again when a diagnostic TCP connection succeeds. 動いているか、動いていないかという状態の決定方法は、Harvest や Squidの進化につれて、少しばかり変化しています。Harvest と Squid の どちらとも、ICP 問合せに 20 回連続して応答が無ければ、相手が 動いていないと判断します。Squid は TCP 接続に失敗した場合でも 相手が動いていないと判断し、また検査の TCP 接続に成功した場合でも 動いているとみなします。 o When sending to a multicast address. In this case we'll probably expect to receive more than one reply, and have no way to definitively determine how many to expect. We discuss multicast issues in section 7 below. o マルチキャストアドレスに送った場合。 この場合はおそらく一つ以上の応答があることを期待していて、最終的に いくつの応答が期待できるかを決定する方法はありません。 マルチキャストについては第 7 章で議論します。 5.1.4. Install timeout event Because ICP uses UDP as underlying transport, ICP queries and replies may sometimes be dropped by the network. The cache installs a timeout event in case not all of the expected replies arrive. By default Squid and Harvest use a two-second timeout. If object retrieval has not commenced when the timeout occurs, a source is selected as described in section 5.3.9 below. ICP は下層の伝送に UDP を用いているため、ICP の問合せと応答は、たまに ネットワーク中で欠落することがあります。キャッシュは到着することに なっている応答が全部届いていなくてもタイムアウトするようになっています。 Squid や Harvest の初期設定では、2秒でタイムアウトします。もし タイムアウトした時にオブジェクトの獲得が始まっていなければ、以下の 第 5.3.9 章で説明しているようにソースが選択されます。 5.2. Receiving ICP Queries and Sending Replies When an ICP_OP_QUERY message is received, the cache examines it and decides which reply message is to be sent. It will send one of the following reply opcodes, tested for use in the order listed: 5.2.1. ICP_OP_ERR The URL is extracted from the payload and parsed. If parsing fails, an ICP_OP_ERR message is returned. 5.2.2. ICP_OP_DENIED The access controls are checked. If the peer is not allowed to make this request, ICP_OP_DENIED is returned. Squid counts the number of ICP_OP_DENIED messages sent to each peer. If more than 95% of more than 100 replies have been denied, then no reply is sent at all. This prevents misconfigured caches from endlessly sending unnecessary ICP messages back and forth. 5.2.3. ICP_OP_HIT If the cache reaches this point without already matching one of the previous opcodes, it means the request is allowed and we must determine if it will be HIT or MISS, so we check if the URL exists in the local cache. If so, and if the cached entry is fresh for at least the next 30 seconds, we can return an ICP_OP_HIT message. The stale/fresh determination uses the local refresh (or TTL) rules. Note that a race condition exists for ICP_OP_HIT replies to sibling peers. The ICP_OP_HIT means that a subsequent HTTP request for the named URL would result in a cache hit. We assume that the HTTP request will come very quickly after the ICP_OP_HIT. However, there is a slight chance that the object might be purged from this cache before the HTTP request is received. If this happens, and the replying peer has applied Squid's `miss_access' configuration then the user will receive a very confusing access denied message. 5.2.3.1. ICP_OP_HIT_OBJ Before returning the ICP_OP_HIT message, we see if we can send an ICP_OP_HIT_OBJ message instead. We can use ICP_OP_HIT_OBJ if: o The ICP_OP_QUERY message had the ICP_FLAG_HIT_OBJ flag set. Wessels & Claffy Informational [Page 10]  RFC 2187 ICP September 1997 o The entire object (plus URL) will fit in an ICP message. The maximum ICP message size is 16 Kbytes, but an application may choose to set a smaller maximum value for ICP_OP_HIT_OBJ replies. Normally ICP replies are sent immediately after the query is received, but the ICP_OP_HIT_OBJ message cannot be sent until the object data is available to copy into the reply message. For Squid and Harvest this means the object must be "swapped in" from disk if it is not already in memory. Therefore, on average, an ICP_OP_HIT_OBJ reply will have higher latency than ICP_OP_HIT. 5.2.4. ICP_OP_MISS_NOFETCH At this point we have a cache miss. ICP has two types of miss replies. If the cache does not want the peer to request the object from it, it sends an ICP_OP_MISS_NOFETCH message. 5.2.5. ICP_OP_MISS Finally, an ICP_OP_MISS reply is returned as the default. If the replying cache is a parent of the querying cache, the ICP_OP_MISS indicates an invitation to fetch the URL through the replying cache. 5.3. Receiving ICP Replies Some ICP replies will be ignored; specifically, when any of the following are true: o The reply message originated from an unknown peer. o The object named by the URL does not exist. o The object is already being fetched. 5.3.1. ICP_OP_DENIED If more than 95% of more than 100 replies from a peer cache have been ICP_OP_DENIED, then such a high denial rate most likely indicates a configuration error, either locally or at the peer. For this reason, no further queries will be sent to the peer for the duration of the cache process. 5.3.2. ICP_OP_HIT Object retrieval commences immediately from the replying peer. Wessels & Claffy Informational [Page 11]  RFC 2187 ICP September 1997 5.3.3. ICP_OP_HIT_OBJ The object data is extracted from the ICP message and the retrieval is complete. If there is some problem with the ICP_OP_HIT_OBJ message (e.g. missing data) the reply will be treated like a standard ICP_OP_HIT. 5.3.4. ICP_OP_SECHO Object retrieval commences immediately from the origin server because the ICP_OP_SECHO reply arrived prior to any ICP_OP_HIT's. If an ICP_OP_HIT had arrived prior, this ICP_OP_SECHO reply would be ignored because the retrieval has already started. 5.3.5. ICP_OP_DECHO An ICP_OP_DECHO reply is handled like an ICP_OP_MISS. Non-ICP peers must always be configured as parents; a non-ICP sibling makes no sense. One serious problem with the ICP_OP_DECHO feature is that since it bounces messages off the peer's UDP echo port, it does not indicate that the peer cache is actually running -- only that network connectivity exists between the pair. 5.3.6. ICP_OP_MISS If the peer is a sibling, the ICP_OP_MISS reply is ignored. Otherwise, the peer may be "remembered" for future use in case no HIT replies are received later (section 5.3.9). Harvest and Squid remember the first parent to return an ICP_OP_MISS message. With Squid, the parents may be weighted so that the "first parent to miss" may not actually be the first reply received. We call this the FIRST_PARENT_MISS. Remember that sibling misses are entirely ignored, we only care about misses from parents. The parent miss RTT's can be weighted because sometimes the closest parent is not the one people want to use. Also, recent versions of Squid may remember the parent with the lowest RTT to the origin server, using the ICP_FLAG_SRC_RTT option. We call this the CLOSEST_PARENT_MISS. 5.3.7. ICP_OP_MISS_NOFETCH This reply is essentially ignored. A cache must not forward a request to a peer that returns ICP_OP_MISS_NOFETCH. Wessels & Claffy Informational [Page 12]  RFC 2187 ICP September 1997 5.3.8. ICP_OP_ERR Silently ignored. 5.3.9. When all peers MISS. For ICP_OP_HIT and ICP_OP_SECHO the request is forwarded immediately. For ICP_OP_HIT_OBJ there is no need to forward the request. For all other reply opcodes, we wait until the expected number of replies have been received. When we have all of the expected replies, or when the query timeout occurs, it is time to forward the request. Since MISS replies were received from all peers, we must either select a parent cache or the origin server. o If the peers are using the ICP_FLAG_SRC_RTT feature, we forward the request to the peer with the lowest RTT to the origin server. If the local cache is also measuring RTT's to origin servers, and is closer than any of the parents, the request is forwarded directly to the origin server. o If there is a FIRST_PARENT_MISS parent available, the request will be forwarded there. o If the ICP query/reply exchange did not produce any appropriate parents, the request will be sent directly to the origin server (unless firewall restrictions prevent it). 5.4. ICP Options The following options were added to Squid to support some new features while maintaining backward compatibility with the Harvest implementation. 5.4.1. ICP_FLAG_HIT_OBJ This flag is off by default and will be set in an ICP_OP_QUERY message only if these three criteria are met: o It is enabled in the cache configuration file with `udp_hit_obj on'. o The peer must be using ICP version 2. o The HTTP request must not include the "Pragma: no-cache" header. Wessels & Claffy Informational [Page 13]  RFC 2187 ICP September 1997 5.4.2. ICP_FLAG_SRC_RTT This flag is off by default and will be set in an ICP_OP_QUERY message only if these two criteria are met: o It is enabled in the cache configuration file with `query_icmp on'. o The peer must be using ICP version 2. 6. Firewalls Operating a Web cache behind a firewall or in a private network poses some interesting problems. The hard part is figuring out whether the cache is able to connect to the origin server. Harvest and Squid provide an `inside_firewall' configuration directive to list DNS domains on the near side of a firewall. Everything else is assumed to be on the far side of a firewall. Squid also has a `firewall_ip' directive so that inside hosts can be specified by IP addresses as well. In a simple configuration, a Squid cache behind a firewall will have only one parent cache (which is on the firewall itself). In this case, Squid must use that parent for all servers beyond the firewall, so there is no need to utilize ICP. In a more complex configuration, there may be a number of peer caches also behind the firewall. Here, ICP may be used to check for cache hits in the peers. Occasionally, when ICP is being used, there may not be any replies received. If the cache were not behind a firewall, the request would be forwarded directly to the origin server. But in this situation, the cache must pick a parent cache, either randomly or due to configuration information. For example, Squid allows a parent cache to be designated as a default choice when no others are available. 7. Multicast For efficient distribution, a cache may deliver ICP queries to a multicast address, and neighbor caches may join the multicast group to receive such queries. Current practice is that caches send ICP replies only to unicast addresses, for several reasons: o Multicasting ICP replies would not reduce the number of packets sent. Wessels & Claffy Informational [Page 14]  RFC 2187 ICP September 1997 o It prevents other group members from receiving unexpected replies. o The reply should follow unicast routing paths to indicate (unicast) connectivity between the receiver and the sender since the subsequent HTTP request will be unicast routed. Trust is an important aspect of inter-cache relationships. A Web cache should not automatically trust any cache which replies to a multicast ICP query. Caches should ignore ICP messages from addresses not specifically configured as neighbors. Otherwise, one could easily pollute a cache mesh by running an illegitimate cache and having it join a group, return ICP_OP_HIT for all requests, and then deliver bogus content. When sending to multicast groups, cache administrators must be careful to use the minimum multicast TTL required to reach all group members. Joining a multicast group requires no special privileges and there is no way to prevent anyone from joining "your" group. Two groups of caches utilizing the same multicast address could overlap, which would cause a cache to receive ICP replies from unknown neighbors. The unknown neighbors would not be used to retrieve the object data, but the cache would constantly receive ICP replies that it must always ignore. To prevent an overlapping cache mesh, caches should thus limit the scope of their ICP queries with appropriate TTLs; an application such as mtrace[6] can determine appropriate multicast TTLs. As mentioned in section 5.1.3, we need to estimate the number of expected replies for an ICP_OP_QUERY message. For unicast we expect one reply for each query if the peer is up. However, for multicast we generally expect more than one reply, but have no way of knowing exactly how many replies to expect. Squid regularly (every 15 minutes) sends out test ICP_OP_QUERY messages to only the multicast group peers. As with a real ICP query, a timeout event is installed and the replies are counted until the timeout occurs. We have found that the received count varies considerably. Therefore, the number of replies to expect is calculated as a moving average, rounded down to the nearest integer. Wessels & Claffy Informational [Page 15]  RFC 2187 ICP September 1997 8. Lessons Learned 8.1. Differences Between ICP and HTTP ICP is notably different from HTTP. HTTP supports a rich and sophisticated set of features. In contrast, ICP was designed to be simple, small, and efficient. HTTP request and reply headers consist of lines of ASCII text delimited by a CRLF pair, whereas ICP uses a fixed size header and represents numbers in binary. The only thing ICP and HTTP have in common is the URL. Note that the ICP message does not even include the HTTP request method. The original implementation assumed that only GET requests would be cachable and there would be no need to locate non-GET requests in neighbor caches. Thus, the current version of ICP does not accommodate non-GET requests, although the next version of this protocol will likely include a field for the request method. HTTP defines features that are important for caching but not expressible with the current ICP protocol. Among these are Pragma: no-cache, If-Modified-Since, and all of the Cache-Control features of HTTP/1.1. An ICP_OP_HIT_OBJ message may deliver an object which may not obey all of the request header constraints. These differences between ICP and HTTP are the reason we discourage the use of the ICP_OP_HIT_OBJ feature. 8.2. Parents, Siblings, Hits and Misses Note that the ICP message does not have a field to indicate the intent of the querying cache. That is, nowhere in the ICP request or reply does it say that the two caches have a sibling or parent relationship. A sibling cache can only respond with HIT or MISS, not "you can retrieve this from me" or "you can not retrieve this from me." The querying cache must apply the HIT or MISS reply to its local configuration to prevent it from resolving misses through a sibling cache. This constraint is awkward, because this aspect of the relationship can be configured only in the cache originating the requests, and indirectly via the access controls configured in the queried cache as described earlier in section 4.2. Wessels & Claffy Informational [Page 16]  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). Wessels & Claffy Informational [Page 17]  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 only be detected by routers, not by hosts. However, the IP Authentication Header[7,8] can be used underneath ICP to provide cryptographic authentication of the entire IP packet containing the ICP protocol, thus eliminating the risk of IP address spoofing. Wessels & Claffy Informational [Page 18]  RFC 2187 ICP September 1997 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 for providing excellent feedback on this document, Martin Hamilton for pushing the development of multicast ICP, Eric Rescorla and Randall Atkinson 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: wessels@nlanr.net K. Claffy National Laboratory for Applied Network Research 10100 Hopkins Drive La Jolla, CA 92093 EMail: kc@nlanr.net 翻訳者： 片山 健夫 / KATAYAMA, Takeo 東京工業大学 精密工学研究所 / P&I Lab., Tokyo Inst. of Tech. tkatayam@pi.titech.ac.jp 97/09/15 怪しいと思う所は、「」で括った。誤りがあると、日本語訳を作ったこと 自体が「百害あって、一利なし」になるので、誤字、誤訳は是非教えて欲しい。