[要約] RFC 2521は、ICMPセキュリティの失敗メッセージに関する標準化された仕様です。その目的は、ネットワーク上のセキュリティの問題を特定し、適切な対策を講じるための情報を提供することです。
Network Working Group P. Karn
Request for Comments: 2521 Qualcomm
Category: Experimental W. Simpson
DayDreamer
March 1999
ICMP Security Failures Messages
ICMPセキュリティ障害メッセージ
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
Copyright（c）The Internet Society（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 ET Schequitur]で使用することを目的としています。静的に構成されたセキュリティ関連の場合、これらのメッセージは、オペレーターが手動で再構成する必要があるか、不正な操作を試みていることを示しています。これらのメッセージは、自動化されたセッションキー管理をトリガーするためにも使用できます。
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タイプフィールドの最新の値は、最新の「割り当てられた数字」[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
0 =悪いSPI 1 =認証失敗2 =減圧失敗3 =復号化失敗4 =認証が必要5 =承認が必要
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.
このデータは、メッセージを適切なプロセスに一致させるためにホストによって使用されます。ペイロードプロトコルがポート番号を使用する場合、それらは元のデータグラムのペイロードの最初の64ビットにあると想定されます。
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で示される原則パーティーには、データグラムが使用する施設に対して適切な許可がありません。たとえば、当事者はTelnetアクセスが許可されていますが、FTPアクセスは許可されていません。
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ソースからの偽のスピスを使用してターゲットを停止し、推定送信者に本物に通知するために多くの役に立たないキー管理セッションを開始するのは非常に簡単です。
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.
このテキストは、1995年1月と1995年12月にIPセキュリティメーリングリストで広範囲にレビューされ、1995年12月に再び検討されており、仕様は安定しており、1996年3月に提案された基準としてIETFの最終呼び出しのために著者によってIESGに転送されました。。いくつかの実装がありました。
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とHilarie Ormanは、このドキュメントの以前のバージョンの有用な批判を提供しました。
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] Postel、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] Braden、R.、編集者、「インターネットホストの要件 - 通信層」、STD 3、USC/Information Sciences Institute、1989年10月。
[RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, USC/Information Sciences Institute, October 1994.
[RFC-1700] Reynolds、J。、およびPostel、J。、「割り当てられた番号」、STD 2、USC/Information Sciences Institute、1994年10月。
[RFC-1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", Cisco Systems, June 1995.
[RFC-1812] Baker、F.、編集者、「IPバージョン4ルーターの要件」、Cisco Systems、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
Phil Karn Qualcomm、Inc。6455 Lusk Blvd.カリフォルニア州サンディエゴ92121-2779
karn@qualcomm.com karn@unix.ka9q.ampr.org (preferred)
karn@qualcomm.com karn@unix.ka9q.ampr.org（優先）
William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
ウィリアム・アレン・シンプソン・デイドレーマー・コンピューター・システムコンサルティングサービス1384フォンテーヌ・マディソン・ハイツ、ミシガン州48071
wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred)
wsimpson@umich.edu wsimpson@greendragon.com（優先）
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
本書に含まれるこの文書と情報は、「現状のまま」に基づいて提供されており、インターネット協会とインターネットエンジニアリングタスクフォースは、本書の情報の使用が保証を含む（ただし、これらに限定されない）すべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害しません。