Network Working Group G. Montenegro
Request for Comments: 3104 Sun Microsystems, Inc.
Category: Experimental M. Borella
CommWorks
October 2001
Network Working Group G. Montenegro
Request for Comments: 3104 Sun Microsystems, Inc.
Category: Experimental M. Borella
CommWorks
October 2001
RSIP Support for End-to-end IPsec
RSIP对端到端IPsec的支持
Status of this Memo
本备忘录的状况
This memo 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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
IESG Note
IESG注释
The IESG notes that the set of documents describing the RSIP technology imply significant host and gateway changes for a complete implementation. In addition, the floating of port numbers can cause problems for some applications, preventing an RSIP-enabled host from interoperating transparently with existing applications in some cases (e.g., IPsec). Finally, there may be significant operational complexities associated with using RSIP. Some of these and other complications are outlined in section 6 of the RFC 3102, as well as in the Appendices of RFC 3104. Accordingly, the costs and benefits of using RSIP should be carefully weighed against other means of relieving address shortage.
IESG指出，描述RSIP技术的一组文档意味着主机和网关的重大更改，以实现完整的实现。此外，端口号的浮动可能会导致某些应用程序出现问题，从而在某些情况下（例如，IPsec）阻止启用RSIP的主机与现有应用程序进行透明的互操作。最后，使用RSIP可能会带来巨大的操作复杂性。RFC 3102第6节以及RFC 3104附录概述了其中一些并发症和其他并发症。因此，使用RSIP的成本和收益应与其他缓解地址短缺的方法仔细权衡。
Abstract
摘要
This document proposes mechanisms that enable Realm Specific IP (RSIP) to handle end-to-end IPsec (IP Security).
本文档提出了使领域特定IP（RSIP）能够处理端到端IPsec（IP安全）的机制。
Table of Contents
目录
1. Introduction .................................................. 2
2. Model ......................................................... 2
3. Implementation Notes .......................................... 3
4. IKE Handling and Demultiplexing ............................... 4
5. IPsec Handling and Demultiplexing ............................. 5
6. RSIP Protocol Extensions ...................................... 6
6.1 IKE Support in RSIP ....................................... 6
6.2 IPsec Support in RSIP ..................................... 7
7. IANA Considerations ........................................... 10
8. Security Considerations ....................................... 10
9. Acknowledgements .............................................. 10
References ....................................................... 11
Authors' Addresses ............................................... 12
Appendix A: On Optional Port Allocation to RSIP Clients .......... 13
Appendix B: RSIP Error Numbers for IKE and IPsec Support ......... 14
Appendix C: Message Type Values for IPsec Support ................ 14
Appendix D: A Note on Flow Policy Enforcement .................... 14
Appendix E: Remote Host Rekeying ................................. 14
Appendix F: Example Application Scenarios ........................ 15
Appendix G: Thoughts on Supporting Incoming Connections .......... 17
Full Copyright Statement ......................................... 19
1. Introduction .................................................. 2
2. Model ......................................................... 2
3. Implementation Notes .......................................... 3
4. IKE Handling and Demultiplexing ............................... 4
5. IPsec Handling and Demultiplexing ............................. 5
6. RSIP Protocol Extensions ...................................... 6
6.1 IKE Support in RSIP ....................................... 6
6.2 IPsec Support in RSIP ..................................... 7
7. IANA Considerations ........................................... 10
8. Security Considerations ....................................... 10
9. Acknowledgements .............................................. 10
References ....................................................... 11
Authors' Addresses ............................................... 12
Appendix A: On Optional Port Allocation to RSIP Clients .......... 13
Appendix B: RSIP Error Numbers for IKE and IPsec Support ......... 14
Appendix C: Message Type Values for IPsec Support ................ 14
Appendix D: A Note on Flow Policy Enforcement .................... 14
Appendix E: Remote Host Rekeying ................................. 14
Appendix F: Example Application Scenarios ........................ 15
Appendix G: Thoughts on Supporting Incoming Connections .......... 17
Full Copyright Statement ......................................... 19
This document specifies RSIP extensions to enable end-to-end IPsec. It assumes the RSIP framework as presented in [RSIP-FW], and specifies extensions to the RSIP protocol defined in [RSIP-P]. Other terminology follows [NAT-TERMS].
本文档指定用于启用端到端IPsec的RSIP扩展。它假定RSIP框架如[RSIP-FW]中所示，并指定对[RSIP-P]中定义的RSIP协议的扩展。其他术语如下[NAT-TERMS]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
For clarity, the discussion below assumes this model:
为清楚起见，以下讨论假设此模型：
RSIP client RSIP server Host
RSIP客户端RSIP服务器主机
Xa Na Nb Yb
+------------+ Nb1 +------------+
[X]------| Addr space |----[N]-----| Addr space |-------[Y]
| A | Nb2 | B |
+------------+ ... +------------+
Xa Na Nb Yb
+------------+ Nb1 +------------+
[X]------| Addr space |----[N]-----| Addr space |-------[Y]
| A | Nb2 | B |
+------------+ ... +------------+
Hosts X and Y belong to different address spaces A and B, respectively, and N is an RSIP server. N has two addresses: Na on address space A, and Nb on address space B. For example, A could be a private address space, and B the public address space of the general Internet. Additionally, N may have a pool of addresses in address space B which it can assign to or lend to X.
主机X和Y分别属于不同的地址空间A和B，而N是一个RSIP服务器。N有两个地址：地址空间A上的Na和地址空间B上的Nb。例如，A可以是专用地址空间，B是通用Internet的公共地址空间。此外，N可以在地址空间B中有一个地址池，它可以分配给X或借出给X。
This document proposes RSIP extensions and mechanisms to enable an RSIP client X to initiate IKE and IPsec sessions to a legacy IKE and IPsec node Y. In order to do so, X exchanges RSIP protocol messages with the RSIP server N. This document does not yet address IKE/IPsec session initiation from Y to an RSIP client X. For some thoughts on this matter see Appendix G.
本文档提出了RSIP扩展和机制，以使RSIP客户端X能够启动到传统IKE和IPsec节点Y的IKE和IPsec会话。为此，X与RSIP服务器N交换RSIP协议消息。本文档尚未说明从Y到RSIP客户端X的IKE/IPsec会话启动。有关此问题的一些想法，请参阅附录G。
The discussion below assumes that the RSIP server N is examining a packet sent by Y, destined for X. This implies that "source" refers to Y and "destination" refers to Y's peer, namely, X's presence at N.
下面的讨论假设RSIP服务器N正在检查由Y发送的、目的地为X的数据包。这意味着“源”指Y，“目的地”指Y的对等方，即X在N处的存在。
This document assumes the use of the RSAP-IP flavor of RSIP (except that port number assignments are optional), on top of which SPI values are used for demultiplexing. Because of this, more than one RSIP client may share the same global IP address.
本文档假设使用RSIP的RSAP-IP风格（端口号分配是可选的除外），除此之外，SPI值用于解复用。因此，多个RSIP客户端可能共享同一全局IP地址。
The RSIP server N is not required to have more than one address on address space B. RSIP allows X (and any other hosts on address space A) to reuse Nb. Because of this, Y's SPD SHOULD NOT be configured to support address-based keying. Address-based keying implies that only one RSIP client may, at any given point in time, use address Nb when exchanging IPsec packets with Y. Instead, Y's SPD SHOULD be configured to support session-oriented keying, or user-oriented keying [Kent98c]. In addition to user-oriented keying, other types of identifications within the IKE Identification Payload are equally effective at disambiguating who is the real client behind the single address Nb [Piper98].
RSIP服务器N不需要在地址空间B上有多个地址。RSIP允许X（以及地址空间A上的任何其他主机）重用Nb。因此，Y的SPD不应配置为支持基于地址的键控。基于地址的键控意味着在任何给定时间点，只有一个RSIP客户端可以在与Y交换IPsec数据包时使用地址Nb。相反，Y的SPD应配置为支持面向会话的键控或面向用户的键控[C]。除了面向用户的键控之外，IKE标识有效载荷中的其他类型的标识在消除谁是单地址Nb后面的真正客户机方面同样有效[Piper98]。
Because it cannot rely on address-based keying, RSIP support for IPsec is similar to the application of IPsec for remote access using dynamically assigned addresses. Both cases impose additional requirements which are not met by minimally compliant IPsec implementations [Gupta]:
因为它不能依赖基于地址的密钥，所以对IPsec的RSIP支持类似于IPsec的应用程序，用于使用动态分配的地址进行远程访问。这两种情况都会带来额外的要求，这些要求是最低限度兼容的IPsec实现[Gupta]无法满足的：
Note that a minimally-compliant IKE implementation (which only implements Main mode with Pre-shared keys for Phase I authentication) cannot be used on a remote host with a dynamically assigned address. The IKE responder (gateway) needs to look up the initiator's (mobile node's) pre-shared key before it can
请注意，在具有动态分配地址的远程主机上，不能使用符合最低要求的IKE实现（它仅使用阶段I身份验证的预共享密钥实现主模式）。IKE响应程序（网关）需要先查找启动器（移动节点）的预共享密钥，然后才能启动
decrypt the latter's third main mode message (fifth overall in Phase I). Since the initiator's identity is contained in the encrypted message, only its IP address is available for lookup and must be predictable. Other options, such as Main mode with digital signatures/RSA encryption and Aggressive mode, can accommodate IKE peers with dynamically assigned addresses.
解密后者的第三个主模式消息（第五个在第一阶段）。由于启动器的标识包含在加密消息中，因此只有其IP地址可用于查找，并且必须是可预测的。其他选项，如带有数字签名/RSA加密的主模式和主动模式，可以容纳具有动态分配地址的IKE对等方。
IKE packets are typically carried on UDP port 500 for both source and destination, although the use of ephemeral source ports is not precluded [ISAKMP]. IKE implementations for use with RSIP SHOULD employ ephemeral ports, and should handle them as follows [IPSEC-MSG]:
IKE数据包通常在源和目标的UDP端口500上携带，但并不排除使用临时源端口[ISAKMP]。用于RSIP的IKE实现应使用临时端口，并应按如下方式处理[IPSEC-MSG]：
IKE implementations MUST support UDP port 500 for both source and destination, but other port numbers are also allowed. If an implementation allows other-than-port-500 for IKE, it sets the value of the port numbers as reported in the ID payload to 0 (meaning "any port"), instead of 500. UDP port numbers (500 or not) are handled by the common "swap src/dst port and reply" method.
IKE实现必须支持源和目标的UDP端口500，但也允许使用其他端口号。如果实现允许IKE使用非端口500，则将ID有效负载中报告的端口号的值设置为0（表示“任何端口”），而不是500。UDP端口号（500或不500）由通用的“交换src/dst端口和应答”方法处理。
It is important to note that IPsec implementations MUST be aware of RSIP, at least in some peripheral sense, in order to receive assigned SPIs and perhaps other parameters from an RSIP client. Therefore, bump-in-the-stack (BITS) implementations of IPsec are not expected to work "out of the box" with RSIP.
需要注意的是，IPsec实现必须了解RSIP，至少在某些外围意义上是这样，以便从RSIP客户端接收分配的SPI和其他参数。因此，IPsec的栈中凹凸（BITS）实现预计不会在RSIP中“开箱即用”。
If an RSIP client requires the use of port 500 as its IKE source, this prevents that field being used for demultiplexing. Instead, the "Initiator Cookie" field in the IKE header fields must be used for this purpose. This field is appropriate as it is guaranteed to be present in every IKE exchange (Phase 1 and Phase 2), and is guaranteed to be in the clear (even if subsequent IKE payloads are encrypted). However, it is protected by the Hash payload in IKE [IKE]. Because of this, an RSIP client and server must agree upon a valid value for the Initiator Cookie.
如果RSIP客户端要求使用端口500作为其IKE源，这将阻止该字段用于解复用。相反，IKE头字段中的“启动器Cookie”字段必须用于此目的。此字段是合适的，因为它保证出现在每个IKE交换（阶段1和阶段2）中，并且保证处于清除状态（即使后续IKE有效负载被加密）。但是，它受到IKE[IKE]中的哈希有效负载的保护。因此，RSIP客户端和服务器必须就启动器Cookie的有效值达成一致。
Once X and N arrive at a mutually agreeable value for the Initiator Cookie, X uses it to create an IKE packet and tunnels it the RSIP server N. N decapsulates the IKE packet and sends it on address space B.
一旦X和N为发起方Cookie确定了一个双方都同意的值，X就使用它来创建一个IKE数据包，并通过隧道传输给RSIP服务器N。N将IKE数据包解封并发送到地址空间B。
The minimum tuple negotiated via RSIP, and used for demultiplexing incoming IKE responses from Y at the RSIP server N, is:
通过RSIP协商的最小元组，用于在RSIP服务器N上解复用来自Y的传入IKE响应，为：
- IKE destination port number
- IKE目标端口号
- Initiator Cookie
- 启动器Cookie
- Destination IP address
- 目标IP地址
One problem still remains: how does Y know that it is supposed to send packets to X via Nb? Y is not RSIP-aware, but it is definitely IKE-aware. Y sees IKE packets coming from address Nb. To prevent Y from mistakenly deriving the identity of its IKE peer based on the source address of the packets (Nb), X MUST exchange client identifiers with Y:
仍然存在一个问题：Y如何知道它应该通过Nb向X发送数据包？Y不知道RSIP，但它肯定知道IKE。Y看到来自地址Nb的IKE数据包。为了防止Y根据数据包的源地址（Nb）错误地导出其IKE对等方的标识，X必须与Y交换客户端标识符：
- IDii, IDir if in Phase 1, and
- IDii，如果在第1阶段，IDir，以及
- IDci, IDcr if in Phase 2.
- IDci、IDcr（如果在第2阶段）。
The proper use of identifiers allows the clear separation between those identities and the source IP address of the packets.
标识符的正确使用允许在这些标识和数据包的源IP地址之间进行清晰的分离。
The RSIP client X and server N must arrive at an SPI value to denote the incoming IPsec security association from Y to X. Once N and X make sure that the SPI is unique within both of their SPI spaces, X communicates its value to Y as part of the IPsec security association establishment process, namely, Quick Mode in IKE [IKE] or manual assignment.
RSIP客户端X和服务器N必须达到一个SPI值，以表示从Y到X的传入IPsec安全关联。一旦N和X确保SPI在两个SPI空间内都是唯一的，X将其值作为IPsec安全关联建立过程的一部分传递给Y，即IKE[IKE]中的快速模式或手动分配。
This ensures that Y sends IPsec packets (protocols 51 and 50 for AH and ESP, respectively) [Kent98a,Kent98b] to X via address Nb using the negotiated SPI.
这确保Y使用协商的SPI通过地址Nb向X发送IPsec数据包（分别针对AH和ESP的协议51和50）[Kent98a，Kent98b]。
IPsec packets from Y destined for X arrive at RSIP server N. They are demultiplexed based on the following minimum tuple of demultiplexing fields:
从Y发送到X的IPsec数据包到达RSIP服务器N。这些数据包根据以下解复用字段的最小元组进行解复用：
- protocol (50 or 51)
- 议定书（50或51）
- SPI
- SPI
- destination IP address
- 目标IP地址
If N is able to find a matching mapping, it tunnels the packet to X according to the tunneling mode in effect. If N cannot find an appropriate mapping, it MUST discard the packet.
如果N能够找到匹配的映射，它将根据有效的隧道模式将数据包隧道到X。如果N找不到合适的映射，它必须丢弃该数据包。
The next two sections specify how the RSIP protocol [RSIP-P] is extended to support both IKE (a UDP application) and the IPsec-defined AH and ESP headers (layered directly over IP with their own protocol numbers).
接下来的两部分将指定如何扩展RSIP协议[RSIP-P]，以支持IKE（UDP应用程序）和IPsec定义的AH和ESP头（通过IP直接分层，并使用各自的协议编号）。
If a server implements RSIP support for IKE and IPsec as defined in this document, it MAY include the RSIP Method parameter for RSIP with IPsec in the REGISTER_RESPONSE method sent to the client. This method is assigned a value of 3:
如果服务器实现了本文档中定义的对IKE和IPsec的RSIP支持，则可能会在发送给客户端的REGISTER_响应方法中包含RSIP Method参数，用于RSIP with IPsec。此方法的值为3：
3 RSIP with IPsec (RSIPSEC)
3带IPsec的RSIP（RSIPSEC）
Unless otherwise specified, requirements of micro and macro flow-based policy are handled according to [RSIP-P].
除非另有规定，基于微观和宏观流量的政策要求按照[RSIP-P]处理。
As discussed above, if X's IPsec implementation allows use of an ephemeral source port for IKE, then incoming IKE traffic can be demultiplexed by N based on the destination address and port tuple. This is the simplest and most desirable way of supporting IKE, and IPsec implementations that interact with RSIP SHOULD allow it.
如上所述，如果X的IPsec实现允许为IKE使用临时源端口，则传入的IKE通信量可以根据目标地址和端口元组由N进行解复用。这是支持IKE的最简单和最理想的方式，与RSIP交互的IPsec实现应该允许这样做。
However, if X must use source port 500 for IKE, there are two techniques with which X and N can arrive at a mutually unique Initiator Cookie.
然而，如果X必须为IKE使用源端口500，则有两种技术可用于X和N获得相互唯一的启动器Cookie。
- Trial and error.
- 反复试验。
- Negotiation via an extension of the RSIP protocol.
- 通过RSIP协议的扩展进行协商。
The trial and error technique consists of X first obtaining resources with which to use IPsec (via ASSIGN_REQUEST_RSIPSEC, defined below), and then randomly choosing an Initiator Cookie and transmitting the first packet to Y. Upon arrival at N, the RSIP server examines the Initiator Cookie for uniqueness per X's assigned address (Nb). If the cookie is unique, N allows the use of this cookie for this an all subsequent packets between X and Y on this RSIP binding. If the cookie is not unique, N drops the packet.
试错技术包括X首先获取使用IPsec的资源（通过下文定义的ASSIGN_REQUEST_RSIPSEC），然后随机选择启动器Cookie并将第一个数据包发送给Y。到达N后，RSIP服务器根据X的分配地址（Nb）检查启动器Cookie的唯一性。如果cookie是唯一的，则N允许将此cookie用于此RSIP绑定上X和Y之间的所有后续数据包。如果cookie不是唯一的，则N丢弃数据包。
When an IKE packet is determined to be lost, the IKE client will attempt to retransmit at least three times [IKE]. An RSIP-aware IKE client SHOULD use different Initiator Cookies for each of these retransmissions.
当确定IKE数据包丢失时，IKE客户端将尝试至少三次重传[IKE]。支持RSIP的IKE客户端应该为每个重传使用不同的启动器cookie。
The probability of an Initiator Cookie collision at N and subsequent retransmissions by X, is infinitesimal given the 64-bit cookie space. According to the birthday paradox, in a population of 640 million RSIP clients going through the same RSIP server, the chances of a first collision is just 1%. Thus, it is desirable to use the trial and error method over negotiation, for these reasons:
给定64位Cookie空间，在N处发起方Cookie冲突并随后通过X重新传输的概率是无穷小的。根据生日悖论，在通过同一台RSIP服务器的6.4亿RSIP客户机中，第一次碰撞的几率只有1%。因此，出于以下原因，最好在谈判中使用试错法：
- Simpler implementation requirements
- 更简单的实现要求
- It is highly unlikely that more than one round trip between X and N will be necessary.
- X和N之间不太可能需要一次以上的往返。
This section defines the protocol extensions required for RSIP to support AH and ESP. The required message types are ASSIGN_REQUEST_RSIPSEC and ASSIGN_RESPONSE_RSIPSEC:
本节定义RSIP支持AH和ESP所需的协议扩展。所需的消息类型为ASSIGN_REQUEST_RSIPSEC和ASSIGN_RESPONSE_RSIPSEC：
ASSIGN_REQUEST_RSIPSEC
分配请求
The ASSIGN_REQUEST_RSIPSEC message is used by an RSIP client to request IPsec parameter assignments. An RSIP client MUST request an IP address and SPIs in one message.
RSIP客户端使用ASSIGN_REQUEST_RSIPSEC消息请求IPsec参数分配。RSIP客户端必须在一条消息中请求IP地址和SPI。
If the RSIP client wishes to use IPsec to protect a TCP or UDP application, it MUST use the port range parameter (see Appendix A). Otherwise, it MUST set the port parameters to the "don't need" value. This is accomplished by setting the length field to 0, and by omitting both the number field and the port field. This informs the server that the client does not actually need any port assignments.
如果RSIP客户端希望使用IPsec保护TCP或UDP应用程序，则必须使用端口范围参数（参见附录a）。否则，它必须将端口参数设置为“不需要”值。这是通过将长度字段设置为0，并省略数字字段和端口字段来实现的。这会通知服务器客户端实际上不需要任何端口分配。
The client may initialize the SPI parameter to the "don't care" value (see below). In this case, it is requesting the server to assign it a valid SPI value to use.
客户端可以将SPI参数初始化为“不在乎”值（见下文）。在这种情况下，它请求服务器为其分配一个要使用的有效SPI值。
Alternatively, the client may initialize the SPI parameter to a value it considers valid. In this case, it is suggesting that value to the server. Of course, the server may choose to reject that suggestion and return an appropriate error message.
或者，客户端可以将SPI参数初始化为它认为有效的值。在本例中，它向服务器建议该值。当然，服务器可以选择拒绝该建议并返回适当的错误消息。
The format of this message is:
此消息的格式为：
<ASSIGN_REQUEST_RSIPSEC> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<SPI>
[Message Counter]
[Lease Time]
[Tunnel Type]
<ASSIGN_REQUEST_RSIPSEC> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<SPI>
[Message Counter]
[Lease Time]
[Tunnel Type]
The following message-specific error conditions exist. The error behavior of ASSIGN_REQUEST_RSIP_IPSEC follows that of ASSIGN_REQUEST_RSAP-IP for all non-IPsec errors.
存在以下特定于消息的错误情况。对于所有非IPSEC错误，ASSIGN_REQUEST_RSIP_IPSEC的错误行为遵循ASSIGN_REQUEST_RSAP-IP的错误行为。
- If the client is not allowed to use IPsec through the server, the server MUST respond with an ERROR_RESPONSE containing the IPSEC_UNALLOWED parameter.
- 如果不允许客户端通过服务器使用IPsec，则服务器必须以包含IPsec\u UNALLOWED参数的错误\u响应进行响应。
- If the SPI parameter is a "don't care" value and the RSIP server cannot allocate ANY SPIs, the RSIP server MUST respond with an ERROR_RESPONSE containing the IPSEC_SPI_UNAVAILABLE error.
- 如果SPI参数是“不关心”值，并且RSIP服务器无法分配任何SPI，则RSIP服务器必须使用包含IPSEC_SPI_不可用错误的错误_响应进行响应。
- If an SPI parameter is not a "don't care" value and the RSIP server cannot allocate it because the requested address and SPI tuple is in use, the RSIP server MUST respond with an ERROR_RESPONSE containing the IPSEC_SPI_INUSE error.
- 如果SPI参数不是“不关心”值，并且由于请求的地址和SPI元组正在使用，RSIP服务器无法分配该参数，则RSIP服务器必须使用包含IPSEC_SPI_使用错误的错误_响应进行响应。
ASSIGN_RESPONSE_RSIPSEC
分配\u响应\u RSIPSEC
The ASSIGN_RESPONSE_RSIPSEC message is used by an RSIP server to assign parameters to an IPsec-enabled RSIP client.
RSIP服务器使用ASSIGN_RESPONSE_RSIPSEC消息为启用IPsec的RSIP客户端分配参数。
The format of this message is:
此消息的格式为：
<ASSIGN_RESPONSE_RSIPSEC> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<SPI>
<Lease Time>
<Tunnel Type>
[Address (tunnel endpoint)]
[Message Counter]
<ASSIGN_RESPONSE_RSIPSEC> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<SPI>
<Lease Time>
<Tunnel Type>
[Address (tunnel endpoint)]
[Message Counter]
If the port parameters were set to the "don't need" value in the request (see above), the RSIP server must do the same in the response.
如果端口参数在请求中设置为“不需要”值（参见上文），RSIP服务器必须在响应中执行相同的操作。
Additionally, RSIP support for IPsec requires the following new parameter:
此外，对IPsec的RSIP支持需要以下新参数：
SPI
Code Length Number SPI SPI
+------+--------+---------+---------+ +---------+
| 22 | 2 | 2 bytes | 4 bytes | ... | 4 bytes |
+------+--------+---------+---------+ +---------+
SPI
Code Length Number SPI SPI
+------+--------+---------+---------+ +---------+
| 22 | 2 | 2 bytes | 4 bytes | ... | 4 bytes |
+------+--------+---------+---------+ +---------+
Sent by the RSIP client in ASSIGN_REQUEST_RSIPSEC messages to ask for a particular number of SPIs to be assigned. Also sent by the RSIP server to the client in ASSIGN_RESPONSE_RSIPSEC messages.
由RSIP客户端在ASSIGN_REQUEST_RSIPSEC消息中发送，请求分配特定数量的SPI。也由RSIP服务器在ASSIGN_RESPONSE_RSIPSEC消息中发送给客户端。
The "SPI" fields encode one or more SPIs. When a single SPI is specified, the value of the number field is 1 and there is one SPI field following the number field. When more than one SPI is specified, the value of the number field will indicate the total number of SPIs contained, and the parameter may take one of two forms. If there is one SPI field, the SPIs specified are considered to be contiguous starting at the SPI number specified in the SPI field. Alternatively, there may be a number of SPI fields equal to the value of the number field. The number of SPI fields can be extrapolated from the value of the length field.
“SPI”字段对一个或多个SPI进行编码。指定单个SPI时，数字字段的值为1，数字字段后面有一个SPI字段。当指定了多个SPI时，数字字段的值将指示包含的SPI总数，参数可以采用两种形式之一。如果有一个SPI字段，则指定的SPI从SPI字段中指定的SPI编号开始视为连续。或者，可能存在与数字字段的值相等的多个SPI字段。SPI字段的数量可以从长度字段的值推断出来。
In some cases, it is necessary to specify a "don't care" value for one or more SPIs. This is accomplished by setting the length field to 2 (to account for the 2 bytes in the Number field), setting the number field to the number of SPIs necessary, and omitting all SPI fields. The value of the number field MUST be greater than or equal to one.
在某些情况下，有必要为一个或多个SPI指定“不在乎”值。这是通过将长度字段设置为2（以说明数字字段中的2个字节）、将数字字段设置为所需的SPI数并省略所有SPI字段来实现的。数字字段的值必须大于或等于1。
All of the designations below are tentative.
以下所有名称均为暂定名称。
- RSIP IPsec error codes (see below).
- RSIP IPsec错误代码（见下文）。
- ASSIGN_REQUEST_RSIP_IPSEC message type code.
- 分配\u请求\u RSIP\u IPSEC消息类型代码。
- SPI parameter code.
- SPI参数代码。
This document does not add any security issues to those already posed by NAT, or normal routing operations. Current routing decisions typically are based on a tuple with only one element: destination IP address. This document just adds more elements to the tuple.
本文档不会将任何安全问题添加到NAT或正常路由操作已经造成的问题上。当前路由决策通常基于只有一个元素的元组：目标IP地址。本文档只是向元组添加了更多元素。
Furthermore, by allowing an end-to-end mode of operation and by introducing a negotiation phase to address reuse, the mechanisms described here are more secure and less arbitrary than NAT.
此外，通过允许端到端的操作模式并引入协商阶段来解决重用问题，这里描述的机制比NAT更安全，也更少随意性。
A word of caution is in order: SPI values are meant to be semi-random, and, thus serve also as anti-clogging tokens to reduce off-the-path denial-of-service attacks. However, RSIP support for IPsec, renders SPI's a negotiated item: in addition to being unique values at the receiver X, they must also be unique at the RSIP server, N. Limiting the range of the SPI values available to the RSIP clients reduces their entropy slightly.
需要注意的是：SPI值是半随机的，因此也可以用作防阻塞令牌，以减少路径外拒绝服务攻击。但是，RSIP对IPsec的支持使SPI成为一个协商项目：除了在接收器X上是唯一的值外，它们在RSIP服务器上也必须是唯一的，N。限制RSIP客户端可用的SPI值的范围稍微降低了它们的熵。
Many thanks to Bernard Aboba, Vipul Gupta, Jeffrey Lo, Dan Nessett, Gary Jaszewski and Prakash Iyer for helpful discussions.
非常感谢Bernard Aboba、Vipul Gupta、Jeffrey Lo、Dan Nessett、Gary Jaszewski和Prakash Iyer进行了有益的讨论。
References
工具书类
[Gupta] Gupta, V., "Secure Remote Access over the Internet using IPSec", Work in Progress.
[Gupta]Gupta，V.，“使用IPSec在互联网上实现安全远程访问”，正在进行中。
[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月。
[IPSEC-MSG] Ted Ts'o, message to the IETF's IPsec mailing list, Message-Id:<199911232216.RAA01932@trampoline.thunk.org>, November 23, 1999.
[IPSEC-MSG]Ted Ts'o，发送给IETF的IPSEC邮件列表的消息，消息Id:<199911232216。RAA01932@trampoline.thunk.org>，一九九九年十一月二十三日。
[Jenkins] Jenkins, T., "IPsec Rekeying Issues", Work in Progress.
[Jenkins]Jenkins，T.，“IPsec密钥更新问题”，正在进行中。
[Kent98a] Kent, S. and R. Atkinson, "IP Encapsulating Payload", RFC 2406, November 1998.
[Kent98a]Kent，S.和R.Atkinson，“IP封装有效载荷”，RFC 2406，1998年11月。
[Kent98b] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[Kent98b]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[Kent98c] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[Kent98c]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[Piper98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[Piper98]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[NAPT] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAPT]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 30222001年1月。
[NAT-TERMS] Srisuresh, P. and M. Holdredge, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT术语]Srisuresh，P.和M.Holdredge，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RSIP-FW] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: A Framework", RFC 3102, October 2001.
[RSIP-FW]Borella，M.，Lo，J.，Grabelsky，D.和G.黑山，“特定领域知识产权：框架”，RFC 3102，2001年10月。
[RSIP-P] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
[RSIP-P]Borella，M.，Grabelsky，D.，Lo，J.和K.Taniguchi，“领域特定IP：协议规范”，RFC 3103，2001年10月。
Authors' Addresses
作者地址
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
加布里埃尔E.黑山太阳微系统实验室，欧洲29号，法国墨西哥chemin du Vieux Chene 38240
Phone: +33 476 18 80 45
EMail: gab@sun.com
Phone: +33 476 18 80 45
EMail: gab@sun.com
Michael Borella CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
伊利诺伊州Rolling Meadows高尔夫路3800号Michael Borella CommWorks 60008
Phone: (847) 262-3083 EMail: mike_borella@commworks.com
电话：（847）262-3083电子邮件：迈克_borella@commworks.com
Appendix A: On Optional Port Allocation to RSIP Clients
附录A：RSIP客户端的可选端口分配
Despite the fact that SPIs rather than ports are used to demultiplex packets at the RSIP server, the RSIP server may still allocate mutually exclusive port numbers to the RSIP clients. If this does not happen, there is the possibility that two RSIP clients using the same IP address attempt an IPsec session with the same server using the same source port numbers.
尽管在RSIP服务器上使用SPI而不是端口来解复用数据包，但RSIP服务器仍然可以向RSIP客户端分配互斥的端口号。如果未发生这种情况，则有可能两个使用相同IP地址的RSIP客户端尝试使用相同的源端口号与同一服务器进行IPsec会话。
+-------------+
| RSIP client |
| X1 +--+
| | | +-------------+
+-------------+ | | |Nb
+---------+ RSIP server +----------------
+-------------+ | | N |
| RSIP client | | +-------------+
| X2 +--+ private public
| | | network network
+-------------+ |
|
|
+-------------+
| RSIP client |
| X1 +--+
| | | +-------------+
+-------------+ | | |Nb
+---------+ RSIP server +----------------
+-------------+ | | N |
| RSIP client | | +-------------+
| X2 +--+ private public
| | | network network
+-------------+ |
|
|
For example, consider hosts X1 and X2 depicted above. Assume that they both are using public address Nb, and both are contacting an external server Y at port 80. If they are using IPsec but are not allocated mutually exclusive port numbers, they may both choose the same ephemeral port number to use when contacting Y at port 80. Assume client X1 does so first, and after engaging in an IKE negotiation begins communicating with the public server using IPsec.
例如，考虑上面描述的主机X1和X2。假设他们都在使用公共地址Nb，并且都在与端口80处的外部服务器Y联系。如果它们正在使用IPsec，但未分配互斥的端口号，则在端口80处与Y联系时，它们都可以选择相同的临时端口号。假设客户机X1首先这样做，在参与IKE协商之后，开始使用IPsec与公共服务器通信。
When Client X2 starts its IKE session, it sends its identification to the public server. The latter's SPD requires that different identities use different flows (port numbers). Because of this, the IKE negotiation will fail. Client X2 will be forced to try another ephemeral port until it succeeds in obtaining one which is currently not in use by any other security association between the public server and any of the RSIP clients in the private network.
当客户机X2启动其IKE会话时，它将其标识发送到公共服务器。后者的SPD要求不同的身份使用不同的流（端口号）。因此，IKE谈判将失败。客户端X2将被迫尝试另一个临时端口，直到它成功获得一个当前未被公共服务器和专用网络中任何RSIP客户端之间的任何其他安全关联使用的端口。
Each such iteration is costly in terms of round-trip times and CPU usage. Hence --and as a convenience to its RSIP clients--, an RSIP server may also assign mutually exclusive port numbers to its IPsec RSIP clients.
就往返时间和CPU使用而言，每次这样的迭代都是昂贵的。因此，为了方便RSIP客户端，RSIP服务器还可以为其IPsec RSIP客户端分配互斥的端口号。
Despite proper allocation of port numbers, an RSIP server cannot prevent their misuse because it cannot examine the port fields in packets that have been encrypted by the RSIP clients. Presumably, if the RSIP clients have gone through the trouble of negotiating ports numbers, it is in their best interest to adhere to these assignments.
尽管正确分配了端口号，但RSIP服务器无法防止其误用，因为它无法检查已由RSIP客户端加密的数据包中的端口字段。据推测，如果RSIP客户已经经历了谈判端口号的麻烦，那么遵守这些分配符合他们的最佳利益。
Appendix B: RSIP Error Numbers for IKE and IPsec Support
附录B:IKE和IPsec支持的RSIP错误号
This section provides descriptions for the error values in the RSIP error parameter beyond those defined in [RSIP-P].
本节提供了RSIP error参数中超出[RSIP-P]中定义的错误值的说明。
401: IPSEC_UNALLOWED. The server will not allow the client to use end-to-end IPsec.
401:IPSEC_不允许。服务器将不允许客户端使用端到端IPsec。
402: IPSEC_SPI_UNAVAILABLE. The server does not have an SPI available for client use.
402:IPSEC\u SPI\u不可用。服务器没有可供客户端使用的SPI。
403: IPSEC_SPI_INUSE. The client has requested an SPI that another client is currently using.
403:IPSEC\u SPI\u使用。客户端已请求另一客户端当前正在使用的SPI。
Appendix C: Message Type Values for IPsec Support
附录C：IPsec支持的消息类型值
This section defines the values assigned to RSIP message types beyond those defined in [RSIP-P].
本节定义了分配给RSIP消息类型的值，这些值超出了[RSIP-P]中定义的值。
22 ASSIGN_REQUEST_RSIPSEC
22分配请求
23 ASSIGN_RESPONSE_RSIPSEC
23分配\u响应\u RSIPSEC
Appendix D: A Note on Flow Policy Enforcement
附录D：关于流动政策实施的说明
An RSIP server may not be able to enforce local or remote micro-flow policy when a client uses ESP for end-to-end encryption, since all TCP/UDP port numbers will be encrypted. However, if AH without ESP is used, micro-flow policy is enforceable. Macro-flow policy will always be enforceable.
当客户端使用ESP进行端到端加密时，RSIP服务器可能无法实施本地或远程微流策略，因为所有TCP/UDP端口号都将加密。但是，如果使用不带ESP的AH，则可以执行微流量政策。宏观流动政策始终是可执行的。
Appendix E: Remote Host Rekeying
附录E：远程主机密钥更新
Occasionally, a remote host with which an RSIP client has established an IPsec security association (SA) will rekey [Jenkins]. SA rekeying is only an issue for RSIP when IKE port 500 is used by the client and the rekey is of ISAKMP phase 1 (the ISAKMP SA). The problem is that the remote host will transmit IKE packets to port 500 with a new initiator cookie. The RSIP server will not have a mapping for the cookie, and SHOULD drop the the packets. This will cause the ISAKMP
有时，RSIP客户端与之建立IPsec安全关联（SA）的远程主机将重新注册[Jenkins]。当客户端使用IKE端口500且重新密钥处于ISAKMP阶段1（ISAKMP SA）时，SA密钥更新仅是RSIP的一个问题。问题是远程主机将使用新的启动器cookie将IKE数据包发送到端口500。RSIP服务器将没有cookie的映射，应该删除数据包。这将导致ISAKMP
SA between the RSIP client and remote host to be deleted, and may lead to undefined behavior given that current implementations handle rekeying in a number of different ways.
RSIP客户端和远程主机之间的SA将被删除，并且可能导致未定义的行为，因为当前的实现以多种不同的方式处理密钥更新。
If the RSIP client uses an ephemeral source port, rekeying will not be an issue for RSIP. If this cannot be done, there are a number of RSIP client behaviors that may reduce the number of occurrences of this problem, but are not guaranteed to eliminate it.
如果RSIP客户端使用临时源端口，则RSIP不会出现密钥更新问题。如果无法做到这一点，则有许多RSIP客户端行为可能会减少此问题的发生次数，但不能保证消除它。
- The RSIP client's IKE implementation is given a smaller ISAKMP SA lifetime than is typically implemented. This would likely cause the RSIP client to rekey the ISAKMP SA before the remote host. Since the RSIP client chooses the Initiator Cookie, there will be no problem routing incoming traffic at the RSIP server.
- RSIP客户端的IKE实现比通常实现的ISAKMP SA生存期更小。这可能会导致RSIP客户端在远程主机之前重新设置ISAKMP SA的密钥。由于RSIP客户端选择启动器Cookie，因此在RSIP服务器上路由传入流量不会有问题。
- The RSIP client terminates the ISAKMP SA as soon as the first IPsec SA is established. This may alleviate the situation to some degree if the SA is coarse-grained. On the other hand, this exacerbates the problem if the SA is fine-grained (such that it cannot be reused by other application-level connections), and the remote host needs to initialize sockets back to the RSIP client.
- RSIP客户端在建立第一个IPsec SA后立即终止ISAKMP SA。如果SA是粗粒度的，这可能会在一定程度上缓解这种情况。另一方面，如果SA是细粒度的（因此不能被其他应用程序级连接重用），并且远程主机需要将套接字初始化回RSIP客户端，则这会加剧问题。
Note that the unreliability of UDP essentially makes the ephemeral source approach the only robust solution.
请注意，UDP的不可靠性本质上使临时源成为唯一可靠的解决方案。
Appendix F: Example Application Scenarios
附录F：示例应用场景
This section briefly describes some examples of how RSIP may be used to enable applications of IPsec that are otherwise not possible.
本节简要介绍了如何使用RSIP启用IPsec应用程序的一些示例，这些应用程序在其他情况下是不可能实现的。
The SOHO (small office, home office) scenario
---------------------------------------------
The SOHO (small office, home office) scenario
---------------------------------------------
+----------+
|RSIP |
|client X1 +--+
| | | +-------------+ +-------+
+----------+ | |NAPT gateway | |public |
+--+ and +--.......---+IPsec |
+----------+ | |RSIP server | |peer Y |
|RSIP | | +-------------+ +-------+
|client X2 +--+ private public
| | | "home" Internet
+----------+ | network
|
|
+----------+
|RSIP |
|client X1 +--+
| | | +-------------+ +-------+
+----------+ | |NAPT gateway | |public |
+--+ and +--.......---+IPsec |
+----------+ | |RSIP server | |peer Y |
|RSIP | | +-------------+ +-------+
|client X2 +--+ private public
| | | "home" Internet
+----------+ | network
|
|
Suppose the private "home" network is a small installation in somebody's home, and that the RSIP clients X1 and X2 must use the RSIP server N as a gateway to the outside world. N is connected via an ISP and obtains a single address which must be shared by its clients. Because of this, N has NAPT, functionality. Now, X1 wishes to establish an IPsec SA with peer Y. This is possible because N is also an RSIP server augmented with the IPsec support defined in this document. Y is IPsec-capable, but is not RSIP aware. This is perhaps the most typical application scenario.
假设私有“家庭”网络是某人家中的一个小装置，RSIP客户端X1和X2必须使用RSIP服务器N作为通向外部世界的网关。N通过ISP连接，并获得一个必须由其客户端共享的地址。因此，N具有NAPT功能。现在，X1希望与对等方Y建立一个IPsec SA。这是可能的，因为N也是一个RSIP服务器，它通过本文档中定义的IPsec支持进行了扩展。Y支持IPsec，但不支持RSIP。这可能是最典型的应用程序场景。
The above is equally applicable in the ROBO (remote office, branch office) scenario.
上述内容同样适用于ROBO（远程办公室、分支办公室）场景。
The Roadwarrior scenario
------------------------
The Roadwarrior scenario
------------------------
+---------+ +------------+ +----------+
|RSIP | |Corporate | | IPsec |
|client X +--..........--+Firewall +---+ peer Y |
| | public | and | | (user's |
+---------+ Internet |RSIP server | | desktop) |
| N | | |
+------------+ +----------+
private corporate
network
+---------+ +------------+ +----------+
|RSIP | |Corporate | | IPsec |
|client X +--..........--+Firewall +---+ peer Y |
| | public | and | | (user's |
+---------+ Internet |RSIP server | | desktop) |
| N | | |
+------------+ +----------+
private corporate
network
In this example, a remote user with a laptop gains access to the Internet, perhaps by using PPP or DHCP. The user wants to access its corporation private network. Using mechanisms not specified in this document, the RSIP client in the laptop engages in an RSIP authentication and authorization phase with the RSIP server at the firewall. After that phase is completed, the IPsec extensions to RSIP defined here are used to establish an IPsec session with a peer, Y, that resides within the corporation's network. Y could be, for example, the remote user's usual desktop when at the office. The corporate firewall complex would use RSIP to selectively enable IPsec traffic between internal and external systems.
在本例中，拥有笔记本电脑的远程用户可能通过使用PPP或DHCP访问Internet。用户希望访问其公司专用网络。使用本文档中未指定的机制，笔记本电脑中的RSIP客户端与防火墙上的RSIP服务器进行RSIP身份验证和授权阶段。该阶段完成后，此处定义的RSIP的IPsec扩展用于与驻留在公司网络中的对等方Y建立IPsec会话。例如，Y可以是远程用户在办公室时的常用桌面。公司防火墙复合体将使用RSIP有选择地启用内部和外部系统之间的IPsec通信。
Note that this scenario could also be reversed in order to allow an internal system (Y) to initiate and establish an IPsec session with an external IPsec peer (X).
请注意，为了允许内部系统（Y）启动并与外部IPsec对等方（X）建立IPsec会话，也可以反转此场景。
Appendix G: Thoughts on Supporting Incoming Connections
附录G：关于支持传入连接的想法
Incoming IKE connections are much easier to support if the peer Y can initiate IKE exchanges to a port other than 500. In this case, the RSIP client would allocate that port at the RSIP server via ASSIGN_REQUEST_RSAP-IP. Alternatively, if the RSIP client is able to allocate an IP address at the RSIP server via ASSIGN_REQUEST_RSA-IP, Y could simply initiate the IKE exchange to port 500 at that address.
如果对等方Y可以发起到500以外的端口的IKE交换，则传入IKE连接更容易支持。在这种情况下，RSIP客户端将通过ASSIGN_REQUEST_RSAP-IP在RSIP服务器上分配该端口。或者，如果RSIP客户机能够通过ASSIGN_REQUEST_RSA-IP在RSIP服务器上分配IP地址，Y可以简单地启动IKE交换到该地址的端口500。
If there is only one address Nb that must be shared by the RSIP server and all its clients, and if Y can only send to port 500, the problem is much more difficult. At any given time, the combination of address Nb and UDP port 500 may be registered and used by only one RSIP system (including clients and server).
如果只有一个地址Nb必须由RSIP服务器及其所有客户端共享，并且如果Y只能发送到端口500，那么问题就要困难得多。在任何给定时间，地址Nb和UDP端口500的组合可仅由一个RSIP系统（包括客户端和服务器）注册和使用。
Solving this issue would require demultiplexing the incoming IKE connection request based on something other than the port and address combination. It may be possible to do so by first registering an identity with a new RSIP command of LISTEN_RSIP_IKE. Note that the identity could not be that of the IKE responder (the RSIP client), but that of the initiator (Y). The reason is that IKE Phase 1 only allows the sender to include its own identity, not that of the intended recipient (both, by the way, are allowed in Phase 2). Furthermore, the identity must be in the clear in the first incoming packet for the RSIP server to be able to use it as a demultiplexor. This rules out all variants of Main Mode and Aggressive Mode with Public Key Encryption (and Revised Mode of Public Key Encryption), since these encrypt the ID payload.
解决此问题需要基于端口和地址组合以外的其他内容对传入的IKE连接请求进行解复用。可以通过首先使用LISTEN_RSIP_IKE的新RSIP命令注册一个标识来实现。请注意，标识不能是IKE响应程序（RSIP客户端）的标识，而是启动器（Y）的标识。原因是IKE阶段1只允许发送方包含自己的身份，而不允许包含预期接收方的身份（顺便说一句，这两种身份在阶段2中都是允许的）。此外，RSIP服务器必须在第一个传入数据包中清除标识，才能将其用作解复用器。这排除了使用公钥加密的主模式和攻击模式（以及修改后的公钥加密模式）的所有变体，因为它们会加密ID有效负载。
The only Phase 1 variants which enable incoming IKE sessions are Aggressive Mode with signatures or with pre-shared keys. Because this scheme involves the RSIP server demultiplexing based on the identity of the IKE initiator, it is conceivable that only one RSIP client at a time may register interest in fielding requests from any given peer Y. Furthermore, this precludes more than one RSIP client' s being available to any unspecified peer Y.
启用传入IKE会话的唯一阶段1变体是带有签名或预共享密钥的攻击模式。由于该方案涉及基于IKE发起方的身份的RSIP服务器解复用，因此可以想象，一次只有一个RSIP客户端可以注册对来自任何给定对等方Y的请求的兴趣。此外，这排除了任何未指定对等方Y可以使用多个RSIP客户端。
Once the IKE session is in place, IPsec is set up as discussed in this document, namely, by the RSIP client and the RSIP server agreeing on an incoming SPI value, which is then communicated to the peer Y as part of Quick Mode.
IKE会话就位后，将按照本文档中的讨论设置IPsec，即由RSIP客户端和RSIP服务器在传入SPI值上达成一致，然后将传入SPI值作为快速模式的一部分传递给对等方Y。
The alternate address and port combination must be discovered by the remote peer using methods such as manual configuration, or the use of KX (RFC2230) or SRV (RFC2052) records. It may even be possible for the DNS query to trigger the above mechanisms to prepare for the incoming and impending IKE session initiation. Such a mechanism would allow more than one RSIP client to be available at any given
远程对等方必须使用手动配置或使用KX（RFC2230）或SRV（RFC2052）记录等方法发现备用地址和端口组合。DNS查询甚至可能触发上述机制，为即将到来的IKE会话启动做准备。这样的机制将允许在任何给定时间都有多个RSIP客户端可用
time, and would also enable each of them to respond to IKE initiations from unspecified peers. Such a DNS query, however, is not guaranteed to occur. For example, the result of the query could be cached and reused after the RSIP server is no longer listening for a given IKE peer's identity.
时间，还将使它们中的每一个能够响应来自未指定对等方的IKE启动。然而，这种DNS查询不能保证发生。例如，在RSIP服务器不再侦听给定IKE对等方的标识后，可以缓存查询结果并重新使用。
Because of the limitations implied by having to rely on the identity of the IKE initiator, the only practical way of supporting incoming connections is for the peer Y to initiate the IKE session at a port other than 500.
由于必须依赖IKE发起方的标识所隐含的限制，支持传入连接的唯一实用方法是对等方Y在500以外的端口发起IKE会话。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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 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编辑功能的资金目前由互联网协会提供。