Network Working Group S. Bellovin
Request for Comments: 3554 J. Ioannidis
Category: Standards Track AT&T Labs - Research
A. Keromytis
Columbia University
R. Stewart
Cisco
July 2003
Network Working Group S. Bellovin
Request for Comments: 3554 J. Ioannidis
Category: Standards Track AT&T Labs - Research
A. Keromytis
Columbia University
R. Stewart
Cisco
July 2003
On the Use of Stream Control Transmission Protocol (SCTP) with IPsec
流控制传输协议（SCTP）在IPsec中的应用
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic.
本文档描述了IPsec（RFC 2401）和Internet密钥交换（IKE）（RFC 2409）的功能要求，以便于它们用于保护SCTP（RFC 2960）流量。
The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connection-less packet network such as IP. SCTP is designed to transport PSTN signaling messages over IP networks, but is capable of broader applications.
流控制传输协议（SCTP）是一种可靠的传输协议，在IP等无连接分组网络上运行。SCTP设计用于通过IP网络传输PSTN信令消息，但具有更广泛的应用能力。
When SCTP is used over IP networks, it may utilize the IP security protocol suite [RFC2402][RFC2406] for integrity and confidentiality. To dynamically establish IPsec Security Associations (SAs), a key negotiation protocol such as IKE [RFC2409] may be used.
当通过IP网络使用SCTP时，它可以利用IP安全协议套件[RFC2402][RFC2406]实现完整性和机密性。为了动态地建立IPsec安全关联（SAs），可以使用诸如IKE[RFC2409]之类的密钥协商协议。
This document describes functional requirements for IPsec and IKE to facilitate their use in securing SCTP traffic. In particular, we discuss additional support in the form of a new ID type in IKE [RFC2409] and implementation choices in the IPsec processing to accommodate for the multiplicity of source and destination addresses associated with a single SCTP association.
本文档描述了IPsec和IKE的功能要求，以便于它们用于保护SCTP流量。特别是，我们讨论了IKE[RFC2409]中新ID类型形式的额外支持，以及IPsec处理中的实现选择，以适应与单个SCTP关联相关联的源地址和目标地址的多样性。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC-2119].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”应按照[RFC-2119]中所述进行解释。
When utilizing the Authentication Header [RFC2402] or Encapsulating Security Payload [RFC2406] protocols to provide security services for SCTP frames, the SCTP frame is treated as just another transport layer protocol on top of IP (same as TCP, UDP, etc.)
当利用身份验证头[RFC2402]或封装安全有效负载[RFC2406]协议为SCTP帧提供安全服务时，SCTP帧被视为IP之上的另一个传输层协议（与TCP、UDP等相同）
IPsec implementations should already be able to use the SCTP transport protocol number as assigned by IANA as a selector in their Security Policy Database (SPD). It should be straightforward to extend existing implementations to use the SCTP source and destination port numbers as selectors in the SPD. Since the concept of a port, and its location in the transport header is protocol-specific, the IPsec code responsible for identifying the transport protocol ports has to be suitably modified. This, however is not enough to fully support the use of SCTP in conjunction with IPsec.
IPsec实现应该已经能够使用IANA分配的SCTP传输协议号作为其安全策略数据库（SPD）中的选择器。扩展现有实现以使用SCTP源端口号和目标端口号作为SPD中的选择器应该很简单。由于端口的概念及其在传输报头中的位置是特定于协议的，因此必须适当修改负责标识传输协议端口的IPsec代码。但是，这还不足以完全支持将SCTP与IPsec结合使用。
Since SCTP can negotiate sets of source and destination addresses (not necessarily in the same subnet or address range) that may be used in the context of a single association, the SPD should be able to accommodate this. The straightforward, and expensive, way is to create one SPD entry for each pair of source/destination addresses negotiated. A better approach is to associate sets of addresses with the source and destination selectors in each SPD entry (in the case of non-SCTP traffic, these sets would contain only one element). While this is an implementation decision, implementors are encouraged to follow this or a similar approach when designing or modifying the SPD to accommodate SCTP-specific selectors.
由于SCTP可以协商可能在单个关联上下文中使用的源地址和目标地址集（不一定在同一子网或地址范围内），SPD应该能够适应这一点。简单而昂贵的方法是为协商的每对源/目标地址创建一个SPD条目。更好的方法是将地址集与每个SPD条目中的源和目标选择器相关联（在非SCTP流量的情况下，这些集合将只包含一个元素）。虽然这是一项实施决策，但鼓励实施者在设计或修改SPD以适应SCTP特定选择器时遵循此方法或类似方法。
Similarly, SAs may have multiple associated source and destination addresses. Thus an SA is identified by the extended triplet ({set of destination addresses}, SPI, Security Protocol). A lookup in the Security Association Database (SADB) using the triplet (Destination Address, SPI, Security Protocol), where Destination Address is any of the negotiated peer addresses, MUST return the same SA.
类似地，SAs可能具有多个关联的源地址和目标地址。因此，SA由扩展的三元组（{目标地址集}，SPI，安全协议）标识。使用三元组（目标地址、SPI、安全协议）在安全关联数据库（SADB）中进行查找，其中目标地址是任何协商的对等地址，必须返回相同的SA。
There are two issues relevant to the use of IKE when negotiating protection for SCTP traffic:
在协商SCTP流量保护时，有两个问题与IKE的使用有关：
a) Since SCTP allows for multiple source and destination network addresses associated with an SCTP association, it MUST be possible for IKE to efficiently negotiate these in the Phase 2 (Quick Mode) exchange. The straightforward approach is to negotiate one pair of IPsec SAs for each combination of source and destination addresses. This can result in an unnecessarily large number of SAs, thus wasting time (in negotiating these) and memory. All current implementations of IKE support this functionality. However, a method for specifying multiple selectors in Phase 2 is desirable for efficiency purposes. Conformance with this document requires that implementations adhere to the guidelines in the rest of this section.
a) 由于SCTP允许与SCTP关联关联的多个源和目标网络地址，因此IKE必须能够在第2阶段（快速模式）交换中有效地协商这些地址。简单的方法是为源地址和目标地址的每个组合协商一对IPsec SA。这可能会导致不必要的大量SA，从而浪费时间（在协商这些SA时）和内存。IKE的所有当前实现都支持此功能。然而，为了提高效率，需要在阶段2中指定多个选择器的方法。与本文档的一致性要求实现遵守本节其余部分中的指导原则。
Define a new type of ID, ID_LIST, that allows for recursive inclusion of IDs. Thus, the IKE Phase 2 Initiator ID for an SCTP association MAY be of type ID_LIST, which would in turn contain as many ID_IPV4_ADDR IDs as necessary to describe Initiator addresses; likewise for Responder IDs. Note that other selector types MAY be used when establishing SAs for use with SCTP, if there is no need to use negotiate multiple addresses for each SCTP endpoint (i.e., if only one address is used by each peer of an SCTP flow). Implementations MUST support this new ID type.
定义一种新类型的ID，ID_LIST，它允许递归包含ID。因此，用于SCTP关联的IKE阶段2发起方ID可以是ID_LIST类型，其将依次包含描述发起方地址所需的尽可能多的ID_IPV4_ADDR ID；对于响应者ID也是如此。注意，如果不需要为每个SCTP端点使用多个地址（即，如果SCTP流的每个对等方只使用一个地址），则在建立SAs以与SCTP一起使用时，可以使用其他选择器类型。实现必须支持这种新的ID类型。
ID_LIST IDs cannot appear inside ID_LIST ID payloads. Any of the ID types defined in [RFC2407] can be included inside an ID_LIST ID. Each of the IDs contained in the ID_LIST ID must include a complete Identification Payload header.
ID_列表ID不能出现在ID_列表ID有效负载内。[RFC2407]中定义的任何ID类型都可以包含在ID_列表ID中。ID_列表ID中包含的每个ID必须包含完整的标识有效负载标头。
The following diagram illustrates the content of an ID_LIST ID payload that contains two ID_FQDN payloads.
下图说明了包含两个ID_FQDN有效负载的ID_列表ID有效负载的内容。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! Protocol ID ! Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! Protocol ID ! Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FQDN 1 Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! Protocol ID ! Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FQDN 2 Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! Protocol ID ! Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! Protocol ID ! Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FQDN 1 Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! Protocol ID ! Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FQDN 2 Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Next Payload field in any of the included IDs (for FQDN 1 and FQDN 2) MUST be ignored by the Responder. The Payload Length, ID Type, Protocol ID, and Port fields of the included Payloads should be set to the appropriate values. The Protocol ID and Port fields of the ID_LIST Payload should be set to zero by the Initiator and MUST be ignored by the Responder.
响应程序必须忽略任何包含的ID（FQDN 1和FQDN 2）中的下一个有效负载字段。应将包含的有效负载的有效负载长度、ID类型、协议ID和端口字段设置为适当的值。ID_列表有效负载的协议ID和端口字段应由启动器设置为零，并且必须由响应程序忽略。
Different types of IDs (e.g., an ID_FQDN and an ID_IPV4_ADDR) can be included inside the same ID_LIST ID. If an ID type included in an ID_LIST ID payload is invalid in the context the ID_LIST ID is used, the whole ID_LIST should be considered to be at fault, e.g., if an ID_LIST ID payload that contains an ID_FQDN and an ID_IPV4_ADDR is received during an IKE Quick Mode exchange, the Responder should signal a fault to the Initiator and stop processing of the message (the same behavior it would exhibit if simply an ID_FQDN was received instead).
不同类型的ID（例如，ID_FQDN和ID_IPV4_ADDR）可以包含在同一ID_列表ID中。如果ID_列表ID有效负载中包含的ID类型在使用ID_列表ID的上下文中无效，则应认为整个ID_列表存在故障，例如。，如果在IKE快速模式交换期间接收到包含ID_FQDN和ID_IPV4_ADDR的ID_列表ID有效负载，则响应程序应向启动器发出故障信号，并停止消息处理（如果只是接收ID_FQDN，则会显示相同的行为）。
The IANA-assigned number for the ID_LIST ID is 12.
为ID_列表ID分配的IANA编号为12。
b) For IKE to be able to validate the Phase 2 selectors, it must be possible to exchange sufficient information during Phase 1. Currently, IKE can directly accommodate the simple case of two peers talking to each other, by using Phase 1 IDs corresponding to their IP addresses, and encoding those same addresses in the SubjAltName of the certificates used to authenticate the Phase 1 exchange. For more complicated scenarios, external policy (or some other mechanism) needs to be consulted, to validate the Phase 2 selectors and SA parameters. All addresses presented in Phase 2 selectors MUST be validated. That is, enough evidence must be presented to the
b) 为了使IKE能够验证阶段2选择器，必须能够在阶段1期间交换足够的信息。目前，IKE可以通过使用与其IP地址相对应的阶段1 ID，并在用于验证阶段1交换的证书的SubjectName中对这些相同的地址进行编码，直接适应两个对等方相互交谈的简单情况。对于更复杂的场景，需要咨询外部策略（或某些其他机制），以验证阶段2选择器和SA参数。必须验证第2阶段选择器中显示的所有地址。也就是说，必须向法庭提供足够的证据
Responder that the Initiator is authorized to receive traffic for all addresses that appear in the Phase 2 selectors. This evidence can be derived from the certificates exchanged during Phase 1 (if possible); otherwise it must be acquired through out-of-band means (e.g., policy mechanism, configured by the administrator, etc.).
响应程序，该启动器被授权接收阶段2选择器中出现的所有地址的通信量。该证据可从第1阶段交换的证书中得出（如果可能）；否则，必须通过带外方式（例如，策略机制、管理员配置等）获取。
In order to accommodate the same simple scenario in the context of multiple source/destination addresses in an SCTP association, it MUST be possible to:
为了在SCTP关联中的多个源/目标地址的上下文中适应相同的简单场景，必须能够：
1) Specify multiple Phase 1 IDs, which are used to validate Phase 2 parameters (in particular, the Phase 2 selectors). Following the discussion on an ID_LIST ID type, it is possible to use the same method for specifying multiple Phase 1 IDs.
1) 指定多个阶段1 ID，用于验证阶段2参数（特别是阶段2选择器）。在讨论ID_列表ID类型之后，可以使用相同的方法指定多个阶段1 ID。
2) Authenticate the various Phase 1 IDs. Using pre-shared key authentication, this is possible by associating the same shared key with all acceptable peer Phase 1 IDs. In the case of certificates, we have two alternatives:
2) 验证各个阶段1 ID。通过使用预共享密钥身份验证，可以将同一共享密钥与所有可接受的对等阶段1 ID相关联。对于证书，我们有两种选择：
a) The same certificate can contain multiple IDs encoded in the SubjAltName field, as an ASN.1 sequence. Since this is already possible, it is the preferred solution and any conformant implementations MUST support this.
a) 同一证书可以包含在SubjectName字段中编码为ASN.1序列的多个ID。因为这已经是可能的，所以它是首选的解决方案，任何一致的实现都必须支持这一点。
b) Multiple certificates MAY be passed during the Phase 1 exchange, in multiple CERT payloads. This feature is also supported by the current specification. Since only one signature may be issued per IKE Phase 1 exchange, it is necessary for all certificates to contain the same key as their Subject. However, this approach does not offer any significant advantage over (a), thus implementations MAY support it.
b) 在第1阶段交换期间，可以在多个证书有效负载中传递多个证书。当前规范也支持此功能。由于每个IKE阶段1交换只能颁发一个签名，因此所有证书都必须包含与其主题相同的密钥。然而，与（a）相比，这种方法没有任何显著的优势，因此实现可能支持它。
In either case, an IKE implementation needs to verify the validity of a peer's claimed Phase 1 ID, for all such IDs received over an exchange.
在任何一种情况下，IKE实现都需要验证对等方声明的阶段1 ID对于通过交换接收的所有此类ID的有效性。
Although SCTP does not currently support modification of the addresses associated with an SCTP association (while the latter is in use), it is a feature that may be supported in the future. Unless the set of addresses changes extremely often, it is sufficient to do a full Phase 1 and Phase 2 exchange to establish the appropriate selectors and SAs.
尽管SCTP目前不支持修改与SCTP关联（在使用SCTP关联时）相关的地址，但这是将来可能支持的功能。除非地址集极为频繁地更改，否则进行完整的第1阶段和第2阶段交换以建立适当的选择器和SA就足够了。
The last issue with respect to SCTP and IKE pertains to the initial offer of Phase 2 selectors (IDs) by the Initiator. Per the current IKE specification, the Responder must send in the second message of the Quick Mode the IDs received in the first message. Thus, it is assumed that the Initiator already knows all the Selectors relevant to this SCTP association. In most cases however, the Responder has more accurate knowledge of its various addresses. Thus, the IPsec Selectors established can be potentially insufficient or inaccurate.
关于SCTP和IKE的最后一个问题涉及发起人最初提供的第2阶段选择器（ID）。根据当前的IKE规范，响应者必须在快速模式的第二条消息中发送在第一条消息中接收到的ID。因此，假设发起方已经知道与此SCTP关联相关的所有选择器。然而，在大多数情况下，响应者对其各种地址有更准确的了解。因此，建立的IPsec选择器可能不足或不准确。
If the proposed set of Selectors is not accurate from the Responder's point of view, the latter can start a new Quick Mode exchange. In this new Quick Mode exchange, the roles of Initiator and Responder have been reversed; the new Initiator MUST copy the SA and Selectors from the old Quick Mode message, and modify its set of Selectors to match reality. All SCTP-supporting IKE implementations MUST be able to do this.
如果从响应者的角度来看，建议的选择器集不准确，后者可以启动新的快速模式交换。在这种新的快速模式交换中，发起方和响应方的角色被颠倒了；新启动器必须从旧的快速模式消息中复制SA和选择器，并修改其选择器集以符合实际情况。所有支持IKE实现的SCTP都必须能够做到这一点。
This documents discusses the use of a security protocol (IPsec) in the context of a new transport protocol (SCTP). SCTP, with its provision for mobility, opens up the possibility for traffic-redirection attacks whereby an attacker X claims that his address should be added to an SCTP session between peers A and B, and be used for further communications. In this manner, traffic between A and B can be seen by X. If X is not in the communication path between A and B, SCTP offers him new attack capabilities. Thus, all such address updates of SCTP sessions should be authenticated. Since IKE negotiates IPsec SAs for use by these sessions, IKE MUST validate all addresses attached to an SCTP endpoint either through validating the certificates presented to it during the Phase 1 exchange, or through some out-of-band method.
本文档讨论在新传输协议（SCTP）的上下文中使用安全协议（IPsec）。SCTP提供了移动性，为流量重定向攻击提供了可能性，攻击者X声称他的地址应添加到对等点A和B之间的SCTP会话中，并用于进一步通信。通过这种方式，X可以看到A和B之间的通信量。如果X不在A和B之间的通信路径中，SCTP为他提供了新的攻击能力。因此，SCTP会话的所有此类地址更新都应该经过身份验证。由于IKE协商IPsec SA以供这些会话使用，因此IKE必须通过验证在阶段1交换期间提供给它的证书或通过一些带外方法来验证附加到SCTP端点的所有地址。
The Responder in a Phase 2 exchange MUST verify the Initiator's authority to receive traffic for all addresses that appear in the Initiator's Phase 2 selectors. Not doing so would allow for any valid peer of the Responder (i.e., anyone who can successfully establish a Phase 1 SA with the Responder) to see any other valid peer's traffic by claiming their address.
阶段2交换中的响应者必须验证启动器的权限，以接收启动器的阶段2选择器中出现的所有地址的通信量。不这样做将允许响应者的任何有效对等方（即，能够成功与响应者建立阶段1 SA的任何人）通过声明其地址来查看任何其他有效对等方的流量。
IANA has assigned number 12 for ID_LIST (defined in Section 3) in the "IPSEC Identification Type" registry from the Internet Security Association and Key Management Protocol (ISAKMP) Identifiers table.
IANA已从Internet安全协会和密钥管理协议（ISAKMP）标识符表中为“IPSEC标识类型”注册表中的ID_列表（定义见第3节）分配了编号12。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Normative References
规范性引用文件
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMPD", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMPD解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schertler，M.，Schneider，M.和J.Turner，“互联网安全协会和密钥管理协议”，RFC 2408，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
Authors' Addresses
作者地址
Steven M. Bellovin AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
Steven M.Bellovin AT&T实验室-新泽西州弗洛勒姆公园公园大道180号研究中心07932-0971
Phone: +1 973 360 8656
EMail: smb@research.att.com
Phone: +1 973 360 8656
EMail: smb@research.att.com
John Ioannidis AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
John Ioannidis AT&T实验室-新泽西州弗洛勒姆公园公园大道180号研究中心07932-0971
EMail: ji@research.att.com
EMail: ji@research.att.com
Angelos D. Keromytis Columbia University, CS Department 515 CS Building 1214 Amsterdam Avenue, Mailstop 0401 New York, New York 10027-7003
Angelos D.Keromytis哥伦比亚大学CS系515 CS大楼1214号阿姆斯特丹大道邮政站0401纽约，纽约10027-7003
Phone: +1 212 939 7095
EMail: angelos@cs.columbia.edu
Phone: +1 212 939 7095
EMail: angelos@cs.columbia.edu
Randall R. Stewart 24 Burning Bush Trail. Crystal Lake, IL 60012
Randall R.Stewart 24号燃烧丛林小道。伊利诺伊州水晶湖60012
Phone: +1-815-477-2127
EMail: rrs@cisco.com
Phone: +1-815-477-2127
EMail: rrs@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。