Internet Engineering Task Force (IETF) A. Keranen
Request for Comments: 6261 Ericsson
Category: Experimental May 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Keranen
Request for Comments: 6261 Ericsson
Category: Experimental May 2011
ISSN: 2070-1721
Encrypted Signaling Transport Modes for the Host Identity Protocol
主机标识协议的加密信令传输模式
Abstract
摘要
This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow them to be conveyed over encrypted connections initiated with the Host Identity Protocol.
本文档规定了主机标识协议（HIP）信令消息的两种传输模式，允许通过主机标识协议启动的加密连接传输这些消息。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6261.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6261.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Transport Mode Negotiation . . . . . . . . . . . . . . . . . . 3
3.1. Mode Negotiation in the HIP Base Exchange . . . . . . . . 3
3.2. Mode Negotiation after the HIP Base Exchange . . . . . . . 5
3.3. Error Notifications . . . . . . . . . . . . . . . . . . . 5
4. HIP Messages on Encrypted Connections . . . . . . . . . . . . 5
4.1. ESP Mode . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. ESP-TCP Mode . . . . . . . . . . . . . . . . . . . . . . . 6
5. Recovering from Failed Encrypted Connections . . . . . . . . . 7
6. Host Mobility and Multihoming . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informational References . . . . . . . . . . . . . . . . . 10
Appendix A. Mobility and Multihoming Examples . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Transport Mode Negotiation . . . . . . . . . . . . . . . . . . 3
3.1. Mode Negotiation in the HIP Base Exchange . . . . . . . . 3
3.2. Mode Negotiation after the HIP Base Exchange . . . . . . . 5
3.3. Error Notifications . . . . . . . . . . . . . . . . . . . 5
4. HIP Messages on Encrypted Connections . . . . . . . . . . . . 5
4.1. ESP Mode . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. ESP-TCP Mode . . . . . . . . . . . . . . . . . . . . . . . 6
5. Recovering from Failed Encrypted Connections . . . . . . . . . 7
6. Host Mobility and Multihoming . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informational References . . . . . . . . . . . . . . . . . 10
Appendix A. Mobility and Multihoming Examples . . . . . . . . . . 11
Host Identity Protocol (HIP) [RFC5201] signaling messages can be exchanged over plain IP using the protocol number reserved for this purpose, or over UDP using the UDP port reserved for HIP NAT traversal [RFC5770]. When two hosts perform a HIP base exchange, they set up an encrypted connection between them for data traffic, but continue to use plain IP or UDP for HIP signaling messages.
主机标识协议（HIP）[RFC5201]信令消息可以使用为此目的保留的协议号在普通IP上交换，或者使用为HIP NAT遍历保留的UDP端口在UDP上交换[RFC5770]。当两台主机执行基于HIP的交换时，它们在它们之间为数据通信建立加密连接，但继续为HIP信令消息使用普通IP或UDP。
This document defines how the encrypted connection can be used also for HIP signaling messages. Two different modes are defined: HIP over Encapsulating Security Payload (ESP) and HIP over TCP. The benefit of sending HIP messages over ESP is that all signaling traffic (including HIP headers) will be encrypted. If HIP messages are sent over TCP (which in turn is transported over ESP), TCP can handle also message fragmentation where needed.
本文档定义了如何将加密连接也用于HIP信令消息。定义了两种不同的模式：HIP-over封装安全有效负载（ESP）和HIP-over-TCP。通过ESP发送HIP消息的好处是所有信令流量（包括HIP头）都将被加密。如果HIP消息通过TCP发送（反过来通过ESP传输），TCP还可以在需要时处理消息碎片。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section defines how support for different HIP signaling message transport modes is indicated and how the use of different modes is negotiated.
本节定义了如何指示对不同HIP信令消息传输模式的支持，以及如何协商不同模式的使用。
A HIP host implementing this specification SHOULD indicate the modes it supports, and is willing to use, in the base exchange. The HIP signaling message transport mode negotiation is similar to HIP NAT traversal mode negotiation: first the Responder lists the supported modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) in the R1 packet. The modes are listed in priority order, the more preferred mode(s) first. If the Initiator supports, and is willing to use, any of the modes proposed by the Responder, it selects one of the modes by adding a HIP_TRANSPORT_MODE parameter containing the selected mode to the I2 packet. Finally, if the Initiator selected one of the modes and the base exchange succeeds, hosts MUST use the selected mode for the following HIP signaling messages sent between them for the duration of the HIP association or until another mode is negotiated.
实现此规范的HIP主机应指明它在基本交换中支持并愿意使用的模式。HIP信令消息传输模式协商类似于HIP NAT穿越模式协商：首先，响应者在R1数据包中的HIP_transport_mode参数（见图1）中列出支持的模式。模式按优先级顺序列出，优先选择的模式优先。如果发起方支持并愿意使用响应方提出的任何模式，则通过向I2分组添加包含所选模式的HIP_TRANSPORT_MODE参数来选择其中一种模式。最后，如果启动器选择了其中一种模式，并且基本交换成功，则主机必须在HIP关联期间或在协商另一种模式之前，对它们之间发送的以下HIP信令消息使用所选模式。
If the Initiator cannot, or will not, use any of the modes proposed by the Responder, the Initiator SHOULD include an empty HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it supports this extension but will not use any of the proposed modes. Depending on local policy, the Responder MAY either abort the base exchange or continue HIP signaling without using an encrypted connection, if there was no HIP_TRANSPORT_MODE parameter in I2 or the parameter was empty. If the Initiator selects a mode that the Responder does not support (and hence was not included in R1), the Responder MUST abort the base exchange. If the base exchange is aborted due to (possibly lack of) HIP_TRANSPORT_PARAMETER, the Responder SHOULD send a NO_VALID_HIP_TRANSPORT_MODE notification (see Section 3.3) to the Initiator.
如果发起者不能或不会使用响应者提出的任何模式，发起者应在I2数据包中包含空HIP_TRANSPORT_MODE参数，以表示其支持此扩展，但不会使用任何提出的模式。根据本地策略，如果I2中没有HIP_TRANSPORT_MODE参数或参数为空，则响应方可以中止基本交换或继续HIP信令，而不使用加密连接。如果启动器选择了响应程序不支持的模式（因此不包括在R1中），则响应程序必须中止基本交换。如果由于（可能缺少）HIP_TRANSPORT_参数而中止基本交换，则响应者应向启动器发送无效的HIP_TRANSPORT_模式通知（见第3.3节）。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 7680 Port transport layer port number (or zero if not used) Length length in octets, excluding Type, Length, and Padding Mode ID defines the proposed or selected transport mode(s)
类型7680端口传输层端口号（如果未使用，则为零）长度（以八位字节为单位），不包括类型、长度和填充模式ID，用于定义建议的或选定的传输模式
The following HIP Transport Mode IDs are defined:
定义了以下髋部运输模式ID：
ID name Value RESERVED 0 DEFAULT 1 ESP 2 ESP-TCP 3
保留的ID名称值0默认值1 ESP 2 ESP-TCP 3
Figure 1: Format of the HIP_TRANSPORT_MODE Parameter
图1:HIP_TRANSPORT_MODE参数的格式
The mode DEFAULT indicates that the same transport mode (e.g., plain IP or UDP) that was used for the base exchange should be used for subsequent HIP signaling messages. In the ESP mode, the messages are sent as such on the encrypted ESP connection; in the ESP-TCP mode, TCP is used within the ESP tunnel. If a mode that uses a transport layer connection within the ESP tunnel (e.g., ESP-TCP) is offered, the Port field MUST contain the local port number the host will use for the connection. If none of the modes utilize a transport layer protocol, the Port field SHOULD be set to zero when the parameter is sent and ignored when received. The Port and Mode ID fields are encoded as unsigned integers using network byte order.
默认模式表示用于基本交换的相同传输模式（例如，普通IP或UDP）应用于后续HIP信令消息。在ESP模式下，通过加密的ESP连接发送消息；在ESP-TCP模式下，在ESP隧道内使用TCP。如果提供了在ESP隧道（例如ESP-TCP）内使用传输层连接的模式，则端口字段必须包含主机将用于连接的本地端口号。如果没有任何模式使用传输层协议，则发送参数时端口字段应设置为零，接收参数时忽略。端口和模式ID字段使用网络字节顺序编码为无符号整数。
The HIP_TRANSPORT_MODE parameter resides on the signed part of the HIP packets, and hence it is covered by the signatures of the R1, I2, and UPDATE packets.
HIP_TRANSPORT_MODE参数位于HIP数据包的签名部分，因此它被R1、I2和UPDATE数据包的签名覆盖。
If a HIP host wants to change to a different transport mode (or start using a transport mode) some time after the base exchange, it sends a HIP UPDATE packet with a HIP_TRANSPORT_MODE parameter containing the mode(s) it would prefer to use. The host receiving the UPDATE SHOULD respond with an UPDATE packet containing the mode that is selected as in the negotiation during the base exchange. If the receiving host does not support, or is not willing to use, any of the listed modes, it SHOULD respond with an UPDATE packet where the HIP_TRANSPORT_MODE parameter contains only the currently used transport mode (even if that was not included in the previous UPDATE packet) and continue using that mode.
如果HIP主机希望在基本交换后的某个时间更改为不同的传输模式（或开始使用传输模式），它将发送一个HIP更新数据包，其中包含HIP_传输_模式参数，该参数包含它希望使用的模式。接收更新的主机应使用更新包进行响应，更新包包含在基本交换期间协商中选择的模式。如果接收主机不支持或不愿意使用任何列出的模式，则应使用更新包进行响应，其中HIP_TRANSPORT_MODE参数仅包含当前使用的传输模式（即使该模式未包含在以前的更新包中），并继续使用该模式。
Since the HIP_TRANSPORT_MODE parameter's type is not critical (as defined in Section 5.2.1 of [RFC5201]), a host not supporting this extension would simply reply with an acknowledgement UPDATE packet without a HIP_TRANSPORT_MODE parameter. In such a case, depending on local policy as in mode negotiation during the base exchange, the host that requested the new transport mode MAY close the HIP association. If the association is closed, the host closing the association SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet to the other host before closing the association.
由于HIP_TRANSPORT_MODE参数的类型不重要（如[RFC5201]第5.2.1节所定义），因此不支持此扩展的主机只需使用不带HIP_TRANSPORT_MODE参数的确认更新包进行回复。在这种情况下，根据本地策略，例如在基本交换期间的模式内协商，请求新传输模式的主机可以关闭HIP关联。如果关联已关闭，则关闭关联的主机应在关闭关联之前向另一主机发送一个无效\u HIP\u传输\u模式通知数据包。
During a HIP signaling transport mode negotiation, if a HIP_TRANSPORT_MODE parameter does not contain any mode that the receiving host is willing to use, or a HIP_TRANSPORT_MODE parameter does not exist in a HIP packet where the receiving host expected to see it, the receiving host MAY send back a NOTIFY packet with a NOTIFICATION parameter [RFC5201] error type NO_VALID_HIP_TRANSPORT_MODE (value 100). The Notification Data field for the error notifications SHOULD contain the HIP header of the rejected packet.
在HIP信令传输模式协商期间，如果HIP_传输模式参数不包含接收主机愿意使用的任何模式，或者HIP_传输模式参数不存在于接收主机期望看到它的HIP分组中，则接收主机可以发送回带有通知参数的通知分组[RFC5201]错误类型NO_VALID_HIP_TRANSPORT_MODE（值100）。错误通知的通知数据字段应包含被拒绝数据包的HIP标头。
This specification defines two different transport modes for sending HIP packets over encrypted ESP connections. These modes require that the ESP transport format [RFC5202] is negotiated to be used between the hosts. If the ESP transport format is not used, these modes MUST NOT be offered in the HIP_TRANSPORT_MODE parameter. If a HIP_TRANSPORT_MODE parameter containing an ESP transport mode is received but the ESP transport format is not used, a host MUST NOT select such a mode but act as specified in Section 3.1 (if performing a base exchange) or Section 3.2 (if performing an UPDATE) when no valid mode is offered.
本规范定义了通过加密ESP连接发送HIP数据包的两种不同传输模式。这些模式要求在主机之间协商ESP传输格式[RFC5202]。如果未使用ESP传输格式，则HIP_transport_MODE参数中不得提供这些模式。如果接收到包含ESP传输模式的HIP_传输模式参数，但未使用ESP传输格式，则当未提供有效模式时，主机不得选择此类模式，而应按照第3.1节（如果执行基本交换）或第3.2节（如果执行更新）的规定行事。
The ESP mode provides simple protection for all the signaling traffic and can be used as a generic replacement for the DEFAULT mode in cases where all signaling traffic should be encrypted. If the HIP messages may become so large that they would need to be fragmented, e.g., because of HIP certificates [RFC6253] or DATA messages [RFC6078], it is RECOMMENDED to use the ESP-TCP mode that can handle message fragmentation at the TCP level instead of relying on IP-level fragmentation.
ESP模式为所有信令通信量提供简单的保护，在所有信令通信量都应加密的情况下，可作为默认模式的通用替代。如果HIP消息可能变得非常大，以至于需要分段，例如，由于HIP证书[RFC6253]或数据消息[RFC6078]，建议使用ESP-TCP模式，该模式可以在TCP级别处理消息分段，而不是依赖IP级别的分段。
When HIP NAT traversal [RFC5770] is used, the ESP and HIP packets are sent UDP encapsulated. The use of different NAT traversal modes, and in particular UDP encapsulation, is independent of the transport mode (as specified in this document) of HIP packets. However, when HIP packets are sent over an ESP connection, no additional UDP encapsulation (i.e., within the ESP connection) for the HIP packets is needed and MUST NOT be used since the ESP packets are already UDP encapsulated, if needed for NAT traversal. For example, if UDP encapsulation is used as defined in [RFC5770], and the ESP-TCP transport mode is used as defined in this document, the HIP packets are sent over IP, UDP, ESP, and TCP (in that order).
当使用HIP NAT遍历[RFC5770]时，ESP和HIP数据包通过UDP封装发送。不同NAT遍历模式的使用，特别是UDP封装，与HIP数据包的传输模式（如本文档所述）无关。但是，当通过ESP连接发送HIP数据包时，不需要对HIP数据包进行额外的UDP封装（即，在ESP连接内），并且不得使用，因为如果NAT穿越需要，ESP数据包已经进行了UDP封装。例如，如果按照[RFC5770]中的定义使用UDP封装，并且按照本文档中的定义使用ESP-TCP传输模式，则HIP数据包将通过IP、UDP、ESP和TCP（按该顺序）发送。
HIP messages that result in changing or generating new keying material, i.e., the base exchange and re-keying UPDATE messages, MUST NOT be sent over the encrypted connection that is created using the keying material that is being changed, nor over an encrypted connection using the newly created keying material.
导致更改或生成新密钥材料的HIP消息，即基本交换和重新密钥更新消息，不得通过使用正在更改的密钥材料创建的加密连接发送，也不得通过使用新创建的密钥材料创建的加密连接发送。
It should be noted that when HIP messages are sent using an encrypted connection, on-path network elements (e.g., firewalls and HIP-aware NATs) that would normally see the HIP headers and contents of the unencrypted parameters, cannot see any part of the messages unless they have access to the encryption keying material. The original HIP design made an explicit decision to expose some of this information to HIP-aware NATs. If an encrypted transport mode is used, only the base exchange or update without encryption is visible to such NATs.
应注意，当使用加密连接发送HIP消息时，通常会看到HIP头和未加密参数内容的路径上网络元素（例如防火墙和HIP感知NAT）无法看到消息的任何部分，除非它们可以访问加密密钥材料。最初的髋关节设计明确决定将其中一些信息公开给髋关节感知的NAT。如果使用加密传输模式，则此类NAT只能看到未加密的基本交换或更新。
If the ESP mode is selected in the base exchange, both hosts MUST listen for incoming HIP signaling messages and send outgoing messages on the encrypted connection. The ESP header's next header value for HIP messages sent over ESP MUST be set to HIP (139).
如果在基本交换机中选择了ESP模式，则两台主机必须侦听传入的HIP信令消息，并在加密连接上发送传出消息。通过ESP发送的HIP消息的ESP标头的下一个标头值必须设置为HIP（139）。
If the ESP-TCP mode is selected, the host with the larger HIT (calculated as defined in Section 6.5 of [RFC5201]) MUST start to listen for an incoming TCP connection on the encrypted connection
如果选择ESP-TCP模式，具有较大命中率（根据[RFC5201]第6.5节中的定义计算）的主机必须开始侦听加密连接上的传入TCP连接
(i.e., to the HIT of the host) on the port it used in the Port field of the transport mode parameter. The other host MUST create a TCP connection to that port and the host MAY use the port it sent in the transport mode parameter as the source port for the connection. Once the TCP connection is established, both hosts MUST listen for incoming HIP signaling messages and send the outgoing messages using the TCP connection. The ESP next header value for messages sent using the ESP-TCP mode TCP connections MUST be set to TCP (6).
在传输模式参数的port字段中使用的端口上。另一台主机必须创建到该端口的TCP连接，并且该主机可以使用它在传输模式参数中发送的端口作为连接的源端口。建立TCP连接后，两台主机必须侦听传入的HIP信令消息，并使用TCP连接发送传出消息。使用ESP-TCP模式TCP连接发送的消息的ESP next标头值必须设置为TCP（6）。
If the hosts are unable to create the TCP connection, the host that initiated the mode negotiation MUST restart the negotiation with the UPDATE message and SHOULD NOT propose the ESP-TCP mode. If local policy does not allow use of any mode other than ESP-TCP, the HIP association SHOULD be closed. The UPDATE or CLOSE message MUST be sent using the same transport mode that was used for negotiating the use of the ESP-TCP mode.
如果主机无法创建TCP连接，则启动模式协商的主机必须使用更新消息重新启动协商，并且不应提出ESP-TCP模式。如果本地策略不允许使用ESP-TCP以外的任何模式，则应关闭HIP关联。必须使用与协商ESP-TCP模式使用相同的传输模式发送更新或关闭消息。
Since TCP provides reliable transport, the HIP messages sent over TCP MUST NOT be retransmitted. Instead, a host SHOULD wait to detect that the TCP connection has failed to retransmit the packet successfully in a timely manner (such detection is platform- and policy-specific) before concluding that there is no response.
由于TCP提供了可靠的传输，通过TCP发送的HIP消息不得重新传输。相反，主机应该等待检测到TCP连接未能及时成功地重新传输数据包（这种检测是平台和策略特定的），然后才能得出没有响应的结论。
If the encrypted connection fails for some reason, it can no longer be used for HIP signaling and the hosts SHOULD re-establish the connection using HIP messages that are sent outside of the encrypted connection. Hence, while listening for incoming HIP messages on the encrypted connection, hosts MUST still accept incoming HIP messages using the same transport method (e.g., UDP or plain IP) that was used for the base exchange. When responding to a HIP message sent outside of the encrypted connection, the response MUST be sent using the same transport method as the original message used. If encryption was previously used, hosts SHOULD send outside of the encrypted connection only HIP messages that are used to re-establish the encrypted connection. In particular, when the policy requires that only encrypted messages (e.g., DATA messages using an encrypted transport mode) be sent, they MUST be sent using an encrypted connection. Note that a policy MUST NOT prevent sending unencrypted UPDATE messages used for re-establishing the encrypted connection, since that would prevent recovering from failed encrypted connections.
如果加密连接因某种原因失败，则它不能再用于HIP信令，主机应使用在加密连接外部发送的HIP消息重新建立连接。因此，在加密连接上侦听传入的HIP消息时，主机仍必须使用与基本交换相同的传输方法（例如UDP或普通IP）接受传入的HIP消息。当响应在加密连接外部发送的HIP消息时，必须使用与原始消息相同的传输方法发送响应。如果以前使用过加密，主机应仅在加密连接外部发送用于重新建立加密连接的HIP消息。特别是，当策略要求仅发送加密消息（例如，使用加密传输模式的数据消息）时，必须使用加密连接发送。请注意，策略不得阻止发送用于重新建立加密连接的未加密更新消息，因为这将阻止从失败的加密连接中恢复。
The UPDATE messages used for re-establishing the encrypted connection MUST contain a HIP_TRANSPORT_MODE parameter and the negotiation proceeds as described in Section 3.2.
用于重新建立加密连接的更新消息必须包含HIP_TRANSPORT_MODE参数，协商过程如第3.2节所述。
If a host obtains a new address, a new Security Association (SA) pair may be created for (or an existing SA pair may be moved to) the new address, as described in [RFC5206]. If the ESP or ESP-TCP transport mode is used, HIP signaling continues using the (new) SA pair and the same transport mode as before.
如[RFC5206]所述，如果主机获得新地址，则可为新地址创建新的安全关联（SA）对（或将现有SA对移动到新地址）。如果使用ESP或ESP-TCP传输模式，HIP信令将继续使用（新）SA对和与以前相同的传输模式。
With the ESP mode, the first mobility UPDATE message SHOULD be sent using the old SA, and the following messages, including the response to the first UPDATE, SHOULD be sent using the new SAs. Retransmissions of the UPDATE messages use the same SA as the original message. If the ESP-TCP mode is used, the HIP signaling TCP connection is moved to the new SA pair like any other TCP connection. However, the mobility UPDATE messages SHOULD NOT be sent over the TCP connection, but using plain ESP as in the ESP mode, and consequently hosts MUST be prepared to receive UPDATE messages over plain ESP even if the ESP-TCP mode is used.
在ESP模式下，应使用旧SA发送第一条移动更新消息，并且应使用新SA发送以下消息，包括对第一次更新的响应。更新消息的重新传输使用与原始消息相同的SA。如果使用ESP-TCP模式，HIP信令TCP连接将像任何其他TCP连接一样移动到新的SA对。但是，移动更新消息不应通过TCP连接发送，而应在ESP模式下使用普通ESP，因此，即使使用ESP-TCP模式，主机也必须准备好通过普通ESP接收更新消息。
In some cases, the host may not be able to send the mobility UPDATE messages using the encrypted connection before it breaks. This results in a similar situation as if the encrypted connection had failed and the hosts need to renegotiate the new addresses using unencrypted UPDATE messages and possibly rendezvous [RFC5204] or HIP relay [RFC5770] servers. Also, these UPDATE messages MUST contain the HIP_TRANSPORT_MODE parameter and perform the transport mode negotiation.
在某些情况下，主机可能无法在断开连接之前使用加密连接发送移动更新消息。这会导致类似的情况，好像加密连接失败，主机需要使用未加密的更新消息和可能的会合[RFC5204]或HIP中继[RFC5770]服务器重新协商新地址。此外，这些更新消息必须包含HIP_TRANSPORT_MODE参数并执行传输模式协商。
Examples of the signaling flows with mobility and multihoming are shown in Appendix A.
具有移动性和多址的信令流示例如附录A所示。
By exchanging the HIP messages over an ESP connection, all HIP signaling data (after the base exchange but excluding keying material (re)negotiation and some of the mobility UPDATE messages) will be encrypted, but only if NULL encryption is not used. Thus, a host requiring confidentiality for the HIP signaling messages must check that encryption is negotiated for use on the ESP connection. Moreover, the level of protection provided by the ESP transport modes depends on the selected ESP transform; see [RFC5202] and [RFC4303] for security considerations of the different ESP transforms.
通过通过ESP连接交换HIP消息，所有HIP信令数据（在基本交换之后，但不包括密钥材料（重新）协商和一些移动更新消息）将被加密，但只有在不使用空加密的情况下。因此，要求HIP信令消息保密的主机必须检查加密是否已协商，以便在ESP连接上使用。此外，ESP传输模式提供的保护级别取决于所选的ESP转换；有关不同ESP转换的安全注意事项，请参见[RFC5202]和[RFC4303]。
While this extension to HIP allows for negotiation of security features, there is no risk of downgrade attacks since the mode negotiation happens using signed (R1/I2 or UPDATE) packets and only after both hosts have been securely identified in the base exchange. If an attacker would attempt to change the modes listed in the
虽然这种对HIP的扩展允许协商安全功能，但不存在降级攻击的风险，因为模式协商是使用签名（R1/I2或更新）数据包进行的，并且只有在基本交换中安全地标识了两台主机之后才发生。如果攻击者试图更改中列出的模式
HIP_TRANSPORT_MODE parameter, that would break the signatures and the base exchange (or update) would not complete. Furthermore, since both "secure" modes (ESP and ESP-TCP) defined in this document are equally secure, the only possible downgrade attack would be to make both hosts accept the DEFAULT mode. If the local policy (of either host) requires using a secure mode, the base exchange or update would again simply fail (as described in Section 3.1).
HIP_TRANSPORT_MODE参数，该参数将破坏签名，并且基本交换（或更新）将无法完成。此外，由于本文档中定义的两种“安全”模式（ESP和ESP-TCP）都是同等安全的，因此唯一可能的降级攻击是使两台主机都接受默认模式。如果（任一主机的）本地策略要求使用安全模式，则基本交换或更新将再次失败（如第3.1节所述）。
Thanks to Gonzalo Camarillo, Kristian Slavov, Tom Henderson, Miika Komu, Jan Melen, and Tobias Heer for reviews and comments.
感谢冈萨洛·卡马里洛、克里斯蒂安·斯拉沃夫、汤姆·亨德森、米卡·科姆、扬·梅伦和托比亚斯·希尔的评论和评论。
This section is to be interpreted according to [RFC5226].
本节将根据[RFC5226]进行解释。
This document updates the IANA maintained "Host Identity Protocol (HIP) Parameters" registry [RFC5201] by assigning a new HIP Parameter Type value (7680) for the HIP_TRANSPORT_MODE parameter (defined in Section 3.1).
本文件通过为HIP_传输_模式参数（定义见第3.1节）分配新的HIP参数类型值（7680），更新IANA维护的“主机标识协议（HIP）参数”注册表[RFC5201]。
The HIP_TRANSPORT_MODE parameter has 16-bit unsigned integer fields for different modes, for which IANA has created and now maintains a new sub-registry entitled "HIP Transport Modes" under the "Host Identity Protocol (HIP) Parameters" registry. Initial values for the transport mode registry are given in Section 3.1; future assignments are to be made through IETF Review or IESG Approval [RFC5226]. Assignments consist of a transport mode identifier name and its associated value.
HIP_TRANSPORT_MODE参数具有不同模式的16位无符号整数字段，IANA已为这些字段创建并在“主机标识协议（HIP）参数”注册表下维护一个名为“HIP TRANSPORT modes”的新子注册表。第3.1节给出了运输模式注册表的初始值；未来的任务将通过IETF审查或IESG批准[RFC5226]进行。分配由传输模式标识符名称及其关联值组成。
This document also defines a new HIP NOTIFICATION message type [RFC5201] NO_VALID_HIP_TRANSPORT_MODE (100) in Section 3.3.
本文件还在第3.3节中定义了新的HIP通知消息类型[RFC5201]无效的HIP传输模式（100）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202]Jokela，P.，Moskowitz，R.，和P.Nikander，“将封装安全有效载荷（ESP）传输格式与主机标识协议（HIP）结合使用”，RFC 52022008年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204]Laganier，J.和L.Eggert，“主机身份协议（HIP）会合扩展”，RFC 52042008年4月。
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]Nikander，P.，Henderson，T.，Vogt，C.，和J.Arkko，“使用主机身份协议的终端主机移动性和多宿”，RFC 52062008年4月。
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators", RFC 5770, April 2010.
[RFC5770]Komu，M.，Henderson，T.，Tschofenig，H.，Melen，J.，和A.Keranen，“用于遍历网络地址转换器的基本主机身份协议（HIP）扩展”，RFC 57702010年4月。
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, January 2011.
[RFC6078]Camarillo，G.和J.Melen，“主机身份协议（HIP）上层协议信令的即时传输（HICCup）”，RFC 6078，2011年1月。
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011.
[RFC6253]Heer，T.和S.Varjonen，“主机身份协议证书”，RFC 6253，2011年5月。
When changing interfaces due to mobility or multihoming, the hosts use HIP messages to notify the other host about the new address and to check that the host with the new address is still reachable. The following examples show the signaling performed during the address change in two different scenarios. Note that not all HIP parameters nor all the content of the parameters is shown in the examples. This section and the examples are not normative; for normative behavior, see previous sections.
当由于移动性或多宿主而更改接口时，主机使用HIP消息通知另一台主机新地址，并检查具有新地址的主机是否仍然可以访问。以下示例显示了在两种不同场景中的地址更改期间执行的信令。请注意，示例中未显示所有髋部参数或参数的所有内容。本节和示例不规范；有关规范行为，请参见前面的章节。
In the examples, host A uses two different addresses (a1 and a2) while host B has just a single address (b1). In the first example, "Make before Break" (Figure 2), host A starts to use the new address but can still use the old address (due to multihoming) for signaling. In the second example, "Break before Make" (Figure 3), host A loses the first address before obtaining the second address (e.g., due to mobility), and the mobility HIP signaling is done without the encrypted connection.
在示例中，主机A使用两个不同的地址（a1和a2），而主机B只有一个地址（b1）。在第一个示例中，“先通后断”（图2），主机A开始使用新地址，但仍然可以使用旧地址（由于多归属）进行信令。在第二个示例中，“先断后通”（图3），主机A在获得第二个地址之前丢失第一个地址（例如，由于移动性），并且移动性HIP信令在没有加密连接的情况下完成。
The following notations are used in the examples:
示例中使用了以下符号：
o ESPx(y): data y sent encapsulated in ESP with SA x; if ESP-encapsulation is not used, the data is sent over plain IP or UDP
o ESPx（y）：用SA x封装在ESP中发送的数据y；如果未使用ESP封装，则通过普通IP或UDP发送数据
o UPDATE(x,y,z): HIP UPDATE message [RFC5201] with parameters x,y,z
o 更新（x，y，z）：带有参数x，y，z的HIP更新消息[RFC5201]
o LOCATOR(x): HIP LOCATOR parameter [RFC5206] with locator x
o 定位器（x）：带定位器x的髋部定位器参数[RFC5206]
o ESP_INFO(x,y): HIP ESP_INFO parameter [RFC5202] with "old SPI" value x and "new SPI" value y
o ESP_信息（x，y）：具有“旧SPI”值x和“新SPI”值y的HIP ESP_信息参数[RFC5202]
o ACK, ECHO_REQ, and ECHO_RSP: HIP ACK, ECHO_REQUEST, and ECHO_RESPONSE parameters [RFC5201]
o ACK、ECHO_REQ和ECHO_RSP:HIP ACK、ECHO_请求和ECHO_响应参数[RFC5201]
A B
ESP1(...)
a1 <----------------------------------------------> b1
A B
ESP1(...)
a1 <----------------------------------------------> b1
ESP1(UPDATE(LOCATOR(a2), ESP_INFO(0,SPI2a)))
a1 -----------------------------------------------> b1
ESP1(UPDATE(LOCATOR(a2), ESP_INFO(0,SPI2a)))
a1 -----------------------------------------------> b1
(A and B create SAs a2 <-> b1 (ESP2) retransmissions of the first UPDATE happen over ESP1)
（A和B创建SAs a2<->b1（ESP2）第一次更新的重传发生在ESP1上）
ESP2(UPDATE(ACK, ESP_INFO(0,SPI2b), ECHO_REQ)))
a2 <----------------------------------------------- b1
ESP2(UPDATE(ACK, ESP_INFO(0,SPI2b), ECHO_REQ)))
a2 <----------------------------------------------- b1
ESP2(UPDATE(ACK, ECHO_RSP))
a2 -----------------------------------------------> b1
ESP2(UPDATE(ACK, ECHO_RSP))
a2 -----------------------------------------------> b1
ESP2(...)
a2 <----------------------------------------------> b1
ESP2(...)
a2 <----------------------------------------------> b1
Figure 2: Make Before Break
图2：先通后断
A B
ESP1(...)
a1 <----------------------------------------------> b1
(A moves from a1 to a2)
A B
ESP1(...)
a1 <----------------------------------------------> b1
(A moves from a1 to a2)
UPDATE(LOCATOR(a2), ESP_INFO(SPI1a, SPI1a))
a2 -----------------------------------------------> b1
UPDATE(LOCATOR(a2), ESP_INFO(SPI1a, SPI1a))
a2 -----------------------------------------------> b1
UPDATE(ACK, ECHO_REQ, ESP_INFO(SPI1b,SPI1b))
a2 <----------------------------------------------- b1
UPDATE(ACK, ECHO_REQ, ESP_INFO(SPI1b,SPI1b))
a2 <----------------------------------------------- b1
UPDATE(ACK, ECHO_RSP)
a2 -----------------------------------------------> b1
(A and B move ESP1 SAs to a2 <-> b1)
UPDATE(ACK, ECHO_RSP)
a2 -----------------------------------------------> b1
(A and B move ESP1 SAs to a2 <-> b1)
ESP1(...)
a2 <----------------------------------------------> b1
ESP1(...)
a2 <----------------------------------------------> b1
Figure 3: Break Before Make
图3：先断后接
When the ESP-TCP mode is used, the signaling flows are similar since TCP is not used for the mobility UPDATE messages as described in Section 6.
当使用ESP-TCP模式时，信令流类似，因为TCP不用于第6节中所述的移动更新消息。
Author's Address
作者地址
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
EMail: ari.keranen@ericsson.com
EMail: ari.keranen@ericsson.com