RFC2521 日本語訳

Network Working Group                                            P. Karn
Request for Comments: 2521                                      Qualcomm
Category: Experimental                                        W. Simpson
                                                              DayDreamer
                                                              March 1999

Karnがコメントのために要求するワーキンググループP.をネットワークでつないでください: 2521年のクアルコムカテゴリ: 1999年の実験的なW.シンプソン空想家行進

                    ICMP Security Failures Messages

ICMPセキュリティ失敗メッセージ

Status of this Memo

この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.

Copyright(C)インターネット協会(1999)。 Copyright(C)フィリップKarnとウィリアム・アレン・シンプソン(1994-1999)。 All rights reserved。

Abstract

要約

   This document specifies ICMP messages for indicating failures when
   using IP Security Protocols (AH and ESP).

このドキュメントはIPセキュリティー・プロトコル(AHと超能力)を使用するとき失敗を示すことへのICMPメッセージを指定します。

Karn & Simpson                Experimental                      [Page i]

RFC 2521                 ICMP Security Failures               March 1999

KarnとシンプソンExperimental[ページi]RFC2521ICMP Security Failures行進1999

Table of Contents

目次

     1.     Introduction ..........................................    1

1. 序論… 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

2. メッセージ形式… 1 2.1 悪いSPI… 2 2.2 認証は失敗しました… 2 2.3 減圧は失敗しました… 2 2.4復号化は失敗しました… 2 2.5は認証を必要とします… 3 2.6 認可を要してください… 3

     3.     Error Procedures ......................................    3

3. 誤り処理手続き… 3

     SECURITY CONSIDERATIONS ......................................    4

セキュリティ問題… 4

     HISTORY ......................................................    5

歴史… 5

     ACKNOWLEDGEMENTS .............................................    5

承認… 5

     REFERENCES ...................................................    5

参照… 5

     CONTACTS .....................................................    6

連絡します。 6

     COPYRIGHT ....................................................    7

著作権… 7

Karn & Simpson                Experimental                     [Page ii]

RFC 2521                 ICMP Security Failures               March 1999

KarnとシンプソンExperimental[ページii]RFC2521ICMP Security Failures行進1999

1.  Introduction

1. 序論

   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.

このメカニズムはインターネットSecurityプロトコル[RFC-1825 et sequitur]との認証とプライバシーの使用のために意図します。 静的に構成されたSecurity Associationsに関してこれらのメッセージは、オペレータが、必要であるのを示します。手動で権限のない操作を再構成するか、または試みています。 また、これらのメッセージは、自動化されたセッションかぎ管理の引き金となるのに使用されるかもしれません。

   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:

最新の「規定番号」[RFC-1700]でICMP Type分野の最新の値は指定されます。 このドキュメントは以下の値に関係があります:

       40  Security Failures

40 セキュリティ失敗

2.  Message Formats

2. メッセージ・フォーマット

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |          Pointer              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~     Original Internet Headers + 64 bits of Payload            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| 指針| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 有効搭載量~のオリジナルのインターネットHeaders+64ビット| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type              40

40をタイプしてください。

   Code             Indicates the kind of failure:

Indicatesをコード化してください、失敗の種類:

                      0 = Bad SPI
                      1 = Authentication Failed
                      2 = Decompression Failed
                      3 = Decryption Failed
                      4 = Need Authentication
                      5 = Need Authorization

0 = 失敗した認証=減圧失敗した3=2悪いSPI1=復号化は必要性認証5=必要性4=承認に失敗しました。

   Checksum         Two octets.  The ICMP Checksum.

チェックサムTwo八重奏。 ICMPチェックサム。

   Reserved         Two octets.  For future use; MUST be set to zero

予約されたTwo八重奏。 今後の使用のために。 ゼロに設定しなければなりません。

Karn & Simpson                Experimental                      [Page 1]

RFC 2521                 ICMP Security Failures               March 1999

1999年の[1ページ]RFC2521ICMPセキュリティ失敗行進のときに実験的なKarnとシンプソン

                    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.

指針Two八重奏。 怒っているSPIの最も重要な八重奏の場所を見つけるOriginalインターネットHeadersへのオフセット。 どんな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.

このメッセージの用法は以下のセクションに詳しく説明されます。

2.1.  Bad SPI

2.1. 悪いSPI

   Indicates that a received datagram includes a Security Parameters
   Index (SPI) that is invalid or has expired.

容認されたデータグラムが無効であるか、または期限が切れたSecurity Parameters Index(SPI)を含んでいるのを示します。

2.2.  Authentication Failed

2.2. 認証は失敗しました。

   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.

別々のAuthentication Header SPIが中に隠されるとき、SPIが外側のEncapsulating Securityプロトコルを示すかもしれないことに注意してください。

2.3.  Decompression Failed

2.3. 減圧は失敗しました。

   Indicates that a received datagram failed a decompression check for a
   given SPI.

容認されたデータグラムが与えられたSPIのために減圧チェックに失敗したのを示します。

2.4.  Decryption Failed

2.4. 復号化は失敗しました。

   Indicates that a received datagram failed a decryption check for a
   given SPI.

容認されたデータグラムが与えられたSPIのために復号化チェックに失敗したのを示します。

Karn & Simpson                Experimental                      [Page 2]

RFC 2521                 ICMP Security Failures               March 1999

1999年の[2ページ]RFC2521ICMPセキュリティ失敗行進のときに実験的なKarnとシンプソン

2.5.  Need Authentication

2.5. 必要性認証

   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は互いに疑わしげなユーザと共にセキュア・オペレーティング・システムから到着します。

2.6.  Need Authorization

2.6. 認可を要してください。

   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アクセサリーのために認可されるというわけではありません。

3.  Error Procedures

3. 誤り処理手続き

   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.

ご多分に漏れず、「非-解明でき」であるか、またはそうでなければ誤りを含むこれらのエラーメッセージの1つを受け取り次第ICMPメッセージと共に、応答でICMPエラーメッセージを全く送りません。 代わりに、メッセージは静かに捨てられます。 しかしながら、問題、静かに捨てられたデータグラム、およびSHOULDのコンテンツを含んでいて、SHOULDが誤りを登録する能力を提供するノードの診断には、統計カウンタに出来事を記録に残してください。

   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.

送付実装はこれらのメッセージが発生しているレートを制限できなければなりません。 レートはパラメタSHOULDを制限します。構成可能であってください。 限界がどう適用されているかは(インタフェース、目的地またはインタフェースあたりの)作成者のものに任せます。

Karn & Simpson                Experimental                      [Page 3]

RFC 2521                 ICMP Security Failures               March 1999

1999年の[3ページ]RFC2521ICMPセキュリティ失敗行進のときに実験的なKarnとシンプソン

Security Considerations

セキュリティ問題

   When a prior Security Association between the parties has not
   expired, these messages SHOULD be sent with authentication.

aであるときに、パーティーの間の先のSecurity Associationは期限が切れていなくて、これらはメッセージSHOULDです。認証と共に送ります。

   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.

しかしながら、ノードはこれらのメッセージを認証する唯一の目的のためにダイナミックに新しいSecurity Associationを設立してはいけません。 自動化されたかぎ管理は計算上徹底的です。 非常に重大なサービス不能攻撃にこれを使用できました。 無作為のIP SourcesからにせのSPIsで目標を圧倒して、ほんとうに推定の送付者に知らせるために頻繁な役に立たないかぎ管理でセッションを始めさせるのは、非常に簡単でしょう。

   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.

状態(システムクラッシュなどの)の損失の場合、ノードは、その後のコミュニケーションを試みるすべてのパーティーに失敗メッセージを送る必要があるでしょう。 この場合、ノードは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.

したがって、受取人が認証されて非認証の両方にされた失敗メッセージを受け入れるのは、必須です。 受取人のログSHOULDは前の有効なメッセージに対応して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.

これらのメッセージを送るとセキュリティ情報の漏出がもたらされるかもしれないという何らかの関心があります。 例えば、攻撃者は潜在的偽造キーについてテストするか、または確かめるこれらのメッセージを使用するかもしれません。 しかしながら、この情報はEcho施設を使用するか、またはTCP3ウェイ握手を待つ簡単な方法で既に利用可能です。

   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.

また、多くのメッセージが誤り表示をもたらしていない間、メカニズムを制限するレートはこのフォームの漏出を制限します。 少なくとも、これはそのような情報について確かめるための時間要素を伸すでしょう。

Karn & Simpson                Experimental                      [Page 4]

RFC 2521                 ICMP Security Failures               March 1999

1999年の[4ページ]RFC2521ICMPセキュリティ失敗行進のときに実験的なKarnとシンプソン

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.

テキストはIP Securityメーリングリストで手広く批評されました、1995年1月、2月、再び1995年12月に。 仕様は、安定していて、1996年3月にIETF Last CallのためにProposed Standardとして作者によって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.

情報Technology Integration(シティ)のためのセンターおかげでは、コンピューティング資源を提供するのにおいて、特別です。

References

参照

   [RFC-792]   Postel, J., "Internet Control Message Protocol", STD 5,
               September 1981.

[RFC-792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、1981年9月。

   [RFC-1122]  Braden, R., Editor, "Requirements for Internet Hosts --
               Communication Layers", STD 3, USC/Information Sciences
               Institute, October 1989.

[RFC-1122] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、科学が設けるUSC/情報、10月1989日

   [RFC-1700]  Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
               USC/Information Sciences Institute, October 1994.

[RFC-1700] USC/情報科学が1994年10月に設けるレイノルズ、J.、およびポステル、J.、「規定番号」、STD2。

   [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月。

Karn & Simpson                Experimental                      [Page 5]

RFC 2521                 ICMP Security Failures               March 1999

1999年の[5ページ]RFC2521ICMPセキュリティ失敗行進のときに実験的なKarnとシンプソン

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

フィルKarnクアルコムInc.6455ラスク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(都合のよい)です。

Karn & Simpson                Experimental                      [Page 6]

RFC 2521                 ICMP Security Failures               March 1999

1999年の[6ページ]RFC2521ICMPセキュリティ失敗行進のときに実験的なKarnとシンプソン

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  Copyright (C) Philip
   Karn and William Allen Simpson (1994-1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 Copyright(C)フィリップKarnとウィリアム・アレン・シンプソン(1994-1999)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は、それを英語以外の言語に翻訳するようにインターネット協会の版権情報か参照かインターネット標準を開発する目的に必要である以外の他のインターネット組織(その場合、インターネットStandardsプロセスで定義された著作権のための手順に従わなければならない)を取り除くことなどのどんな方法、または必要に応じても変更されないかもしれません。

   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.

このドキュメントとここに含まれた情報はそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄するかどうかということです、急行であるか、または含意されて、情報の使用がここに侵害しないどんな保証も含むのは(他)、市場性か特定目的への適合性のどんな権利かあらゆる黙示的な保証です。

Karn & Simpson                Experimental                      [Page 7]

KarnとシンプソンExperimentalです。[7ページ]