Network Working Group S. Kent
Request for Comments: 4304 BBN Technologies
Category: Standards Track December 2005
Network Working Group S. Kent
Request for Comments: 4304 BBN Technologies
Category: Standards Track December 2005
Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
Internet安全关联和密钥管理协议（ISAKMP）IPsec解释域（DOI）的扩展序列号（ESN）附录
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol (ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended (64- bit) sequence numbers (ESNs) for a particular AH or ESP security association.
IP安全认证头（AH）和封装安全有效负载（ESP）协议使用序列号来检测重播。本文档描述了对Internet安全关联和密钥管理协议（ISAKMP）的Internet IP安全解释域（DOI）的扩展。这些扩展支持为特定AH或ESP安全关联协商使用传统32位序列号或扩展（64位）序列号（ESN）。
The specifications for the IP Authentication Header (AH) [AH] and the IP Encapsulating Security Payload (ESP) [ESP] describe an option for use of extended (64-bit) sequence numbers. This option permits transmission of very large volumes of data at high speeds over an IPsec Security Association, without rekeying to avoid sequence number space exhaustion. This document describes the additions to the IPsec DOI for ISAKMP [DOI] that are needed to support negotiation of the extended sequence number (ESN) option.
IP认证头（AH）[AH]和IP封装安全有效负载（ESP）[ESP]的规范描述了使用扩展（64位）序列号的选项。此选项允许通过IPsec安全关联高速传输大量数据，而无需重新设置密钥以避免序列号空间耗尽。本文档描述了ISAKMP[DOI]的IPsec DOI的新增功能，这些功能是支持扩展序列号（ESN）选项协商所必需的。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、推荐、可和可选时，应按照RFC 2119[Bra97]中的说明进行解释。
The following SA attribute definition is used in Phase II of an Internet Key Exchange Protocol (IKE) negotiation. The attribute type is Basic (B). Encoding of this attribute is defined in the base ISAKMP specification [ISAKMP]. Attributes described as basic MUST NOT be encoded as variable. See [IKE] for further information on attribute encoding in the IPsec DOI. All restrictions listed in [IKE] also apply to the IPsec DOI and to this addendum.
以下SA属性定义用于Internet密钥交换协议（IKE）协商的第二阶段。属性类型为基本（B）。此属性的编码在基本ISAKMP规范[ISAKMP]中定义。描述为基本的属性不能编码为变量。有关IPsec DOI中属性编码的更多信息，请参阅[IKE]。[IKE]中列出的所有限制也适用于IPsec DOI和本附录。
Attribute Type
属性类型
class value type
---------------------------------------------------------
Extended (64-bit) Sequence Number 11 B
class value type
---------------------------------------------------------
Extended (64-bit) Sequence Number 11 B
Class Values
阶级价值观
This class specifies that the Security Association will be using 64-bit sequence numbers. (See [AH] and [ESP] for a description of extended (64-bit) sequence numbers.)
此类指定安全关联将使用64位序列号。（有关扩展（64位）序列号的说明，请参见[AH]和[ESP]
RESERVED 0 64-bit Sequence Number 1
保留0 64位序列号1
If an implementation receives a defined IPsec DOI attribute (or attribute value) that it does not support, an ATTRIBUTES-NOT-SUPPORT SHOULD be sent and the security association setup MUST be aborted.
如果实现接收到它不支持的已定义IPsec DOI属性（或属性值），则应发送ATTRIBUTES-not-support，并且必须中止安全关联设置。
If an implementation receives any attribute value but the value for 64-bit sequence numbers, the security association setup MUST be aborted.
如果实现接收到除64位序列号的值以外的任何属性值，则必须中止安全关联设置。
This memo pertains to the Internet Key Exchange protocol [IKE], which combines ISAKMP [ISAKMP] and Oakley [OAKLEY] to provide for the derivation of cryptographic keying material in a secure and authenticated manner. Specific discussion of the various security protocols and transforms identified in this document can be found in the associated base documents and in the cipher references.
本备忘录涉及互联网密钥交换协议[IKE]，该协议结合了ISAKMP[ISAKMP]和Oakley[Oakley]，以安全和认证的方式提供加密密钥材料的推导。本文档中确定的各种安全协议和转换的具体讨论可在相关基础文档和密码参考中找到。
The addition of the ESN attribute does not change the underlying security characteristics of IKE. In using ESNs with ESP, it is important to employ an encryption mode that is secure when very large volumes of data are encrypted under a single key. Thus, for example, Data Encryption Standard (DES) in Cipher Block Chaining (CBC) mode would NOT be suitable for use with the ESN, because no more than 2^32 blocks should be encrypted under a single DES key in that mode. Similarly, the integrity algorithm used with ESP or AH should be secure relative to the number of packets being protected. To avoid potential security problems imposed by algorithm limitations, the SA lifetime may be set to limit the volume of data protected with a single key, prior to reaching the 2^64 packet limit imposed by the ESN.
添加ESN属性不会改变IKE的基本安全特性。在将ESN与ESP结合使用时，重要的是采用一种加密模式，该模式在使用单个密钥加密大量数据时是安全的。因此，例如，密码块链接（CBC）模式下的数据加密标准（DES）不适合与ESN一起使用，因为在该模式下，在单个DES密钥下加密的块不应超过2^32个。类似地，与ESP或AH一起使用的完整性算法应该相对于受保护的数据包数量是安全的。为了避免算法限制带来的潜在安全问题，可以在达到ESN施加的2^64数据包限制之前，将SA生存期设置为限制使用单个密钥保护的数据量。
This document contains a "magic" number to be maintained by the IANA. No additional class values will be assigned for this attribute. The IANA has allocated an IPsec Security Attribute value for "Attribute Type". This value is listed under the heading "value" in the table in Section 2.
本文件包含IANA维护的“魔术”编号。不会为此属性指定其他类值。IANA已为“属性类型”分配IPsec安全属性值。该值列在第2节表格中标题“值”下。
Acknowledgements
致谢
The author would like to thank the members of the IPsec working group. The author would also like to acknowledge the contributions of Karen Seo for her help in the editing of this specification.
作者要感谢IPsec工作组的成员。作者还想感谢Karen Seo在编辑本规范方面的贡献。
Normative References
规范性引用文件
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[DOI]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4303，2005年12月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[ISAKMP]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
Informative References
资料性引用
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[OAKLEY]Orman，H.，“OAKLEY密钥确定协议”，RFC 2412，1998年11月。
Author's Address
作者地址
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
美国马萨诸塞州剑桥莫尔顿街10号Stephen Kent BBN Technologies 02138
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。