Network Working Group P. Karn
Request for Comments: 2521 Qualcomm
Category: Experimental W. Simpson
DayDreamer
March 1999
ICMP Security Failures Messages
Status of this Memo
このメモの位置付け
This document defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。著作権（C）フィリップ・カーンとウィリアムアレンシンプソン（1994年から1999年）。全著作権所有。
Abstract
抽象
This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP).
この文書では、IPセキュリティプロトコル（AHとESP）を使用した場合の障害を示すためにICMPメッセージを指定します。
Table of Contents
目次
1. Introduction .......................................... 1
2. Message Formats ....................................... 1
2.1 Bad SPI ......................................... 2
2.2 Authentication Failed ........................... 2
2.3 Decompression Failed ............................ 2
2.4 Decryption Failed ............................... 2
2.5 Need Authentication ............................. 3
2.6 Need Authorization .............................. 3
3. Error Procedures ...................................... 3
SECURITY CONSIDERATIONS ...................................... 4
HISTORY ...................................................... 5
ACKNOWLEDGEMENTS ............................................. 5
REFERENCES ................................................... 5
CONTACTS ..................................................... 6
COPYRIGHT .................................................... 7
This mechanism is intended for use with the Internet Security Protocols [RFC-1825 et sequitur] for authentication and privacy. For statically configured Security Associations, these messages indicate that the operator needs to manually reconfigure, or is attempting an unauthorized operation. These messages may also be used to trigger automated session-key management.
このメカニズムは、認証とプライバシーのためのインターネットセキュリティプロトコル[RFC-1825らsequitur]で使用するためのものです。静的に構成されたセキュリティアソシエーションのために、これらのメッセージは、オペレータが手動で再設定する必要があり、または不正な操作を試みていることを示しています。これらのメッセージはまた、自動化されたセッション・キー管理をトリガするために使用することができます。
The datagram format and basic facilities are already defined for ICMP [RFC-792].
データグラムの形式と基本施設は既にICMP [RFC-792]のために定義されています。
Up-to-date values of the ICMP Type field are specified in the most recent "Assigned Numbers" [RFC-1700]. This document concerns the following values:
ICMPタイプフィールドの最新の値は最新の「Assigned Numbers」[RFC-1700]で指定されています。このドキュメントでは、次の値に関係します：
40 Security Failures
40のセキュリティの失敗
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Original Internet Headers + 64 bits of Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 40
タイプ40
Code Indicates the kind of failure:
コードは、障害の種類を示します。
0 = Bad SPI
1 = Authentication Failed
2 = Decompression Failed
3 = Decryption Failed
4 = Need Authentication
5 = Need Authorization
Checksum Two octets. The ICMP Checksum.
チェックサムの2つのオクテット。 ICMPチェックサム。
Reserved Two octets. For future use; MUST be set to zero
2つのオクテットを禁じます。将来の使用のために。ゼロに設定する必要があります
when transmitted, and MUST be ignored when received.
ときに送信し、受信時に無視しなければなりません。
Pointer Two octets. An offset into the Original Internet Headers that locates the most significant octet of the offending SPI. Will be zero when no SPI is present.
ポインタの2つのオクテット。問題のSPIの最も重要なオクテットの位置を元のインターネットヘッダへのオフセット。何のSPIが存在しない場合はゼロになります。
Original Internet Headers ... The original Internet Protocol header, any intervening headers up to and including the offending SPI (if any), plus the first 64 bits (8 octets) of the remaining payload data.
元のインターネットヘッダ...元のインターネットプロトコルヘッダ、および問題のあるSPI（もしあれば）に加え、残りのペイロード・データの最初の64ビット（8オクテット）を含むアップ任意の介在ヘッダ。
This data is used by the host to match the message
to the appropriate process. If a payload protocol
uses port numbers, they are assumed to be in the
first 64-bits of the original datagram's payload.
Usage of this message is elaborated in the following sections.
このメッセージの使用方法については、次のセクションで詳述されます。
Indicates that a received datagram includes a Security Parameters Index (SPI) that is invalid or has expired.
受信したデータグラムが無効であるか、有効期限が切れたセキュリティパラメータインデックス（SPI）を備えていることを示します。
Indicates that a received datagram failed the authenticity or integrity check for a given SPI.
受信したデータグラムが与えられたSPIのための信憑性や整合性チェックに失敗したことを示します。
Note that the SPI may indicate an outer Encapsulating Security Protocol when a separate Authentication Header SPI is hidden inside.
別個の認証ヘッダのSPIが内部に隠されている場合、SPIは、外側カプセル化セキュリティプロトコルを示すことができることに留意されたいです。
Indicates that a received datagram failed a decompression check for a given SPI.
受信したデータグラムが与えられたSPIのために解凍チェックに失敗したことを示します。
Indicates that a received datagram failed a decryption check for a given SPI.
受信したデータグラムが与えられたSPIのための復号化チェックに失敗したことを示します。
Indicates that a received datagram will not be accepted without additional authentication.
受信したデータグラムは、追加の認証なしで受け入れられないであろうことを示します。
In this case, either no SPI is present, or an unsuitable SPI is present. For example, an encryption SPI without integrity arrives from a secure operating system with mutually suspicious users.
この場合、SPIのいずれかが存在しない、または不適切SPIが存在します。たとえば、整合性のない暗号化SPIは、相互に不審なユーザーとのセキュアなオペレーティングシステムから到着します。
Indicates that a received datagram will not be accepted because it has insufficient authorization.
それは不十分な権限を持っているので、受信したデータグラムが受け入れられないことを示します。
In this case, an authentication SPI is present that is inappropriate for the target transport or application. The principle party denoted by the SPI does not have proper authorization for the facilities used by the datagram. For example, the party is authorized for Telnet access, but not for FTP access.
この場合、認証SPIは、目標搬送またはアプリケーションのために不適切である存在します。 SPIで示さ原則当事者は、データグラムが使用する施設のための適切な権限を持っていません。例えば、当事者はなく、FTPアクセスのために、Telnetアクセスを許可されています。
As is usual with ICMP messages, upon receipt of one of these error messages that is uninterpretable or otherwise contains an error, no ICMP error message is sent in response. Instead, the message is silently discarded. However, for diagnosis of problems, a node SHOULD provide the capability of logging the error, including the contents of the silently discarded datagram, and SHOULD record the event in a statistics counter.
ICMPメッセージで通常であるように、解釈不可能であるか、またはそうでなければ、エラーが含まれているこれらのいずれかのエラーメッセージを受信すると、何のICMPエラーメッセージが応答で送信されません。代わりに、メッセージは静かに捨てられます。しかし、問題の診断のために、ノードは黙って廃棄されたデータグラムの内容を含め、エラーをログに記録する機能を提供すべきである、と統計カウンターにイベントを記録する必要があります。
On receipt, special care MUST be taken that the ICMP message actually includes information that matches a previously sent IP datagram. Otherwise, this might provide an opportunity for a denial of service attack.
領収書には、特別なケアは、ICMPメッセージは、実際に以前に送信されたIPデータグラムに一致する情報が含まれていることを注意する必要があります。そうでなければ、これは、サービス拒否攻撃の機会を提供するかもしれません。
The sending implementation MUST be able to limit the rate at which these messages are generated. The rate limit parameters SHOULD be configurable. How the limits are applied (such as, by destination or per interface) is left to the implementor's discretion.
送信実装は、これらのメッセージが生成されるレートを制限することができなければなりません。レートリミットパラメータが設定可能であるべきです。方法（界面宛先によって又はごとなど）に適用される制限は、実装者の裁量に任されています。
Security Considerations
セキュリティの考慮事項
When a prior Security Association between the parties has not expired, these messages SHOULD be sent with authentication.
当事者間の事前のセキュリティアソシエーションの有効期限が切れていない場合には、これらのメッセージは、認証を送ってください。
However, the node MUST NOT dynamically establish a new Security Association for the sole purpose of authenticating these messages. Automated key management is computationally intensive. This could be used for a very serious denial of service attack. It would be very easy to swamp a target with bogus SPIs from random IP Sources, and have it start up numerous useless key management sessions to authentically inform the putative sender.
ただし、ノードが動的にこれらのメッセージを認証する唯一の目的のために新しいセキュリティアソシエーションを確立してはなりません。自動化された鍵管理は、計算集約的です。これは、サービス攻撃の非常に深刻な否定を使用することができます。ランダムなIPソースからの偽のSPIでターゲットを圧倒することは非常に容易であり、それは本物の推定送信者に通知するために、多数の無駄な鍵管理セッションを起動する必要があります。
In the event of loss of state (such as a system crash), the node will need to send failure messages to all parties that attempt subsequent communication. In this case, the node may have lost the key management technique that was used to establish the Security Association.
（このようなシステムのクラッシュなど）の状態が失われた場合には、ノードは、その後の通信を試みるすべての関係者に障害メッセージを送信する必要があります。この場合、ノードは、セキュリティアソシエーションを確立するために使用された鍵管理技術を失っている可能性があります。
Much better to simply let the peers know that there was a failure, and let them request key management as needed (at their staggered timeouts). They'll remember the previous key management technique, and restart gracefully. This distributes the restart burden among systems, and helps allow the recently failed node to manage its computational resources.
はるかに良いだけでピアが失敗があったことを知っている、と（その千鳥タイムアウトで）必要に応じて、鍵管理を要求できるようにします。彼らは、以前の鍵管理技術を覚えて、そして優雅に再起動します。これは、システム間でリスタート負担を配布し、最近で障害が発生したノードは、その計算リソースを管理することを可能にするのに役立ちます。
In addition, these messages inform the recipient when the ICMP sender is under attack. Unlike other ICMP error messages, the messages provide sufficient data to determine that these messages are in response to previously sent messages.
ICMPの送信者が攻撃を受けている時に加えて、これらのメッセージは、受信者に通知します。他のICMPエラーメッセージとは異なり、メッセージは、これらのメッセージは、以前に送信されたメッセージに応答していることを決定するために十分なデータを提供します。
Therefore, it is imperative that the recipient accept both authenticated and unauthenticated failure messages. The recipient's log SHOULD indicate when the ICMP messages are not validated, and when the ICMP messages are not in response to a valid previous message.
したがって、受信者は、両方の認証され、認証されていない障害メッセージを受け入れることが不可欠です。 ICMPメッセージが有効な前のメッセージに対応していないとき、受信者のログは、ICMPメッセージが検証されていない場合を示し、そしてべきです。
There is some concern that sending these messages may result in the leak of security information. For example, an attacker might use these messages to test or verify potential forged keys. However, this information is already available through the simple expedient of using Echo facilities, or waiting for a TCP 3-way handshake.
これらのメッセージを送信することは、セキュリティ情報の漏洩につながることが、いくつかの懸念があります。例えば、攻撃者は、テストまたは潜在的な偽造キーを確認するために、これらのメッセージを使用する場合があります。しかし、この情報はエコー機能を使用して、またはTCP 3ウェイハンドシェイクを待っているという単純なを通じてすでに利用可能です。
The rate limiting mechanism also limits this form of leak, as many messages will not result in an error indication. At the very least, this will lengthen the time factor for verifying such information.
多くのメッセージはエラー表示を生じないように速度制限機構はまた、漏れのこの形態を制限します。少なくとも、これはそのような情報を確認するための時間係数が長くなります。
History
歴史
The text has been extensively reviewed on the IP Security mailing list, in January and February of 1995 and again in December 1995. The specification is stable, and was forwarded to the IESG by the authors for IETF Last Call as a Proposed Standard in March 1996. There have been several implementations.
仕様が安定しており、1996年3月中のProposed StandardとしてIETFラストコールのために著者によってIESGに転送された1995年の1月と2月にし、再び1995年12月にテキストが広く、IPセキュリティメーリングリストで検討されています。いくつかの実装がありました。
Acknowledgements
謝辞
Some of the text of this specification was derived from "Requirements for Internet Hosts -- Communication Layers" [RFC-1122] and "Requirements for IP Version 4 Routers" [RFC-1812].
[RFC-1122]と「IPバージョン4つのルータのための要件」[RFC-1812] - この仕様のテキストの一部は、「通信レイヤーインターネットホストのための要件」から派生しました。
Naganand Doraswamy and Hilarie Orman provided useful critiques of earlier versions of this document.
Naganand Doraswamyとヒラリーオーマンはこのドキュメントの以前のバージョンの有益な批評を提供します。
Stimulating comments were also received from Jeffrey Schiller.
刺激的なコメントは、ジェフリー・シラーから受け取りました。
Special thanks to the Center for Information Technology Integration (CITI) for providing computing resources.
コンピューティングリソースを提供するための情報基盤の統合のためのセンター（CITI）に感謝します。
References
リファレンス
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, September 1981.
[RFC-792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、1981年9月。
[RFC-1122] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, USC/Information Sciences Institute, October 1989.
[RFC-1122]ブレーデン、R.、エディタ、 "インターネットホストのための要件 - 通信層"、STD 3、USC /情報科学研究所、1989年10月。
[RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, USC/Information Sciences Institute, October 1994.
[RFC-1700]レイノルズ、J.、およびポステル、J.、 "割り当て番号"、STD 2、USC /情報科学研究所、1994年10月。
[RFC-1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", Cisco Systems, June 1995.
[RFC-1812]ベイカー、F.、エディタ、 "IPバージョン4つのルータのための要件"、シスコシステムズ、1995年6月。
[RFC-1825] Atkinson, R., "Security Architecture for the Internet Protocol", Naval Research Laboratory, July 1995.
[RFC-1825]アトキンソン、R.、 "インターネットプロトコルのためのセキュリティー体系"、海軍研究所、1995年7月。
Contacts
コンタクト
Comments about this document should be discussed on the photuris@adk.gr mailing list.
この文書についてのコメントはphoturis@adk.grメーリングリストで議論されるべきです。
Questions about this document can also be directed to:
このドキュメントに関する質問も対象とすることができます。
Phil Karn Qualcomm, Inc. 6455 Lusk Blvd. San Diego, California 92121-2779
フィル・カーンクアルコム社6455ラスクブルバードサンディエゴ、カリフォルニア92121-2779
karn@qualcomm.com
karn@unix.ka9q.ampr.org (preferred)
William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
ウィリアムアレンシンプソン空想家コンピュータシステムズコンサルティングサービス1384フォンテーヌマディソンハイツ、ミシガン州48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。著作権（C）フィリップ・カーンとウィリアムアレンシンプソン（1994年から1999年）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards (in which case the procedures for copyrights defined in the Internet Standards process must be followed), or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手続きが規定されている場合には（インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化過程で）続く、またはとしては、英語以外の言語に翻訳するために必要とされなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
基礎とインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または黙示、（に限らず）を含めた情報の使用は、本明細書に一切の保証「そのまま」本明細書中に含まれるこの文書や情報を上に設けられています特定の目的に対する権利または商品性または適合性の黙示の保証を侵害することはありません。