Network Working Group                                            P. Karn
Request for Comments: 2521                                      Qualcomm
Category: Experimental                                        W. Simpson
                                                              DayDreamer
                                                              March 1999
        
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.

版权所有(C)互联网协会(1999年)。版权所有(C)Philip Karn和William Allen Simpson(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
        
     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
        
     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
        
     3.     Error Procedures ......................................    3
        
     SECURITY CONSIDERATIONS ......................................    4
        
     SECURITY CONSIDERATIONS ......................................    4
        
     HISTORY ......................................................    5
        
     HISTORY ......................................................    5
        
     ACKNOWLEDGEMENTS .............................................    5
        
     ACKNOWLEDGEMENTS .............................................    5
        
     REFERENCES ...................................................    5
        
     REFERENCES ...................................................    5
        
     CONTACTS .....................................................    6
        
     CONTACTS .....................................................    6
        
     COPYRIGHT ....................................................    7
        
     COPYRIGHT ....................................................    7
        
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.

该机制旨在与互联网安全协议[RFC-1825 et 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类型字段的最新值在最新的“分配编号”[RFC-1700]中指定。本文件涉及以下值:

40 Security Failures

40安全故障

2. Message Formats
2. 消息格式
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |          Pointer              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~     Original Internet Headers + 64 bits of Payload            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     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.

校验和两个八位字节。ICMP校验和。

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

保留两个八位组。供日后使用;必须设置为零

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.

指针是两个八位字节。原始Internet报头中的偏移量,用于定位违规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.

下面几节将详细介绍此消息的用法。

2.1. Bad SPI
2.1. 坏SPI

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

指示接收到的数据报包含无效或已过期的安全参数索引(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.

注意,当单独的认证报头SPI隐藏在内部时,SPI可能指示外部封装安全协议。

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的解密检查。

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.

与通常的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.

有人担心发送这些消息可能会导致安全信息泄漏。例如,攻击者可能会使用这些消息来测试或验证潜在的伪造密钥。然而,通过使用Echo设施或等待TCP三方握手等简单的权宜之计,这些信息已经可用。

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月和2月以及1995年12月在IP安全邮件列表上进行了广泛审查。该规范是稳定的,作者于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.,“互联网控制消息协议”,标准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/信息科学研究所,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/信息科学研究所,1994年10月。

[RFC-1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", Cisco Systems, June 1995.

[RFC-1812]Baker,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)

karn@qualcomm.com karn@unix.ka9q.ampr.org(首选)

William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071

William Allen Simpson DayDreamer计算机系统咨询服务1384 Fontaine Madison Heights,Michigan 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.

版权所有(C)互联网协会(1999年)。版权所有(C)Philip Karn和William Allen Simpson(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.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括(但不限于)保证使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。