Internet Engineering Task Force (IETF) P. Jokela
Request for Comments: 7402 Ericsson Research NomadicLab
Obsoletes: 5202 R. Moskowitz
Category: Standards Track HTT Consulting
ISSN: 2070-1721 J. Melen
Ericsson Research NomadicLab
April 2015
Internet Engineering Task Force (IETF) P. Jokela
Request for Comments: 7402 Ericsson Research NomadicLab
Obsoletes: 5202 R. Moskowitz
Category: Standards Track HTT Consulting
ISSN: 2070-1721 J. Melen
Ericsson Research NomadicLab
April 2015
Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)
将封装安全有效负载（ESP）传输格式与主机标识协议（HIP）一起使用
Abstract
摘要
This memo specifies an Encapsulating Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This document obsoletes RFC 5202.
此备忘录指定了一种基于封装安全有效负载（ESP）的机制，用于传输用户数据包，与主机标识协议（HIP）一起使用。本文件淘汰了RFC 5202。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc7402.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7402.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 ....................................................3
2. Conventions Used in This Document ...............................4
3. Using ESP with HIP ..............................................4
3.1. ESP Packet Format ..........................................5
3.2. Conceptual ESP Packet Processing ...........................5
3.2.1. Semantics of the Security Parameter Index (SPI) .....6
3.3. Security Association Establishment and Maintenance .........6
3.3.1. ESP Security Associations ...........................6
3.3.2. Rekeying ............................................7
3.3.3. Security Association Management .....................8
3.3.4. Security Parameter Index (SPI) ......................8
3.3.5. Supported Ciphers ...................................8
3.3.6. Sequence Number .....................................9
3.3.7. Lifetimes and Timers ................................9
3.4. IPsec and HIP ESP Implementation Considerations ............9
3.4.1. Data Packet Processing Considerations ..............10
3.4.2. HIP Signaling Packet Considerations ................10
4. The Protocol ...................................................11
4.1. ESP in HIP ................................................11
4.1.1. IPsec ESP Transport Format Type ....................11
4.1.2. Setting Up an ESP Security Association .............11
4.1.3. Updating an Existing ESP SA ........................12
5. Parameter and Packet Formats ...................................13
5.1. New Parameters ............................................13
5.1.1. ESP_INFO ...........................................13
5.1.2. ESP_TRANSFORM ......................................15
5.1.3. NOTIFICATION Parameter .............................16
5.2. HIP ESP Security Association Setup ........................17
5.2.1. Setup during Base Exchange .........................17
5.3. HIP ESP Rekeying ..........................................18
5.3.1. Initializing Rekeying ..............................19
5.3.2. Responding to the Rekeying Initialization ..........19
5.4. ICMP Messages .............................................20
5.4.1. Unknown SPI ........................................20
6. Packet Processing ..............................................20
6.1. Processing Outgoing Application Data ......................20
6.2. Processing Incoming Application Data ......................21
6.3. HMAC and SIGNATURE Calculation and Verification ...........21
6.4. Processing Incoming ESP SA Initialization (R1) ............22
6.5. Processing Incoming Initialization Reply (I2) .............22
6.6. Processing Incoming ESP SA Setup Finalization (R2) ........23
6.7. Dropping HIP Associations .................................23
6.8. Initiating ESP SA Rekeying ................................23
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Using ESP with HIP ..............................................4
3.1. ESP Packet Format ..........................................5
3.2. Conceptual ESP Packet Processing ...........................5
3.2.1. Semantics of the Security Parameter Index (SPI) .....6
3.3. Security Association Establishment and Maintenance .........6
3.3.1. ESP Security Associations ...........................6
3.3.2. Rekeying ............................................7
3.3.3. Security Association Management .....................8
3.3.4. Security Parameter Index (SPI) ......................8
3.3.5. Supported Ciphers ...................................8
3.3.6. Sequence Number .....................................9
3.3.7. Lifetimes and Timers ................................9
3.4. IPsec and HIP ESP Implementation Considerations ............9
3.4.1. Data Packet Processing Considerations ..............10
3.4.2. HIP Signaling Packet Considerations ................10
4. The Protocol ...................................................11
4.1. ESP in HIP ................................................11
4.1.1. IPsec ESP Transport Format Type ....................11
4.1.2. Setting Up an ESP Security Association .............11
4.1.3. Updating an Existing ESP SA ........................12
5. Parameter and Packet Formats ...................................13
5.1. New Parameters ............................................13
5.1.1. ESP_INFO ...........................................13
5.1.2. ESP_TRANSFORM ......................................15
5.1.3. NOTIFICATION Parameter .............................16
5.2. HIP ESP Security Association Setup ........................17
5.2.1. Setup during Base Exchange .........................17
5.3. HIP ESP Rekeying ..........................................18
5.3.1. Initializing Rekeying ..............................19
5.3.2. Responding to the Rekeying Initialization ..........19
5.4. ICMP Messages .............................................20
5.4.1. Unknown SPI ........................................20
6. Packet Processing ..............................................20
6.1. Processing Outgoing Application Data ......................20
6.2. Processing Incoming Application Data ......................21
6.3. HMAC and SIGNATURE Calculation and Verification ...........21
6.4. Processing Incoming ESP SA Initialization (R1) ............22
6.5. Processing Incoming Initialization Reply (I2) .............22
6.6. Processing Incoming ESP SA Setup Finalization (R2) ........23
6.7. Dropping HIP Associations .................................23
6.8. Initiating ESP SA Rekeying ................................23
6.9. Processing Incoming UPDATE Packets ........................24
6.9.1. Processing UPDATE Packet: No Outstanding
Rekeying Request ...................................25
6.10. Finalizing Rekeying ......................................26
6.11. Processing NOTIFY Packets ................................26
7. Keying Material ................................................27
8. Security Considerations ........................................27
9. IANA Considerations ............................................28
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................30
Appendix A. A Note on Implementation Options ......................32
Appendix B. Bound End-to-End Tunnel Mode for ESP ..................32
B.1. Protocol Definition ........................................33
B.1.1. Changes to Security Association Data Structures .....33
B.1.2. Packet Format .......................................34
B.1.3. Cryptographic Processing ............................36
B.1.4. IP Header Processing ................................36
B.1.5. Handling of Outgoing Packets ........................37
B.1.6. Handling of Incoming Packets ........................38
B.1.7. Handling of IPv4 Options ............................39
Acknowledgments ...................................................40
Authors' Addresses ................................................40
6.9. Processing Incoming UPDATE Packets ........................24
6.9.1. Processing UPDATE Packet: No Outstanding
Rekeying Request ...................................25
6.10. Finalizing Rekeying ......................................26
6.11. Processing NOTIFY Packets ................................26
7. Keying Material ................................................27
8. Security Considerations ........................................27
9. IANA Considerations ............................................28
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................30
Appendix A. A Note on Implementation Options ......................32
Appendix B. Bound End-to-End Tunnel Mode for ESP ..................32
B.1. Protocol Definition ........................................33
B.1.1. Changes to Security Association Data Structures .....33
B.1.2. Packet Format .......................................34
B.1.3. Cryptographic Processing ............................36
B.1.4. IP Header Processing ................................36
B.1.5. Handling of Outgoing Packets ........................37
B.1.6. Handling of Incoming Packets ........................38
B.1.7. Handling of IPv4 Options ............................39
Acknowledgments ...................................................40
Authors' Addresses ................................................40
In the Host Identity Protocol Architecture [HIP-ARCH], hosts are identified with public keys. The Host Identity Protocol (HIP) [RFC7401] base exchange allows any two HIP-supporting hosts to authenticate each other and to create a HIP association between themselves. During the base exchange, the hosts generate a piece of shared keying material using an authenticated Diffie-Hellman exchange.
在主机标识协议体系结构[HIP-ARCH]中，主机由公钥标识。Host Identity Protocol（HIP）[RFC7401]基本交换允许任何两个支持HIP的主机相互验证，并在它们之间创建HIP关联。在基本交换期间，主机使用经过身份验证的Diffie-Hellman交换生成一段共享密钥材料。
The HIP base exchange specification [RFC7401] does not describe any transport formats or methods for user data to be used during the actual communication; it only defines that it is mandatory to implement the Encapsulating Security Payload (ESP) [RFC4303] based transport format and method. This document specifies how ESP is used with HIP to carry actual user data.
HIP base exchange规范[RFC7401]未描述实际通信期间使用的用户数据的任何传输格式或方法；它仅定义必须实现基于封装安全有效负载（ESP）[RFC4303]的传输格式和方法。本文档规定了如何将ESP与HIP结合使用来携带实际用户数据。
To be more specific, this document specifies a set of HIP protocol extensions and their handling. Using these extensions, a pair of ESP Security Associations (SAs) is created between the hosts during the base exchange. The resulting ESP Security Associations use keys drawn from the keying material (KEYMAT) generated during the base exchange. After the HIP association and required ESP SAs have been
更具体地说，本文档指定了一组HIP协议扩展及其处理。使用这些扩展，在基本交换期间在主机之间创建一对ESP安全关联（SA）。生成的ESP安全关联使用从基本交换期间生成的键控材质（KEYMAT）中提取的键。在髋关节协会和要求的ESP SAs完成后
established between the hosts, the user data communication is protected using ESP. In addition, this document specifies methods to update an existing ESP Security Association.
在主机之间建立，用户数据通信使用ESP进行保护。此外，本文档指定了更新现有ESP安全关联的方法。
It should be noted that representations of Host Identity are not carried explicitly in the headers of user data packets. Instead, the ESP Security Parameter Index (SPI) is used to indicate the right host context. The SPIs are selected during the HIP ESP setup exchange. For user data packets, ESP SPIs (in possible combination with IP addresses) are used indirectly to identify the host context, thereby avoiding any additional explicit protocol headers.
应该注意的是，主机标识的表示没有显式地携带在用户数据包的报头中。相反，ESP安全参数索引（SPI）用于指示正确的主机上下文。在HIP ESP设置交换期间选择SPI。对于用户数据包，ESP SPI（可能与IP地址组合）被间接用于标识主机上下文，从而避免任何额外的显式协议头。
HIP and ESP traffic have known issues with middlebox traversal (RFC 5207 [RFC5207]). Other specifications exist for operating HIP and ESP over UDP. (RFC 5770 [RFC5770] is an experimental specification, and others are being developed.) Middlebox traversal is out of scope for this document.
HIP和ESP流量存在已知的中间盒遍历问题（RFC 5207[RFC5207]）。存在通过UDP操作HIP和ESP的其他规范。（RFC 5770[RFC5770]是一个实验性规范，其他规范正在开发中。）中间盒遍历超出了本文档的范围。
This document obsoletes RFC 5202.
本文件淘汰了RFC 5202。
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]中所述进行解释。
The HIP base exchange is used to set up a HIP association between two hosts. The base exchange provides two-way host authentication and key material generation, but it does not provide any means for protecting data communication between the hosts. In this document, we specify the use of ESP for protecting user data traffic after the HIP base exchange. Note that this use of ESP is intended only for host-to-host traffic; security gateways are not supported.
HIP base exchange用于在两个主机之间建立HIP关联。基本交换提供双向主机身份验证和密钥材料生成，但它不提供任何保护主机之间数据通信的方法。在本文档中，我们指定在HIP base exchange之后使用ESP来保护用户数据流量。请注意，ESP的使用仅用于主机到主机的通信；不支持安全网关。
To support ESP use, the HIP base exchange messages require some minor additions to the parameters transported. In the R1 packet, the Responder adds the possible ESP transforms in an ESP_TRANSFORM parameter before sending it to the Initiator. The Initiator gets the proposed transforms, selects one of those proposed transforms, and adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2 packet, the Initiator also sends the SPI value that it wants to be used for ESP traffic flowing from the Responder to the Initiator. This information is carried using the ESP_INFO parameter. When finalizing the ESP SA setup, the Responder sends its SPI value to the Initiator in the R2 packet, again using ESP_INFO.
为了支持ESP的使用，HIP base exchange消息需要对传输的参数进行一些小的添加。在R1数据包中，响应程序在将其发送给启动器之前，将可能的ESP转换添加到ESP_转换参数中。发起方获取建议的转换，选择其中一个建议的转换，并将其添加到ESP_转换参数中的I2数据包中。在这个I2数据包中，发起方还发送它希望用于从响应方流向发起方的ESP流量的SPI值。此信息使用ESP_INFO参数携带。当完成ESP SA设置时，响应程序再次使用ESP_信息将其SPI值发送到R2数据包中的启动器。
The ESP specification [RFC4303] defines the ESP packet format for IPsec. The HIP ESP packet looks exactly the same as the IPsec ESP transport format packet. The semantics, however, are a bit different and are described in more detail in the next subsection.
ESP规范[RFC4303]定义了IPsec的ESP数据包格式。HIP ESP数据包看起来与IPsec ESP传输格式数据包完全相同。但是，语义有点不同，将在下一小节中进行更详细的描述。
ESP packet processing can be implemented in different ways in HIP. It is possible to implement it in a way that a standards compliant, unmodified IPsec implementation [RFC4303] can be used in conjunction with some additional transport checksum processing above it, and if IP addresses are used as indexes to the right host context.
ESP数据包处理可以在HIP中以不同的方式实现。如果IP地址用作正确主机上下文的索引，则可以采用符合标准、未经修改的IPsec实现[RFC4303]与上面的一些附加传输校验和处理结合使用的方式来实现它。
When a standards compliant IPsec implementation that uses IP addresses in the Security Policy Database (SPD) and Security Association Database (SAD) is used, the packet processing may take the following steps. For outgoing packets, assuming that the upper-layer pseudo header has been built using IP addresses, the implementation recalculates upper-layer checksums using Host Identity Tags (HITs) and, after that, changes the packet source and destination addresses back to corresponding IP addresses. The packet is sent to the IPsec ESP for transport mode handling, and from there the encrypted packet is sent to the network. When an ESP packet is received, the packet is first put through the IPsec ESP transport mode handling, and after decryption, the source and destination IP addresses are replaced with HITs, and finally, upper-layer checksums are verified before passing the packet to the upper layer.
当使用在安全策略数据库（SPD）和安全关联数据库（SAD）中使用IP地址的符合标准的IPsec实现时，数据包处理可采取以下步骤。对于传出数据包，假设上层伪报头已使用IP地址构建，则实现将使用主机标识标记（HITs）重新计算上层校验和，然后将数据包源地址和目标地址更改回相应的IP地址。数据包被发送到IPsec ESP进行传输模式处理，并从那里将加密数据包发送到网络。当接收到ESP数据包时，该数据包首先通过IPsec ESP传输模式处理，解密后，源和目标IP地址被替换为HITs，最后，在将数据包传递到上层之前，验证上层校验和。
An alternative way to implement packet processing is the BEET (Bound End-to-End Tunnel) mode (see Appendix B). In BEET mode, the ESP packet is formatted as a transport mode packet, but the semantics of the connection are the same as for tunnel mode. The "outer" addresses of the packet are the IP addresses, and the "inner" addresses are the HITs. For outgoing traffic, after the packet has been encrypted, the packet's IP header is changed to a new one that contains IP addresses instead of HITs, and the packet is sent to the network. When the ESP packet is received, the SPI value, together with the integrity protection, allow the packet to be securely associated with the right HIT pair. The packet header is replaced with a new header containing HITs, and the packet is decrypted. BEET mode is completely internal for a host and doesn't require that the corresponding host implement it; instead, the corresponding host can have ESP transport mode and do HIT IP conversions outside ESP.
实现数据包处理的另一种方法是BEET（绑定端到端隧道）模式（见附录B）。在BEET模式下，ESP数据包被格式化为传输模式数据包，但连接的语义与隧道模式相同。数据包的“外部”地址是IP地址，“内部”地址是命中数。对于传出流量，在对数据包进行加密后，数据包的IP报头将更改为包含IP地址而不是HITs的新报头，并将数据包发送到网络。当收到ESP数据包时，SPI值以及完整性保护允许数据包与右击对安全关联。数据包报头被一个包含点击的新报头替换，数据包被解密。BEET模式对于主机来说是完全内部的，不需要相应的主机实现它；相反，相应的主机可以具有ESP传输模式，并在ESP之外进行命中IP转换。
SPIs are used in ESP to find the right Security Association for received packets. The ESP SPIs have added significance when used with HIP; they are a compressed representation of a pair of HITs. Thus, SPIs MAY be used by intermediary systems in providing services like address mapping. Note that since the SPI has significance at the receiver, only the < DST, SPI >, where DST is a destination IP address, uniquely identifies the receiver HIT at any given point of time. The same SPI value may be used by several hosts. A single < DST, SPI > value may denote different hosts and contexts at different points of time, depending on the host that is currently reachable at the DST.
SPI在ESP中用于为接收到的数据包找到正确的安全关联。ESP SPI与HIP一起使用时具有更大的意义；它们是一对点击的压缩表示。因此，SPI可由中介系统用于提供诸如地址映射之类的服务。注意，由于SPI在接收器处具有重要意义，因此只有<DST，SPI>（其中DST是目的地IP地址）在任何给定时间点唯一地标识接收器命中。多台主机可能使用相同的SPI值。单个<DST，SPI>值可能表示不同时间点的不同主机和上下文，具体取决于当前可在DST访问的主机。
Each host selects for itself the SPI it wants to see in packets received from its peer. This allows it to select different SPIs for different peers. The SPI selection SHOULD be random; the rules of Section 2.1 of the ESP specification [RFC4303] must be followed. A different SPI SHOULD be used for each HIP exchange with a particular host; this is to avoid a replay attack. Additionally, when a host rekeys, the SPI MUST be changed. Furthermore, if a host changes over to use a different IP address, it MAY change the SPI.
每个主机为自己选择它希望在从其对等机接收的数据包中看到的SPI。这允许它为不同的对等点选择不同的SPI。SPI选择应是随机的；必须遵守ESP规范[RFC4303]第2.1节的规定。与特定主机的每次髋关节置换应使用不同的SPI；这是为了避免重播攻击。此外，当主机重新设置密钥时，必须更改SPI。此外，如果主机切换为使用不同的IP地址，则可能会更改SPI。
One method for SPI creation that meets the above criteria would be to concatenate the HIT with a 32-bit random or sequential number, hash this (using SHA1), and then use the high-order 32 bits as the SPI.
符合上述标准的SPI创建方法之一是将命中与32位随机数或序列号连接起来，对此进行散列（使用SHA1），然后使用高阶32位作为SPI。
The selected SPI is communicated to the peer in the third (I2) and fourth (R2) packets of the base HIP exchange. Changes in SPI are signaled with ESP_INFO parameters.
所选择的SPI在基本HIP交换的第三（I2）和第四（R2）分组中被传送给对等方。SPI的变化通过ESP_信息参数发出信号。
In HIP, ESP Security Associations are set up between the HIP nodes during the base exchange [RFC7401]. Existing ESP SAs can be updated later using UPDATE messages. The reason for updating the ESP SA later can be, for example, a need for rekeying the SA because of sequence number rollover.
在HIP中，在基本交换期间在HIP节点之间建立ESP安全关联[RFC7401]。以后可以使用更新消息更新现有ESP SAs。稍后更新ESP SA的原因可能是，例如，由于序列号滚动，需要重新设置SA的密钥。
Upon setting up a HIP association, each association is linked to two ESP SAs, one for incoming packets and one for outgoing packets. The Initiator's incoming SA corresponds with the Responder's outgoing one, and vice versa. The Initiator defines the SPI for its incoming association, as defined in Section 3.2.1. This SA is herein called
建立HIP关联后，每个关联都链接到两个ESP SA，一个用于传入数据包，一个用于传出数据包。发起方的传入SA与响应方的传出SA相对应，反之亦然。启动器为其传入关联定义SPI，如第3.2.1节所定义。此SA在此称为
SA-RI, and the corresponding SPI is called SPI-RI. Respectively, the Responder's incoming SA corresponds with the Initiator's outgoing SA and is called SA-IR, with the SPI being called SPI-IR.
SA-RI，相应的SPI称为SPI-RI。响应者的传入SA分别对应于启动器的传出SA，称为SA-IR，SPI称为SPI-IR。
The Initiator creates SA-RI as a part of R1 processing, before sending out the I2, as explained in Section 6.4. The keys are derived from KEYMAT, as defined in Section 7. The Responder creates SA-RI as a part of I2 processing; see Section 6.5.
发起者在发送I2之前创建SA-RI作为R1处理的一部分，如第6.4节所述。根据第7节中的定义，钥匙来自KEYMAT。响应者创建SA-RI作为I2处理的一部分；见第6.5节。
The Responder creates SA-IR as a part of I2 processing, before sending out R2; see Section 6.5. The Initiator creates SA-IR when processing R2; see Section 6.6.
响应者在发送R2之前创建SA-IR作为I2处理的一部分；见第6.5节。发起方在处理R2时创建SA-IR；见第6.6节。
The initial session keys are drawn from the generated keying material, KEYMAT, after the HIP keys have been drawn as specified in [RFC7401].
按照[RFC7401]中的规定绘制臀部关键点后，从生成的关键点材质KEYMAT中绘制初始会话关键点。
When the HIP association is removed, the related ESP SAs MUST also be removed.
移除髋部关联后，还必须移除相关的ESP SA。
After the initial HIP base exchange and SA establishment, both hosts are in the ESTABLISHED state. There are no longer Initiator and Responder roles, and the association is symmetric. In this subsection, the party that initiates the rekey procedure is denoted with I' and the peer with R'.
在初始髋部碱基交换和SA建立后，两个主机都处于已建立状态。不再有发起方和响应方角色，并且关联是对称的。在本小节中，启动密钥更新程序的一方用I'表示，对等方用R'表示。
An existing HIP-created ESP SA may need updating during the lifetime of the HIP association. This document specifies the rekeying of an existing HIP-created ESP SA, using the UPDATE message. The ESP_INFO parameter introduced above is used for this purpose.
在HIP关联的生命周期内，ESP SA创建的现有HIP可能需要更新。本文档指定使用更新消息对ESP SA创建的现有HIP重新设置密钥。上面介绍的ESP_INFO参数用于此目的。
I' initiates the ESP SA updating process when needed (see Section 6.8). It creates an UPDATE packet with required information and sends it to the peer node. The old SAs are still in use, local policy permitting.
I’在需要时启动ESP SA更新过程（参见第6.8节）。它创建一个包含所需信息的更新包，并将其发送到对等节点。在当地政策允许的情况下，旧SAs仍在使用。
R', after receiving and processing the UPDATE (see Section 6.9), generates new SAs: SA-I'R' and SA-R'I'. It does not take the new outgoing SA into use, but still uses the old one, so there temporarily exist two SA pairs towards the same peer host. The SPI for the new outgoing SA, SPI-R'I', is specified in the received ESP_INFO parameter in the UPDATE packet. For the new incoming SA, R' generates the new SPI value, SPI-I'R', and includes it in the response UPDATE packet.
接收并处理更新后（见第6.9节），生成新的SA:SA-I'R'和SA-R'I'。它不使用新的传出SA，但仍使用旧的SA，因此暂时存在两个指向同一对等主机的SA对。新传出SA的SPI-R'I'在更新数据包中接收到的ESP_信息参数中指定。对于新的传入SA，R'生成新的SPI值SPI-I'R'，并将其包括在响应更新包中。
When I' receives a response UPDATE from R', it generates new SAs, as described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the new outgoing SA immediately.
如第6.9节：SA-I'R'和SA-R'I'所述，当I'从R'接收到响应更新'时，它将生成新的SA。它立即开始使用新的传出SA。
R' starts using the new outgoing SA when it receives traffic on the new incoming SA or when it receives the UPDATE ACK confirming completion of rekeying. After this, R' can remove the old SAs. Similarly, when the I' receives traffic from the new incoming SA, it can safely remove the old SAs.
R'在接收到新传入SA上的通信量或接收到确认重新键入完成的更新确认时，开始使用新传出SA。在此之后，R'可以删除旧的SAs。类似地，当I’从新的传入SA接收流量时，它可以安全地删除旧SA。
An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote HITs since a system can have more than one HIT). An inactivity timer is RECOMMENDED for all SAs. If the state dictates the deletion of an SA, a timer is set to allow for any late arriving packets.
SA对由2个SPI和2个命中（本地和远程命中，因为系统可以有多个命中）索引。建议所有SA使用非活动计时器。如果该状态指示删除SA，则会设置计时器以允许任何延迟到达的数据包。
The SPIs in ESP provide a simple compression of the HIP data from all packets after the HIP exchange. This does require a per HIT-pair Security Association (and SPI), and a decrease of policy granularity over other Key Management Protocols like Internet Key Exchange (IKE) [RFC7296].
ESP中的SPI提供了HIP交换后所有数据包中HIP数据的简单压缩。这确实需要一个每命中对安全关联（和SPI），并且与其他密钥管理协议（如Internet密钥交换（IKE））相比，需要减少策略粒度[RFC7296]。
When a host updates the ESP SA, it provides a new inbound SPI to and gets a new outbound SPI from its peer.
当主机更新ESP SA时，它将向其对等机提供新的入站SPI，并从其对等机获取新的出站SPI。
All HIP implementations MUST support AES-128-CBC and AES-256-CBC [RFC3602]. If the Initiator does not support any of the transforms offered by the Responder, it should abandon the negotiation and inform the peer with a NOTIFY message about a non-supported transform.
所有HIP实施必须支持AES-128-CBC和AES-256-CBC[RFC3602]。如果发起方不支持响应方提供的任何转换，它应该放弃协商，并用一条关于不支持的转换的通知消息通知对等方。
In addition to AES-128-CBC, all implementations SHOULD implement the ESP NULL encryption algorithm. When the ESP NULL encryption is used, it MUST be used together with SHA-256 authentication as specified in Section 5.1.2.
除AES-128-CBC外，所有实现都应实现ESP空加密算法。使用ESP NULL加密时，必须与第5.1.2节规定的SHA-256身份验证一起使用。
When an authentication-only suite is used (NULL, AES-CMAC-96, and AES-GMAC are examples), the suite MUST NOT be accepted if offered by the peer unless the local policy configuration regarding the peer host is explicitly set to allow an authentication-only mode. This is to prevent sessions from being downgraded to an authentication-only mode when one side's policy requests privacy for the session.
当使用仅限身份验证套件时（NULL、AES-CMAC-96和AES-GMAC是示例），如果该套件由对等主机提供，则不得接受该套件，除非有关对等主机的本地策略配置明确设置为允许仅限身份验证模式。这是为了防止当一方的策略请求会话的隐私时，会话降级为仅身份验证模式。
The Sequence Number field is MANDATORY when ESP is used with HIP. Anti-replay protection MUST be used in an ESP SA established with HIP. When ESP is used with HIP, a 64-bit sequence number MUST be used. This means that each host MUST rekey before its sequence number reaches 2^64.
当ESP与HIP一起使用时，序列号字段是必需的。在使用HIP建立的ESP SA中必须使用防重放保护。当ESP与HIP一起使用时，必须使用64位序列号。这意味着每个主机必须在其序列号达到2^64之前重新设置密钥。
When using a 64-bit sequence number, the higher 32 bits are NOT included in the ESP header, but are simply kept local to both peers. See [RFC4301].
当使用64位序列号时，较高的32位不包括在ESP报头中，但仅对两个对等方保持本地。参见[RFC4301]。
HIP does not negotiate any lifetimes. All ESP lifetimes are local policy. The only lifetimes a HIP implementation MUST support are sequence number rollover (for replay protection), and SHOULD support timing out inactive ESP SAs. An SA times out if no packets are received using that SA. Implementations SHOULD support a configurable SA timeout value. Implementations MAY support lifetimes for the various ESP transforms. Each implementation SHOULD implement per-HIT configuration of the inactivity timeout, allowing statically configured HIP associations to stay alive for days, even when inactive.
HIP不会在任何生命周期内进行协商。所有ESP寿命均为本地政策。HIP实现必须支持的唯一生命周期是序列号翻转（用于重播保护），并且应该支持超时非活动ESP SA。如果没有使用SA接收到数据包，SA将超时。实现应支持可配置的SA超时值。实现可能支持各种ESP转换的生存期。每个实现都应该实现不活动超时的每次命中配置，允许静态配置的HIP关联保持活动数天，即使在不活动时也是如此。
When HIP is run on a node where a standards compliant IPsec is used, some issues have to be considered.
当HIP在使用符合标准的IPsec的节点上运行时，必须考虑一些问题。
The HIP implementation must be able to co-exist with other IPsec keying protocols. When the HIP implementation selects the SPI value, it may lead to a collision if not implemented properly. To avoid the possibility for a collision, the HIP implementation MUST ensure that the SPI values used for HIP SAs are not used for IPsec or other SAs, and vice versa.
HIP实现必须能够与其他IPsec密钥协议共存。当HIP实现选择SPI值时，如果未正确实现，可能会导致碰撞。为了避免冲突的可能性，HIP实现必须确保用于HIP SA的SPI值不用于IPsec或其他SA，反之亦然。
Incoming packets using an SA that is not negotiated by HIP MUST NOT be processed as described in Section 3.2, paragraph 2. The SPI will identify the correct SA for packet decryption and MUST be used to identify that the packet has an upper-layer checksum that is calculated as specified in [RFC7401].
不得按照第3.2节第2段中的说明处理使用SA的非HIP协商的传入数据包。SPI将识别用于数据包解密的正确SA，并且必须用于识别数据包是否具有按照[RFC7401]中的规定计算的上层校验和。
For outbound traffic, the SPD (or coordinated SPDs, if there are two -- one for HIP and one for IPsec) MUST ensure that packets intended for HIP processing are given a HIP-enabled SA and that packets intended for IPsec processing are given an IPsec-enabled SA. The SP then MUST be bound to the matching SA, and non-HIP packets will not be processed by this SA. Data originating from a socket that is not using HIP MUST NOT have the checksum recalculated (as described in Section 3.2, paragraph 2), and data MUST NOT be passed to the SP or SA created by HIP.
对于出站流量，SPD（或协调SPD，如果有两个—一个用于HIP，一个用于IPsec）必须确保为HIP处理的数据包提供支持HIP的SA，并且为IPsec处理的数据包提供支持IPsec的SA。然后SP必须绑定到匹配的SA，此SA不会处理非HIP数据包。来自未使用HIP的套接字的数据不得重新计算校验和（如第3.2节第2段所述），且不得将数据传递给HIP创建的SP或SA。
It is possible that in the case of overlapping policies, the outgoing packet would be handled by both IPsec and HIP. In this case, it is possible that the HIP association is end to end, while the IPsec SA is for encryption between the HIP host and a security gateway. In the case of a security gateway ESP association, the ESP always uses tunnel mode.
在策略重叠的情况下，传出数据包可能由IPsec和HIP处理。在这种情况下，HIP关联可能是端到端的，而IPsec SA用于HIP主机和安全网关之间的加密。对于安全网关ESP关联，ESP始终使用隧道模式。
In the case of IPsec tunnel mode, it is hard to see during the HIP SA processing if the IPsec ESP SA has the same final destination. Thus, traffic MUST be encrypted with both the HIP ESP SA and the IPsec SA when the IPsec ESP SA is used in tunnel mode.
在IPsec隧道模式的情况下，在HIP SA处理期间很难看到IPsec ESP SA是否具有相同的最终目的地。因此，在隧道模式下使用IPsec ESP SA时，必须使用HIP ESP SA和IPsec SA对通信量进行加密。
In the case of IPsec transport mode, the connection endpoints are the same. However, for HIP data packets it is not possible to avoid HIP SA processing, while mapping the HIP data packet's IP addresses to the corresponding HITs requires SPI values from the ESP header. In the case of a transport mode IPsec SA, the IPsec encryption MAY be skipped to avoid double encryption, if the local policy allows.
在IPsec传输模式的情况下，连接端点是相同的。但是，对于HIP数据包，不可能避免HIP SA处理，而将HIP数据包的IP地址映射到相应的HITs需要来自ESP报头的SPI值。对于传输模式IPsec SA，如果本地策略允许，可以跳过IPsec加密以避免双重加密。
In general, HIP signaling packets should follow the same processing as HIP data packets.
通常，HIP信令分组应遵循与HIP数据分组相同的处理。
In the case of IPsec tunnel mode, the HIP signaling packets are always encrypted using an IPsec ESP SA. Note that this hides the HIP signaling packets from the eventual HIP middleboxes on the path between the originating host and the security gateway.
在IPsec隧道模式的情况下，HIP信令包始终使用IPsec ESP SA进行加密。请注意，这会在发起主机和安全网关之间的路径上对最终的HIP中间盒隐藏HIP信令数据包。
In the case of IPsec transport mode, the HIP signaling packets MAY skip the IPsec ESP SA encryption if the local policy allows. This allows the eventual HIP middleboxes to handle the passing HIP signaling packets.
在IPsec传输模式的情况下，如果本地策略允许，HIP信令包可以跳过IPsec ESP SA加密。这允许最终的HIP中间盒处理传递的HIP信令包。
In this section, the protocol for setting up an ESP association to be used with a HIP association is described.
在本节中，描述了设置ESP关联以与HIP关联一起使用的协议。
The HIP handshake signals the TRANSPORT_FORMAT_LIST parameter in the R1 and I2 messages. This parameter contains a list of the supported HIP transport formats of the sending host, in the order of preference. The transport format type for IPsec ESP is the type number of the ESP_TRANSFORM parameter, i.e., 4095.
HIP握手向R1和I2消息中的TRANSPORT_FORMAT_LIST参数发送信号。此参数包含发送主机支持的HIP传输格式列表，按首选顺序排列。IPsec ESP的传输格式类型是ESP_转换参数的类型号，即4095。
Setting up an ESP Security Association between hosts using HIP is performed by including parameters in the last three messages (R1, I2, and R2 messages) of the four-message HIP base exchange.
使用HIP在主机之间建立ESP安全关联是通过在四消息HIP基本交换的最后三条消息（R1、I2和R2消息）中包含参数来执行的。
Initiator Responder
发起者响应者
I1
---------------------------------->
I1
---------------------------------->
R1: ESP_TRANSFORM
<----------------------------------
R1: ESP_TRANSFORM
<----------------------------------
I2: ESP_TRANSFORM, ESP_INFO
---------------------------------->
I2: ESP_TRANSFORM, ESP_INFO
---------------------------------->
R2: ESP_INFO
<----------------------------------
R2: ESP_INFO
<----------------------------------
The R1 message contains the ESP_TRANSFORM parameter, in which the sending host defines the possible ESP transforms it is willing to use for the ESP SA.
R1消息包含ESP_TRANSFORM参数，在该参数中，发送主机定义其愿意用于ESP SA的可能ESP转换。
Including the ESP_TRANSFORM parameter in the R1 message adds clarity to the TRANSPORT_FORMAT_LIST but may initiate negotiations for possibly unselected transforms. However, resource-constrained devices will most likely restrict support to a single transform for the sake of minimizing ROM overhead, and the additional parameter adds negligible overhead with unconstrained devices.
在R1消息中包含ESP_TRANSFORM参数可增加传输_格式_列表的清晰度，但可能会启动可能未选择的转换的协商。但是，资源受限的设备很可能会为了最小化ROM开销而将支持限制为单个转换，并且附加参数会为无约束设备增加可忽略的开销。
The I2 message contains the response to an ESP_TRANSFORM received in the R1 message. The sender must select one of the proposed ESP transforms from the ESP_TRANSFORM parameter in the R1 message and include the selected one in the ESP_TRANSFORM parameter in the I2 packet. In addition to the transform, the host includes the ESP_INFO parameter containing the SPI value to be used by the peer host.
I2消息包含对R1消息中接收到的ESP_转换的响应。发送方必须从R1消息中的ESP_转换参数中选择一个建议的ESP转换，并将所选转换包含在I2数据包中的ESP_转换参数中。除了转换之外，主机还包括包含对等主机使用的SPI值的ESP_INFO参数。
In the R2 message, the ESP SA setup is finalized. The packet contains the SPI information required by the Initiator for the ESP SA.
在R2消息中，ESP SA设置完成。该数据包包含ESP SA启动器所需的SPI信息。
The update process is accomplished using three messages. The HIP UPDATE message is used to update the parameters of an existing ESP SA. The UPDATE mechanism and message are defined in [RFC7401], and the additional parameters for updating an existing ESP SA are described here.
更新过程使用三条消息完成。HIP更新消息用于更新现有ESP SA的参数。[RFC7401]中定义了更新机制和消息，此处描述了更新现有ESP SA的附加参数。
The following picture shows a typical exchange when an existing ESP SA is updated. Messages include SEQ and ACK parameters required by the UPDATE mechanism.
下图显示了更新现有ESP SA时的典型交换。消息包括更新机制所需的SEQ和ACK参数。
H1 H2
UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN]
----------------------------------------------------->
H1 H2
UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN]
----------------------------------------------------->
UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN]
<-----------------------------------------------------
UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN]
<-----------------------------------------------------
UPDATE: ACK
----------------------------------------------------->
UPDATE: ACK
----------------------------------------------------->
The host willing to update the ESP SA creates and sends an UPDATE message. The message contains the ESP_INFO parameter containing the old SPI value that was used, the new SPI value to be used, and the index value for the keying material, giving the point from where the next keys will be drawn. If new keying material must be generated, the UPDATE message will also contain the DIFFIE_HELLMAN parameter defined in [RFC7401].
愿意更新ESP SA的主机创建并发送更新消息。该消息包含ESP_INFO参数，该参数包含已使用的旧SPI值、要使用的新SPI值以及关键帧材质的索引值，给出下一个关键帧的绘制点。如果必须生成新的键控材料，更新消息还将包含[RFC7401]中定义的DIFFIE_HELLMAN参数。
The host receiving the UPDATE message requesting update of an existing ESP SA MUST reply with an UPDATE message. In the reply message, the host sends the ESP_INFO parameter containing the corresponding values: old SPI, new SPI, and the keying material index. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter, the reply packet MUST also contain a DIFFIE_HELLMAN parameter.
接收请求更新现有ESP SA的更新消息的主机必须回复更新消息。在回复消息中，主机发送包含相应值的ESP_INFO参数：旧SPI、新SPI和键控材质索引。如果传入更新包含DIFFIE_HELLMAN参数，则应答数据包还必须包含DIFFIE_HELLMAN参数。
In this section, new and modified HIP parameters are presented, as well as modified HIP packets.
本节介绍了新的和修改后的HIP参数，以及修改后的HIP数据包。
Two HIP parameters are defined for setting up ESP transport format associations in HIP communication and for rekeying existing ones. Also, the NOTIFICATION parameter, described in [RFC7401], has two error values defined for this specification.
定义了两个HIP参数，用于在HIP通信中设置ESP传输格式关联和重新键入现有关联。此外，[RFC7401]中描述的通知参数具有为此规范定义的两个错误值。
Parameter Type Length Data
参数类型长度数据
ESP_INFO 65 12 Remote's old SPI, new SPI, and other info ESP_TRANSFORM 4095 variable ESP Encryption and Authentication Transform(s)
ESP_INFO 65 12远程的旧SPI、新SPI和其他信息ESP_TRANSFORM 4095变量ESP加密和身份验证转换
During the establishment and update of an ESP SA, the SPI value of both hosts must be transmitted between the hosts. In addition, hosts need the index value to the KEYMAT when they are drawing keys from the generated keying material. The ESP_INFO parameter is used to transmit the SPI values and the KEYMAT index information between the hosts.
在建立和更新ESP SA期间，两台主机的SPI值必须在主机之间传输。此外，主机在从生成的关键帧材质绘制关键帧时，需要将索引值添加到关键帧。ESP_INFO参数用于在主机之间传输SPI值和键盘索引信息。
During the initial ESP SA setup, the hosts send the SPI value that they want the peer to use when sending ESP data to them. The value is set in the NEW SPI field of the ESP_INFO parameter. In the initial setup, an old value for the SPI does not exist; thus, the OLD SPI field value is set to zero. The OLD SPI field value may also be zero when additional SAs are set up between HIP hosts, e.g., in the case of multihomed HIP hosts [RFC5206]. However, such use is beyond the scope of this specification.
在初始ESP SA设置期间，主机发送希望对等机在向其发送ESP数据时使用的SPI值。该值在ESP_INFO参数的新SPI字段中设置。在初始设置中，SPI的旧值不存在；因此，旧SPI字段值设置为零。当在HIP主机之间设置其他SA时，旧SPI字段值也可能为零，例如，在多宿HIP主机的情况下[RFC5206]。但是，此类使用超出了本规范的范围。
The KEYMAT index value points to the place in the KEYMAT from where the keying material for the ESP SAs is drawn. The KEYMAT index value is zero only when the ESP_INFO is sent during a rekeying process and new keying material is generated.
KEYMAT索引值指向KEYMAT中用于绘制ESP SAs的键控材质的位置。只有在重新键入过程中发送ESP_信息并生成新的键入材料时，KEYMAT索引值才为零。
During the life of an SA established by HIP, one of the hosts may need to reset the Sequence Number to one and rekey. The reason for rekeying might be an approaching sequence number wrap in ESP, or a local policy on the use of a key. Rekeying ends the current SAs and starts new ones on both peers.
在HIP建立的SA的生命周期内，其中一个主机可能需要将序列号重置为1并重新设置密钥。重新设置密钥的原因可能是ESP中接近的序列号换行，或者是使用密钥的本地策略。重新键入结束当前SA并在两个对等机上启动新SA。
During the rekeying process, the ESP_INFO parameter is used to transmit the changed SPI values and the keying material index.
在重新键入过程中，ESP_INFO参数用于传输更改的SPI值和键入材料索引。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | KEYMAT Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLD SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEW SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | KEYMAT Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLD SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEW SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65 Length 12 KEYMAT Index index, in bytes, where to continue to draw ESP keys from KEYMAT. If the packet includes a new Diffie-Hellman key and the ESP_INFO is sent in an UPDATE packet, the field MUST be zero. If the ESP_INFO is included in base exchange messages, the KEYMAT Index must have the index value of the point from where the ESP SA keys are drawn. Note that the length of this field limits the amount of keying material that can be drawn from KEYMAT. If that amount is exceeded, the packet MUST contain a new Diffie-Hellman key. OLD SPI old SPI for data sent to address(es) associated with this SA. If this is an initial SA setup, the OLD SPI value is zero. NEW SPI new SPI for data sent to address(es) associated with this SA.
键入65长度12 KEYMAT索引，以字节为单位，从中继续从KEYMAT绘制ESP键。如果数据包包含新的Diffie-Hellman密钥，且ESP_信息在更新数据包中发送，则该字段必须为零。如果基本交换消息中包含ESP_信息，则KEYMAT索引必须具有从中绘制ESP SA键的点的索引值。请注意，此字段的长度限制了可以从KEYMAT中提取的关键帧材质的数量。如果超过该数量，则数据包必须包含新的Diffie-Hellman密钥。OLD SPI发送到与此SA关联的地址的数据的OLD SPI。如果这是初始SA设置，则旧SPI值为零。新SPI发送到与此SA关联的地址的数据的新SPI。
The ESP_TRANSFORM parameter is used during ESP SA establishment. The first party sends a selection of transform families in the ESP_TRANSFORM parameter, and the peer must select one of the proposed values and include it in the response ESP_TRANSFORM parameter.
ESP_TRANSFORM参数在ESP SA建立过程中使用。第一方在ESP_变换参数中发送变换族选择，对等方必须选择其中一个建议值并将其包含在响应ESP_变换参数中。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Suite ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite ID #2 | Suite ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Suite ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite ID #2 | Suite ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4095 Length length in octets, excluding Type, Length, and padding. Reserved zero when sent, ignored when received. Suite ID defines the ESP Suite to be used.
键入4095长度八位字节，不包括类型、长度和填充。发送时保留零，接收时忽略。套件ID定义要使用的ESP套件。
The following Suite IDs can be used:
可以使用以下套件ID：
Suite ID Value
套件ID值
RESERVED 0 [RFC7402]
AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404]
DEPRECATED 2 [RFC7402]
DEPRECATED 3 [RFC7402]
DEPRECATED 4 [RFC7402]
DEPRECATED 5 [RFC7402]
DEPRECATED 6 [RFC7402]
NULL with HMAC-SHA-256 7 [RFC2410], [RFC4868]
AES-128-CBC with HMAC-SHA-256 8 [RFC3602], [RFC4868]
AES-256-CBC with HMAC-SHA-256 9 [RFC3602], [RFC4868]
AES-CCM-8 10 [RFC4309]
AES-CCM-16 11 [RFC4309]
AES-GCM with an 8-octet ICV 12 [RFC4106]
AES-GCM with a 16-octet ICV 13 [RFC4106]
AES-CMAC-96 14 [RFC4493], [RFC4494]
AES-GMAC 15 [RFC4543]
RESERVED 0 [RFC7402]
AES-128-CBC with HMAC-SHA1 1 [RFC3602], [RFC2404]
DEPRECATED 2 [RFC7402]
DEPRECATED 3 [RFC7402]
DEPRECATED 4 [RFC7402]
DEPRECATED 5 [RFC7402]
DEPRECATED 6 [RFC7402]
NULL with HMAC-SHA-256 7 [RFC2410], [RFC4868]
AES-128-CBC with HMAC-SHA-256 8 [RFC3602], [RFC4868]
AES-256-CBC with HMAC-SHA-256 9 [RFC3602], [RFC4868]
AES-CCM-8 10 [RFC4309]
AES-CCM-16 11 [RFC4309]
AES-GCM with an 8-octet ICV 12 [RFC4106]
AES-GCM with a 16-octet ICV 13 [RFC4106]
AES-CMAC-96 14 [RFC4493], [RFC4494]
AES-GMAC 15 [RFC4543]
The sender of an ESP transform parameter MUST make sure that there are no more than six (6) Suite IDs in one ESP transform parameter. Conversely, a recipient MUST be prepared to handle received transform parameters that contain more than six Suite IDs. The limited number of Suite IDs sets the maximum size of the ESP_TRANSFORM parameter. As the default configuration, the ESP_TRANSFORM parameter MUST contain at least one of the mandatory Suite IDs. There MAY be a configuration option that allows the administrator to override this default.
ESP转换参数的发送方必须确保一个ESP转换参数中的套件ID不超过六（6）个。相反，收件人必须准备好处理接收到的包含六个以上套件ID的转换参数。有限数量的套件ID设置ESP_转换参数的最大大小。作为默认配置，ESP_TRANSFORM参数必须至少包含一个必需的套件ID。可能存在允许管理员覆盖此默认值的配置选项。
Mandatory implementations: AES-128-CBC with HMAC-SHA-256. NULL with HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5).
强制实施：AES-128-CBC和HMAC-SHA-256。HMAC-SHA-256也应支持NULL（另见第3.3.5节）。
Under some conditions, it is possible to use Traffic Flow Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the definition of such an operation is left for future work and must be done in a separate specification.
在某些情况下，可以在BEET模式下使用ESP的交通流机密性（TFC）[RFC4303]。但是，此类操作的定义留待将来的工作，必须在单独的规范中完成。
The HIP base specification defines a set of NOTIFICATION error types. The following error types are required for describing errors in ESP Transform crypto suites during negotiation.
HIP base规范定义了一组通知错误类型。以下错误类型是描述协商期间ESP Transform crypto Suite中的错误所必需的。
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
NO_ESP_PROPOSAL_CHOSEN 18
没有选择ESP建议18
None of the proposed ESP Transform crypto suites was acceptable.
建议的ESP转换加密套件均不可接受。
INVALID_ESP_TRANSFORM_CHOSEN 19
无效的\u ESP\u转换\u选择19
The ESP Transform crypto suite does not correspond to one offered by the Responder.
ESP转换加密套件与响应者提供的套件不对应。
The ESP Security Association is set up during the base exchange. The following subsections define the ESP SA setup procedure using both base exchange messages (R1, I2, R2) and UPDATE messages.
ESP安全关联是在基本交换期间建立的。以下小节使用基本交换消息（R1、I2、R2）和更新消息定义ESP SA设置过程。
The ESP_TRANSFORM contains the ESP modes supported by the sender, in the order of preference. All implementations MUST support AES-128-CBC [RFC3602] with HMAC-SHA-256 [RFC4868].
ESP_转换按优先顺序包含发送方支持的ESP模式。所有实施必须支持AES-128-CBC[RFC3602]和HMAC-SHA-256[RFC4868]。
The following figure shows the resulting R1 packet layout.
下图显示了生成的R1数据包布局。
The HIP parameters for the R1 packet:
R1数据包的HIP参数：
IP ( HIP ( [ R1_COUNTER, ] PUZZLE, DIFFIE_HELLMAN, HIP_CIPHER, ESP_TRANSFORM, HOST_ID, [ ECHO_REQUEST, ] HIP_SIGNATURE_2 ) [, ECHO_REQUEST ])
IP（HIP（[R1\u计数器，]PUZZLE，DIFFIE\u HELLMAN，HIP\u密码，ESP\u转换，主机ID，[ECHO\u请求，]HIP\u签名\u 2）[，ECHO\u请求]）
The ESP_INFO contains the sender's SPI for this association as well as the KEYMAT index from where the ESP SA keys will be drawn. The old SPI value is set to zero.
ESP_信息包含此关联的发送方SPI以及从中提取ESP SA密钥的KEYMAT索引。旧SPI值设置为零。
The ESP_TRANSFORM contains the ESP mode selected by the sender of R1. All implementations MUST support AES-128-CBC [RFC3602] with HMAC-SHA-256 [RFC4868].
ESP_转换包含R1发送方选择的ESP模式。所有实施必须支持AES-128-CBC[RFC3602]和HMAC-SHA-256[RFC4868]。
The following figure shows the resulting I2 packet layout.
下图显示了生成的I2数据包布局。
The HIP parameters for the I2 packet:
I2数据包的HIP参数：
IP ( HIP ( ESP_INFO,
[R1_COUNTER,]
SOLUTION,
DIFFIE_HELLMAN,
HIP_CIPHER,
ESP_TRANSFORM,
ENCRYPTED { HOST_ID },
[ ECHO_RESPONSE ,]
HMAC,
HIP_SIGNATURE
[, ECHO_RESPONSE] ) )
IP ( HIP ( ESP_INFO,
[R1_COUNTER,]
SOLUTION,
DIFFIE_HELLMAN,
HIP_CIPHER,
ESP_TRANSFORM,
ENCRYPTED { HOST_ID },
[ ECHO_RESPONSE ,]
HMAC,
HIP_SIGNATURE
[, ECHO_RESPONSE] ) )
The R2 contains an ESP_INFO parameter, which has the SPI value of the sender of the R2 for this association. The ESP_INFO also has the KEYMAT index value specifying where the ESP SA keys are drawn.
R2包含一个ESP_INFO参数，该参数具有此关联R2的发送方的SPI值。ESP_信息还具有KEYMAT索引值，用于指定ESP SA键的绘制位置。
The following figure shows the resulting R2 packet layout.
下图显示了生成的R2数据包布局。
The HIP parameters for the R2 packet:
R2数据包的HIP参数：
IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) )
IP（HIP（ESP_信息、HMAC_2、HIP_签名））
In this section, the procedure for rekeying an existing ESP SA is presented.
本节介绍了为现有ESP SA重新设置密钥的过程。
Conceptually, the process can be represented by the following message sequence using the host names I' and R' defined in Section 3.3.2. For simplicity, HMAC and HIP_SIGNATURE are not depicted, and DIFFIE_HELLMAN keys are optional. The UPDATE with ACK_I need not be piggybacked with the UPDATE with SEQ_R; it may be ACKed separately (in which case the sequence would include four packets).
从概念上讲，该过程可以使用第3.3.2节中定义的主机名I'和R'通过以下消息序列表示。为简单起见，未描述HMAC和HIP_签名，DIFFIE_HELLMAN键是可选的。带有ACK_I的更新不需要与带有SEQ_R的更新一起进行；它可以单独确认（在这种情况下，序列将包括四个数据包）。
I' R'
我是
UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN])
<-----------------------------------
UPDATE(ACK_R)
----------------------------------->
UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN])
<-----------------------------------
UPDATE(ACK_R)
----------------------------------->
Below, the first two packets in this figure are explained.
下面，解释该图中的前两个分组。
When HIP is used with ESP, the UPDATE packet is used to initiate rekeying. The UPDATE packet MUST carry an ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter.
当HIP与ESP一起使用时，更新数据包用于启动密钥更新。更新数据包必须携带ESP_信息，并且可能携带DIFFIE_HELLMAN参数。
Intermediate systems that use the SPI will have to inspect HIP packets for those that carry rekeying information. The packet is signed for the benefit of the intermediate systems. Since intermediate systems may need the new SPI values, the contents cannot be encrypted.
使用SPI的中间系统必须检查HIP数据包中是否有携带密钥更新信息的数据包。为了中间系统的利益，对数据包进行签名。由于中间系统可能需要新的SPI值，因此无法对内容进行加密。
The following figure shows the contents of a rekeying initialization UPDATE packet.
下图显示了重新键入初始化更新数据包的内容。
The HIP parameters for the UPDATE packet initiating rekeying:
更新包启动密钥更新的HIP参数：
IP ( HIP ( ESP_INFO, SEQ, [DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) )
IP（HIP（ESP_信息，序号，[DIFFIE_HELLMAN，]HMAC，HIP_签名））
The UPDATE ACK is used to acknowledge the received UPDATE rekeying initialization. The acknowledgment UPDATE packet MUST carry an ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter.
更新确认用于确认接收到的更新密钥更新初始化。确认更新数据包必须携带ESP_信息，并可能携带DIFFIE_HELLMAN参数。
Intermediate systems that use the SPI will have to inspect HIP packets for packets carrying rekeying information. The packet is signed for the benefit of the intermediate systems. Since intermediate systems may need the new SPI values, the contents cannot be encrypted.
使用SPI的中间系统必须检查HIP数据包中是否有携带密钥更新信息的数据包。为了中间系统的利益，对数据包进行签名。由于中间系统可能需要新的SPI值，因此无法对内容进行加密。
The following figure shows the contents of a rekeying acknowledgment UPDATE packet.
下图显示了重新键入确认更新数据包的内容。
The HIP parameters for the UPDATE packet:
更新数据包的HIP参数：
IP ( HIP ( ESP_INFO, SEQ, ACK, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) )
IP（HIP（ESP_信息，序列，确认，[DIFFIE_HELLMAN，]HMAC，HIP_签名））
ICMP message handling is mainly described in the HIP base specification [RFC7401]. In this section, we describe the actions related to ESP security associations.
ICMP消息处理主要在HIP基本规范[RFC7401]中描述。在本节中，我们将描述与ESP安全关联相关的操作。
If a HIP implementation receives an ESP packet that has an unrecognized SPI number, it MAY respond (subject to rate limiting the responses) with an ICMP packet with type "Parameter Problem", with the pointer pointing to the beginning of the SPI field in the ESP header.
如果HIP实现接收到具有无法识别的SPI号的ESP数据包，它可能会使用类型为“Parameter Problem”的ICMP数据包进行响应（受响应速率限制），指针指向ESP报头中SPI字段的开头。
Packet processing is mainly defined in the HIP base specification [RFC7401]. This section describes the changes and new requirements for packet handling when the ESP transport format is used. Note that all HIP packets (currently protocol 139) MUST bypass ESP processing.
数据包处理主要在HIP base规范[RFC7401]中定义。本节描述了使用ESP传输格式时对数据包处理的更改和新要求。请注意，所有HIP数据包（当前为协议139）必须绕过ESP处理。
Outgoing application data handling is specified in the HIP base specification [RFC7401]. When the ESP transport format is used, and there is an active HIP session for the given < source, destination > HIT pair, the outgoing datagram is protected using the ESP security association. The following additional steps define the conceptual processing rules for outgoing ESP protected datagrams.
HIP基本规范[RFC7401]中规定了传出应用程序数据处理。当使用ESP传输格式，并且给定的<source，destination>命中对存在活动HIP会话时，传出数据报将使用ESP安全关联进行保护。以下附加步骤定义了传出ESP保护数据报的概念处理规则。
1. Detect the proper ESP SA using the HITs in the packet header or other information associated with the packet.
1. 使用数据包头中的点击或与数据包相关的其他信息检测正确的ESP SA。
2. Process the packet normally, as if the SA was a transport mode SA.
2. 正常处理数据包，就像SA是传输模式SA一样。
3. Ensure that the outgoing ESP protected packet has proper IP header format, depending on the used IP address family, and proper IP addresses in its IP header, e.g., by replacing HITs left by the ESP processing. Note that this placement of proper IP addresses MAY also be performed at some other point in the stack, e.g., before ESP processing.
3. 确保受ESP保护的传出数据包具有正确的IP头格式（取决于使用的IP地址系列），并在其IP头中具有正确的IP地址，例如，通过替换ESP处理留下的命中数。请注意，适当IP地址的放置也可以在堆栈中的某个其他点执行，例如，在ESP处理之前。
Incoming HIP user data packets arrive as ESP protected packets. In the usual case, the receiving host has a corresponding ESP security association, identified by the SPI and destination IP address in the packet. However, if the host has crashed or otherwise lost its HIP state, it may not have such an SA.
传入的HIP用户数据包作为受ESP保护的数据包到达。在通常情况下，接收主机具有相应的ESP安全关联，由数据包中的SPI和目标IP地址标识。但是，如果主机已崩溃或以其他方式失去HIP状态，则它可能没有这样的SA。
The basic incoming data handling is specified in the HIP base specification. Additional steps are required when ESP is used for protecting the data traffic. The following steps define the conceptual processing rules for incoming ESP protected datagrams targeted to an ESP security association created with HIP.
HIP base规范中规定了基本的传入数据处理。当ESP用于保护数据流量时，需要执行其他步骤。以下步骤定义了针对使用HIP创建的ESP安全关联的传入ESP保护数据报的概念处理规则。
1. Detect the proper ESP SA using the SPI. If the resulting SA is a non-HIP ESP SA, process the packet according to standard IPsec rules. If there are no SAs identified with the SPI, the host MAY send an ICMP packet as defined in Section 5.4. How to handle lost state is an implementation issue.
1. 使用SPI检测正确的ESP SA。如果生成的SA是非HIP ESP SA，请根据标准IPsec规则处理数据包。如果没有使用SPI标识的SA，主机可以发送第5.4节中定义的ICMP数据包。如何处理丢失状态是一个实现问题。
2. If the SPI matches with an active HIP-based ESP SA, the IP addresses in the datagram are replaced with the HITs associated with the SPI. Note that this IP-address-to-HIT conversion step MAY also be performed at some other point in the stack, e.g., after ESP processing. Note also that if the incoming packet has IPv4 addresses, the packet must be converted to IPv6 format before replacing the addresses with HITs (such that the transport checksum will pass if there are no errors).
2. 如果SPI与活动的基于HIP的ESP SA匹配，则数据报中的IP地址将替换为与SPI关联的命中。请注意，此IP地址到命中转换步骤也可在堆栈中的某个其他点执行，例如，在ESP处理之后。还请注意，如果传入数据包具有IPv4地址，则必须先将数据包转换为IPv6格式，然后再使用HITs替换地址（这样，如果没有错误，传输校验和将通过）。
3. The transformed packet is next processed normally by ESP, as if the packet were a transport mode packet. The packet may be dropped by ESP, as usual. In a typical implementation, the result of successful ESP decryption and verification is a datagram with the associated HITs as source and destination.
3. 转换后的数据包接下来由ESP正常处理，就像数据包是传输模式数据包一样。与往常一样，ESP可能会丢弃数据包。在一个典型的实现中，成功的ESP解密和验证的结果是一个数据报，其中关联的命中作为源和目标。
4. The datagram is delivered to the upper layer. Demultiplexing the datagram to the right upper-layer socket is performed as usual, except that the HITs are used in place of IP addresses during the demultiplexing.
4. 数据报被传送到上层。将数据报解复用到右上层套接字的操作与往常一样，除了在解复用过程中使用HITs代替IP地址之外。
The new HIP parameters described in this document, ESP_INFO and ESP_TRANSFORM, must be protected using HMAC and signature calculations. In a typical implementation, they are included in R1, I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as described in [RFC7401].
本文档中描述的新HIP参数ESP_INFO和ESP_TRANSFORM必须使用HMAC和签名计算进行保护。在典型实现中，它们包括在R1、I2、R2和更新数据包HMAC和签名计算中，如[RFC7401]所述。
The ESP SA setup is initialized in the R1 message. The receiving host (Initiator) selects one of the ESP transforms from the presented values. If no suitable value is found, the negotiation is terminated. The selected values are subsequently used when generating and using encryption keys, and when sending the reply packet. If the proposed alternatives are not acceptable to the system, it may abandon the ESP SA establishment negotiation, or it may resend the I1 message within the retry bounds.
ESP SA设置在R1消息中初始化。接收主机（启动器）从显示的值中选择一个ESP转换。如果没有找到合适的值，协商将终止。随后在生成和使用加密密钥以及发送应答包时使用所选值。如果系统不接受建议的备选方案，则可能放弃ESP SA建立协商，或者可能在重试范围内重新发送I1消息。
After selecting the ESP transform and performing other R1 processing, the system prepares and creates an incoming ESP security association. It may also prepare a security association for outgoing traffic, but since it does not have the correct SPI value yet, it cannot activate it.
选择ESP转换并执行其他R1处理后，系统准备并创建传入的ESP安全关联。它还可以为传出流量准备安全关联，但由于它还没有正确的SPI值，因此无法激活它。
The following steps are required to process the incoming ESP SA initialization replies in I2. The steps below assume that the I2 has been accepted for processing (e.g., has not been dropped due to HIT comparisons as described in [RFC7401]).
处理I2中传入的ESP SA初始化回复需要以下步骤。以下步骤假设I2已被接受处理（例如，未因[RFC7401]中所述的命中比较而丢弃）。
o The ESP_TRANSFORM parameter is verified, and it MUST contain a single value in the parameter; and it MUST match one of the values offered in the initialization packet.
o 验证ESP_TRANSFORM参数，参数中必须包含单个值；并且它必须与初始化数据包中提供的一个值匹配。
o The ESP_INFO NEW SPI field is parsed to obtain the SPI that will be used for the Security Association outbound from the Responder and inbound to the Initiator. For this initial ESP SA establishment, the old SPI value MUST be zero. The KEYMAT Index field MUST contain the index value to the KEYMAT from where the ESP SA keys are drawn.
o 对ESP_INFO NEW SPI字段进行分析，以获取将用于安全关联的SPI，该SPI将从响应程序出站并入站到启动器。对于此初始ESP SA建立，旧SPI值必须为零。KEYMAT索引字段必须包含从中绘制ESP SA键的KEYMAT的索引值。
o The system prepares and creates both incoming and outgoing ESP security associations.
o 系统准备并创建传入和传出ESP安全关联。
o Upon successful processing of the initialization reply message, the possible old Security Associations (as left over from an earlier incarnation of the HIP association) are dropped and the new ones are installed, and a finalizing packet, R2, is sent. Possible ongoing rekeying attempts are dropped.
o 成功处理初始化回复消息后，可能的旧安全关联（从HIP关联的早期版本遗留下来）被丢弃，新的安全关联被安装，并发送一个最终数据包R2。可能正在进行的密钥更新尝试被放弃。
Before the ESP SA can be finalized, the ESP_INFO NEW SPI field is parsed to obtain the SPI that will be used for the ESP Security Association inbound to the sender of the finalization message R2. The system uses this SPI to create or activate the outgoing ESP security association used for sending packets to the peer.
在完成ESP SA之前，将对ESP_INFO NEW SPI字段进行解析，以获取将用于ESP安全关联的SPI，该关联将入站到完成消息R2的发送方。系统使用此SPI创建或激活用于向对等方发送数据包的传出ESP安全关联。
When the system drops a HIP association, as described in the HIP base specification, the associated ESP SAs MUST also be dropped.
如HIP基本规范中所述，当系统删除HIP关联时，也必须删除关联的ESP SA。
During ESP SA rekeying, the hosts draw new keys from the existing keying material, or new keying material is generated from where the new keys are drawn.
在ESP SA重新设置关键帧期间，主机从现有关键帧材质绘制新关键帧，或者从绘制新关键帧的位置生成新关键帧材质。
A system may initiate the SA rekeying procedure at any time. It MUST initiate a rekey if its incoming ESP sequence counter is about to overflow. The system MUST NOT replace its keying material until the rekeying packet exchange successfully completes.
系统可随时启动SA密钥更新程序。如果传入的ESP序列计数器即将溢出，则必须启动重新密钥。在重新设置密钥的数据包交换成功完成之前，系统不得更换其密钥材料。
Optionally, a system may include a new Diffie-Hellman key for use in new KEYMAT generation. New KEYMAT generation occurs prior to drawing the new keys.
可选地，系统可包括用于新一代键盘的新Diffie-Hellman钥匙。在绘制新关键帧之前生成新的KEYMAT。
The rekeying procedure uses the UPDATE mechanism defined in [RFC7401]. Because each peer must update its half of the security association pair (including new SPI creation), the rekeying process requires that each side both send and receive an UPDATE. A system will then rekey the ESP SA when it has sent parameters to the peer and has received both an ACK of the relevant UPDATE message and corresponding peer's parameters. It may be that the ACK and the required HIP parameters arrive in different UPDATE messages. This is always true if a system does not initiate an ESP SA update but responds to an update request from the peer, and may also occur if two systems initiate update nearly simultaneously. In such a case, if the system has an outstanding update request, it saves the one parameter and waits for the other before completing rekeying.
密钥更新过程使用[RFC7401]中定义的更新机制。因为每个对等方都必须更新其安全关联对的一半（包括新的SPI创建），所以密钥更新过程要求每一方都发送和接收更新。当系统向对等方发送参数并接收到相关更新消息的ACK和相应对等方的参数时，系统将重新设置ESP SA的密钥。可能是ACK和所需的HIP参数在不同的更新消息中到达。如果一个系统不启动ESP SA更新，但响应来自对等方的更新请求，则这始终是正确的，如果两个系统几乎同时启动更新，也可能发生这种情况。在这种情况下，如果系统有一个未完成的更新请求，它将保存一个参数，并在完成重新键入之前等待另一个参数。
The following steps define the processing rules for initiating an ESP SA update:
以下步骤定义了启动ESP SA更新的处理规则：
1. The system decides whether to continue to use the existing KEYMAT or to generate a new KEYMAT. In the latter case, the system MUST generate a new Diffie-Hellman public key.
1. 系统决定是继续使用现有键盘垫还是生成新键盘垫。在后一种情况下，系统必须生成新的Diffie-Hellman公钥。
2. The system creates an UPDATE packet, which contains the ESP_INFO parameter. In addition, the host may include the optional DIFFIE_HELLMAN parameter. If the UPDATE contains the DIFFIE_HELLMAN parameter, the KEYMAT Index in the ESP_INFO parameter MUST be zero, and the Diffie-Hellman Group ID must be unchanged from that used in the initial handshake. If the UPDATE does not contain DIFFIE_HELLMAN, the ESP_INFO KEYMAT Index MUST be greater than or equal to the index of the next byte to be drawn from the current KEYMAT.
2. 系统将创建一个更新数据包，其中包含ESP_INFO参数。此外，主机可能包括可选的DIFFIE_HELLMAN参数。如果更新包含DIFFIE_HELLMAN参数，则ESP_INFO参数中的KEYMAT索引必须为零，并且DIFFIE HELLMAN组ID必须与初始握手中使用的ID保持不变。如果更新不包含DIFFIE_HELLMAN，则ESP_INFO键盘索引必须大于或等于从当前键盘提取的下一个字节的索引。
3. The system sends the UPDATE packet. For reliability, the underlying UPDATE retransmission mechanism MUST be used.
3. 系统发送更新包。为了保证可靠性，必须使用底层的更新重传机制。
4. The system MUST NOT delete its existing SAs, but continue using them if its policy still allows. The rekeying procedure SHOULD be initiated early enough to make sure that the SA replay counters do not overflow.
4. 系统不得删除其现有SA，但如果其策略仍然允许，则必须继续使用它们。应尽早启动密钥更新过程，以确保SA replay计数器不会溢出。
5. In case a protocol error occurs and the peer system acknowledges the UPDATE but does not itself send an ESP_INFO, the system may not finalize the outstanding ESP SA update request. To guard against this, a system MAY re-initiate the ESP SA update procedure after some time waiting for the peer to respond, or it MAY decide to abort the ESP SA after waiting for an implementation-dependent time. The system MUST NOT keep an outstanding ESP SA update request for an indefinite time.
5. 如果发生协议错误，对等系统确认更新，但自身未发送ESP_信息，则系统可能无法完成未完成的ESP SA更新请求。为了防止这种情况，系统可能会在等待对等方响应一段时间后重新启动ESP SA更新过程，或者在等待与实现相关的时间后决定中止ESP SA。系统不得无限期保留未完成的ESP SA更新请求。
To simplify the state machine, a host MUST NOT generate new UPDATEs while it has an outstanding ESP SA update request, unless it is restarting the update process.
为了简化状态机，主机在有未完成的ESP SA更新请求时不得生成新更新，除非它正在重新启动更新过程。
When a system receives an UPDATE packet, it must be processed if the following conditions hold (in addition to the generic conditions specified for UPDATE processing in Section 6.12 of [RFC7401]):
当系统接收到更新数据包时，如果满足以下条件，则必须对其进行处理（除了[RFC7401]第6.12节中规定的更新处理通用条件外）：
1. A corresponding HIP association must exist. This is usually ensured by the underlying UPDATE mechanism.
1. 必须存在相应的髋关节联合。这通常由底层的更新机制来保证。
2. The state of the HIP association is ESTABLISHED or R2-SENT.
2. 髋关节协会的状态已建立或已发送。
If the above conditions hold, the following steps define the conceptual processing rules for handling the received UPDATE packet:
如果上述条件成立，则以下步骤定义用于处理接收到的更新数据包的概念处理规则：
1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the received KEYMAT Index MUST be zero and the Group ID must match the Group ID in use on the association. If this test fails, the packet SHOULD be dropped and the system SHOULD log an error message.
1. 如果收到的更新包含DIFFIE_HELLMAN参数，则收到的KEYMAT索引必须为零，并且组ID必须与关联上使用的组ID匹配。如果此测试失败，则应丢弃数据包，系统应记录错误消息。
2. If there is no outstanding rekeying request, the packet processing continues as specified in Section 6.9.1.
2. 如果没有未完成的密钥更新请求，则按照第6.9.1节的规定继续进行数据包处理。
3. If there is an outstanding rekeying request, the UPDATE MUST be acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN) parameters must be saved, and the packet processing continues as specified in Section 6.10.
3. 如果存在未完成的密钥更新请求，则必须确认更新，必须保存收到的ESP_信息（以及可能的DIFFIE_HELLMAN）参数，并按照第6.10节的规定继续数据包处理。
The following steps define the conceptual processing rules for handling a received UPDATE packet with the ESP_INFO parameter:
以下步骤定义了使用ESP_INFO参数处理接收到的更新数据包的概念处理规则：
1. The system consults its policy to see if it needs to generate a new Diffie-Hellman key, and generates a new key (with same Group ID) if needed. The system records any newly generated or received Diffie-Hellman keys for use in KEYMAT generation upon finalizing the ESP SA update.
1. 系统参考其策略，查看是否需要生成新的Diffie-Hellman密钥，并在需要时生成新密钥（具有相同的组ID）。在完成ESP SA更新后，系统会记录任何新生成或接收的Diffie Hellman密钥，以便在生成密钥垫时使用。
2. If the system generated a new Diffie-Hellman key in the previous step, or if it received a DIFFIE_HELLMAN parameter, it sets the ESP_INFO KEYMAT Index to zero. Otherwise, the ESP_INFO KEYMAT Index MUST be greater than or equal to the index of the next byte to be drawn from the current KEYMAT. In this case, it is RECOMMENDED that the host use the KEYMAT Index requested by the peer in the received ESP_INFO.
2. 如果系统在上一步中生成了新的Diffie Hellman密钥，或者收到Diffie_Hellman参数，则会将ESP_INFO KEYMAT索引设置为零。否则，ESP_信息键盘索引必须大于或等于从当前键盘提取的下一个字节的索引。在这种情况下，建议主机在收到的ESP_信息中使用对等方请求的键盘索引。
3. The system creates an UPDATE packet, which contains an ESP_INFO parameter and the optional DIFFIE_HELLMAN parameter. This UPDATE would also typically acknowledge the peer's UPDATE with an ACK parameter, although a separate UPDATE ACK may be sent.
3. 系统创建一个更新包，其中包含一个ESP_INFO参数和可选的DIFFIE_HELLMAN参数。此更新通常也会使用ACK参数确认对等方的更新，尽管可能会发送单独的更新ACK。
4. The system sends the UPDATE packet and stores any received ESP_INFO and DIFFIE_HELLMAN parameters. At this point, it only needs to receive an acknowledgment for the newly sent UPDATE to finish the ESP SA update. In the usual case, the acknowledgment is handled by the underlying UPDATE mechanism.
4. 系统发送更新数据包并存储任何接收到的ESP_信息和DIFFIE_HELLMAN参数。此时，它只需要接收对新发送的更新的确认即可完成ESP SA更新。在通常情况下，确认由底层更新机制处理。
A system finalizes rekeying when it has both received the corresponding UPDATE acknowledgment packet from the peer and successfully received the peer's UPDATE. The following steps are taken:
当系统从对等方接收到相应的更新确认数据包并成功接收到对等方的更新时，系统完成密钥更新。采取以下步骤：
1. If the received UPDATE messages contain a new Diffie-Hellman key, the system has a new Diffie-Hellman key due to initiating an ESP SA update, or both, the system generates a new KEYMAT. If there is only one new Diffie-Hellman key, the old existing key is used as the other key.
1. 如果收到的更新消息包含新的Diffie-Hellman密钥，则系统由于启动ESP SA更新而具有新的Diffie-Hellman密钥，或者两者都具有，则系统将生成新的KEYMAT。如果只有一个新的Diffie-Hellman密钥，则使用现有的旧密钥作为另一个密钥。
2. If the system generated a new KEYMAT in the previous step, it sets the KEYMAT Index to zero, independent of whether the received UPDATE included a Diffie-Hellman key or not. If the system did not generate a new KEYMAT, it uses the greater KEYMAT Index of the two (sent and received) ESP_INFO parameters.
2. 如果系统在上一步中生成了一个新的KEYMAT，它会将KEYMAT索引设置为零，这与接收到的更新是否包含Diffie-Hellman密钥无关。如果系统未生成新的键盘，则使用两个（已发送和已接收）ESP_信息参数中较大的键盘索引。
3. The system draws keys for new incoming and outgoing ESP SAs, starting from the KEYMAT Index, and prepares new incoming and outgoing ESP SAs. The SPI for the outgoing SA is the new SPI value received in an ESP_INFO parameter. The SPI for the incoming SA was generated when the ESP_INFO was sent to the peer. The order of the keys retrieved from the KEYMAT during the rekeying process is similar to that described in Section 7. Note that only IPsec ESP keys are retrieved during the rekeying process, not the HIP keys.
3. 系统从KEYMAT索引开始为新的传入和传出ESP SA绘制键，并准备新的传入和传出ESP SA。传出SA的SPI是在ESP_INFO参数中接收到的新SPI值。传入SA的SPI是在向对等方发送ESP_信息时生成的。在重新设置钥匙的过程中，从键盘检索到的钥匙的顺序与第7节中描述的相似。请注意，在重新设置密钥的过程中，仅检索IPsec ESP密钥，而不是HIP密钥。
4. The system starts to send to the new outgoing SA and prepares to start receiving data on the new incoming SA. Once the system receives data on the new incoming SA, it may safely delete the old SAs.
4. 系统开始向新的传出SA发送数据，并准备开始接收新传入SA上的数据。一旦系统接收到新传入SA上的数据，它就可以安全地删除旧SA。
The processing of NOTIFY packets is described in the HIP base specification.
HIP基本规范中描述了通知数据包的处理。
The keying material is generated as described in the HIP base specification. During the base exchange, the initial keys are drawn from the generated material. After the HIP association keys have been drawn, the ESP keys are drawn in the following order:
键控材料按照HIP基座规范中的描述生成。在基本交换过程中，初始关键帧将从生成的材质中绘制。绘制髋部关联关键点后，将按以下顺序绘制ESP关键点：
SA-gl ESP encryption key for HOST_g's outgoing traffic
主机的传出流量的SA gl ESP加密密钥
SA-gl ESP authentication key for HOST_g's outgoing traffic
主机的传出流量的SA gl ESP身份验证密钥
SA-lg ESP encryption key for HOST_l's outgoing traffic
主机传出流量的SA lg ESP加密密钥
SA-lg ESP authentication key for HOST_l's outgoing traffic
主机传出流量的SA lg ESP身份验证密钥
HOST_g denotes the host with the greater HIT value, and HOST_l denotes the host with the lower HIT value. When HIT values are compared, they are interpreted as positive (unsigned) 128-bit integers in network byte order.
HOST_g表示命中值较大的主机，HOST_l表示命中值较低的主机。比较命中值时，它们将按网络字节顺序解释为正（无符号）128位整数。
The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 exchange. Subsequent rekeys using UPDATE will only draw the four ESP keys from KEYMAT. Section 6.9 describes the rules for reusing or regenerating KEYMAT based on the rekeying.
四个髋关节键仅在髋关节I1->R2交换期间从KEYMAT中绘制。随后使用UPDATE重新设置密钥将仅从KEYMAT中绘制四个ESP密钥。第6.9节描述了基于重新键入的键盘的重用或再生规则。
The number of bits drawn for a given algorithm is the "natural" size of the keys, as specified in Section 6.5 of [RFC7401].
根据[RFC7401]第6.5节的规定，为给定算法绘制的位数为密钥的“自然”大小。
In this document, the usage of ESP [RFC4303] between HIP hosts to protect data traffic is introduced. The security considerations for ESP are discussed in the ESP specification.
在本文档中，介绍了在HIP主机之间使用ESP[RFC4303]来保护数据流量。ESP规范中讨论了ESP的安全注意事项。
There are different ways to establish an ESP Security Association between two nodes. This can be done, e.g., using IKE [RFC7296]. This document specifies how the Host Identity Protocol is used to establish ESP Security Associations.
有不同的方法在两个节点之间建立ESP安全关联。这可以通过使用IKE[RFC7296]来实现。本文档指定如何使用主机标识协议建立ESP安全关联。
The following issues are new or have changed from the standard ESP usage:
以下问题是新问题，或与标准ESP用法不同：
o Initial keying material generation
o 初始键控材质生成
o Updating the keying material
o 更新键控材质
The initial keying material is generated using the Host Identity Protocol [RFC7401] using the Diffie-Hellman procedure. This document extends the usage of the UPDATE packet, defined in the base specification, to modify existing ESP SAs. The hosts may rekey, i.e., force the generation of new keying material using the Diffie-Hellman procedure. The initial setup of ESP SAs between the hosts is done during the base exchange, and the message exchange is protected using methods provided by the base exchange. Changes in connection parameters basically mean that the old ESP SA is removed and a new one is generated once the UPDATE message exchange has been completed. The message exchange is protected using the HIP association keys. Both HMAC and signing of packets are used.
使用主机标识协议[RFC7401]和Diffie-Hellman过程生成初始密钥材料。本文档扩展了基本规范中定义的更新数据包的用法，以修改现有的ESP SA。主机可以重新键控，即使用Diffie-Hellman过程强制生成新的键控材料。主机之间ESP SAs的初始设置在基本交换期间完成，消息交换使用基本交换提供的方法进行保护。连接参数的更改基本上意味着旧的ESP SA将被删除，并在更新消息交换完成后生成一个新的ESP SA。消息交换使用HIP关联键进行保护。使用HMAC和数据包签名。
The following changes to the "Host Identity Protocol (HIP) Parameters" registries have been made. In all cases, the changes updated the reference from [RFC5202] to this specification.
对“主机标识协议（HIP）参数”注册表进行了以下更改。在所有情况下，更改将参考从[RFC5202]更新为本规范。
This document defines two Parameter Types and two NOTIFY Message Types for the Host Identity Protocol [RFC7401].
本文档为主机标识协议[RFC7401]定义了两种参数类型和两种通知消息类型。
The parameters and their type numbers are defined in Sections 5.1.1 and 5.1.2, and they have been added to the "Parameter Types" namespace created by [RFC7401]. No new action regarding these values is required by this specification, other than updating the reference from [RFC5202] to this specification.
参数及其类型号在第5.1.1节和第5.1.2节中定义，并已添加到[RFC7401]创建的“参数类型”命名空间中。除了将参考从[RFC5202]更新到本规范外，本规范不要求对这些值采取新的措施。
The new NOTIFICATION error types and their values are defined in Section 5.1.3, and they have been added to the "Notify Message Types" namespace created by [RFC7401]. No new action regarding these values is required by this specification, other than updating the reference from [RFC5202] to this specification.
第5.1.3节定义了新的通知错误类型及其值，并将其添加到[RFC7401]创建的“通知消息类型”命名空间中。除了将参考从[RFC5202]更新到本规范外，本规范不要求对这些值采取新的措施。
Section 5.1.2 of this document defines values for "ESP Transform Suite IDs", which are registered in a new IANA registry, with an "IETF Review" registration procedure [RFC5226] for new values.
本文件第5.1.2节定义了“ESP转换套件ID”的值，这些ID在新的IANA注册表中注册，新值采用“IETF审查”注册程序[RFC5226]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998, <http://www.rfc-editor.org/info/rfc2404>.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月<http://www.rfc-editor.org/info/rfc2404>.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998, <http://www.rfc-editor.org/info/rfc2410>.
[RFC2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月<http://www.rfc-editor.org/info/rfc2410>.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003, <http://www.rfc-editor.org/info/rfc3602>.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月<http://www.rfc-editor.org/info/rfc3602>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005, <http://www.rfc-editor.org/ info/rfc4106>.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效载荷（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月<http://www.rfc-editor.org/ 信息/rfc4106>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005, <http://www.rfc-editor.org/ info/rfc4303>.
[RFC4303]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4303，2005年12月<http://www.rfc-editor.org/ 信息/rfc4303>。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005, <http://www.rfc-editor.org/ info/rfc4309>.
[RFC4309]Housley，R.，“使用高级加密标准（AES）CCM模式和IPsec封装安全有效载荷（ESP）”，RFC 4309，2005年12月<http://www.rfc-editor.org/ 信息/rfc4309>。
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, June 2006, <http://www.rfc-editor.org/info/rfc4493>.
[RFC4493]Song，JH.，Poovendran，R.，Lee，J.，和T.Iwata，“AES-CMAC算法”，RFC 44932006年6月<http://www.rfc-editor.org/info/rfc4493>.
[RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 Algorithm and Its Use with IPsec", RFC 4494, June 2006, <http://www.rfc-editor.org/info/rfc4494>.
[RFC4494]Song，JH.，Poovendran，R.，和J.Lee，“AES-CMAC-96算法及其与IPsec的使用”，RFC 44942006年6月<http://www.rfc-editor.org/info/rfc4494>.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006, <http://www.rfc-editor.org/info/rfc4543>.
[RFC4543]McGrew，D.和J.Viega，“在IPsec ESP和AH中使用Galois消息认证码（GMAC）”，RFC 4543，2006年5月<http://www.rfc-editor.org/info/rfc4543>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，2007年5月<http://www.rfc-editor.org/info/rfc4868>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, April 2015, <http://www.rfc-editor.org/ info/rfc7401>.
[RFC7401]Moskowitz，R.，Ed.，Heer，T.，Jokela，P.，和T.Henderson，“主机身份协议版本2（HIPv2）”，RFC 7401，2015年4月<http://www.rfc-editor.org/ 信息/rfc7401>。
[HIP-ARCH] Moskowitz, R., Ed., and M. Komu, "Host Identity Protocol Architecture", Work in Progress, draft-ietf-hip-rfc4423-bis-09, October 2014.
[HIP-ARCH]Moskowitz，R.，Ed.，和M.Komu，“主机身份协议体系结构”，正在进行的工作，草稿-ietf-HIP-rfc4423-bis-092014年10月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月<http://www.rfc-editor.org/info/rfc791>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月<http://www.rfc-editor.org/info/rfc4301>.
[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, <http://www.rfc-editor.org/info/rfc5202>.
[RFC5202]Jokela，P.，Moskowitz，R.，和P.Nikander，“将封装安全有效载荷（ESP）传输格式与主机标识协议（HIP）结合使用”，RFC 52022008年4月<http://www.rfc-editor.org/info/rfc5202>.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008, <http://www.rfc-editor.org/info/rfc5206>.
[RFC5206]Nikander，P.，Henderson，T.，Vogt，C.，和J.Arkko，“使用主机身份协议的终端主机移动性和多宿”，RFC 52062008年4月<http://www.rfc-editor.org/info/rfc5206>.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008, <http://www.rfc-editor.org/info/rfc5207>.
[RFC5207]Stieemerling，M.，Quittek，J.，和L.Eggert，“主机身份协议（HIP）通信的NAT和防火墙穿越问题”，RFC 5207，2008年4月<http://www.rfc-editor.org/info/rfc5207>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[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, <http://www.rfc-editor.org/info/rfc5770>.
[RFC5770]Komu，M.，Henderson，T.，Tschofenig，H.，Melen，J.，和A.Keranen，“用于遍历网络地址转换器的基本主机标识协议（HIP）扩展”，RFC 57702010年4月<http://www.rfc-editor.org/info/rfc5770>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
It is possible to implement this specification in multiple different ways. As noted above, one possible way of implementing this is to rewrite IP headers below IPsec. In such an implementation, IPsec is used as if it was processing IPv6 transport mode packets, with the IPv6 header containing HITs instead of IP addresses in the source and destination address fields. In outgoing packets, after IPsec processing, the HITs are replaced with actual IP addresses, based on the HITs and the SPI. In incoming packets, before IPsec processing, the IP addresses are replaced with HITs, based on the SPI in the incoming packet. In such an implementation, all IPsec policies are based on HITs and the upper layers only see packets with HITs in the place of IP addresses. Consequently, support of HIP does not conflict with other uses of IPsec as long as the SPI spaces are kept separate. Appendix B describes another way to implement this specification.
可以通过多种不同的方式实现此规范。如上所述，实现这一点的一种可能方法是在IPsec下重写IP头。在这样的实现中，IPsec的使用就像它在处理IPv6传输模式数据包一样，IPv6报头在源地址和目标地址字段中包含命中而不是IP地址。在传出数据包中，经过IPsec处理后，根据HITs和SPI将HITs替换为实际IP地址。在传入数据包中，在IPsec处理之前，IP地址将根据传入数据包中的SPI替换为HITs。在这样的实现中，所有IPsec策略都基于命中，上层只看到在IP地址位置有命中的数据包。因此，只要SPI空间保持分离，HIP的支持就不会与IPsec的其他用途发生冲突。附录B描述了实施本规范的另一种方法。
This section introduces an alternative way of implementing the necessary functions for HIP ESP transport. Compared to the option of implementing the required address rewrites outside of IPsec, BEET has one implementation-level benefit. In a BEET-mode-based implementation, the address-rewriting information is kept in one place, at the SAD. On the other hand, when address rewriting is implemented separately, the implementation MUST make sure that the information in the SAD and the information in the separate address-rewriting database are kept in synchrony. As a result, the BEET-mode-based way of implementing this specification is RECOMMENDED over the separate implementation, as it binds the identities, encryption, and locators tightly together. It should be noted that implementing BEET mode doesn't require that corresponding hosts implement it, as the behavior is only visible internally in a host.
本节介绍实现HIP ESP传输所需功能的替代方法。与在IPsec之外实现所需地址重写的选项相比，BEET有一个实现级别的优势。在基于BEET模式的实现中，地址重写信息保存在SAD的一个位置。另一方面，当单独实现地址重写时，实现必须确保SAD中的信息与单独地址重写数据库中的信息保持同步。因此，建议使用基于BEET模式的方法来实现本规范，而不是单独实现，因为它将身份、加密和定位器紧密地结合在一起。应该注意的是，实现BEET模式并不要求相应的主机实现它，因为该行为仅在主机内部可见。
BEET mode is a combination of IPsec tunnel and transport modes, and it provides some of the features from both. HIP uses HITs as the "inner" addresses and IP addresses as "outer" addresses, like IP addresses are used in tunnel mode. Instead of tunneling packets between hosts, a conversion between inner and outer addresses is made at end hosts, and the inner address is never sent on the wire after the initial HIP negotiation. BEET provides IPsec transport mode syntax (no inner headers) with limited tunnel mode semantics (fixed logical inner addresses -- the HITs -- and changeable outer IP addresses).
BEET模式是IPsec隧道模式和传输模式的组合，它提供了两者的一些特性。HIP使用HITs作为“内部”地址，IP地址作为“外部”地址，就像在隧道模式中使用IP地址一样。在终端主机上进行内部地址和外部地址之间的转换，而不是在主机之间通过隧道传输数据包，并且在初始HIP协商之后，内部地址永远不会在线路上发送。BEET提供了IPsec传输模式语法（无内部头）和有限的隧道模式语义（固定的逻辑内部地址——HITs——和可变的外部IP地址）。
In this section, we define the exact protocol formats and operations.
在本节中，我们将定义确切的协议格式和操作。
A BEET mode Security Association contains the same data as a regular tunnel mode Security Association, with the exception that the inner selectors must be single addresses and cannot be subnets. The data includes the following:
甜菜模式安全关联包含与常规隧道模式安全关联相同的数据，但内部选择器必须是单地址，不能是子网。数据包括以下内容：
o A pair of inner IP addresses.
o 一对内部IP地址。
o A pair of outer IP addresses.
o 一对外部IP地址。
o Cryptographic keys and other data as defined in Section 4.4.2 of RFC 4301 [RFC4301].
o RFC 4301[RFC4301]第4.4.2节中定义的加密密钥和其他数据。
A conforming implementation MAY store the data in a way similar to a regular tunnel mode Security Association.
一致性实现可以类似于常规隧道模式安全关联的方式存储数据。
Note that in a conforming implementation the inner and outer addresses MAY belong to different address families. All implementations that support both IPv4 and IPv6 SHOULD support both IPv4-over-IPv6 and IPv6-over-IPv4 tunneling.
注意，在一致性实现中，内部地址和外部地址可能属于不同的地址族。所有同时支持IPv4和IPv6的实现都应同时支持IPv4-over-IPv6和IPv6-over-IPv4隧道。
The wire packet format is identical to the ESP transport mode wire format as defined in Section 3.1.1 of [RFC4303]. However, the resulting packet contains outer IP addresses instead of the inner IP addresses received from the upper layer. The construction of the outer headers is defined in Section 5.1.2 of RFC 4301 [RFC4301]. The following diagram illustrates ESP BEET mode positioning for typical IPv4 and IPv6 packets.
有线数据包格式与[RFC4303]第3.1.1节中定义的ESP传输模式有线格式相同。但是，生成的数据包包含外部IP地址，而不是从上层接收的内部IP地址。RFC 4301[RFC4301]第5.1.2节定义了外部集管的构造。下图说明了典型IPv4和IPv6数据包的ESP BEET模式定位。
IPv4 INNER ADDRESSES
--------------------
IPv4 INNER ADDRESSES
--------------------
BEFORE APPLYING ESP
------------------------------
| inner IP hdr | | |
| | TCP | Data |
------------------------------
BEFORE APPLYING ESP
------------------------------
| inner IP hdr | | |
| | TCP | Data |
------------------------------
AFTER APPLYING ESP, OUTER v4 ADDRESSES
----------------------------------------------------
| outer IP hdr | | | | ESP | ESP |
| (any options) | ESP | TCP | Data | Trailer | ICV |
----------------------------------------------------
|<---- encryption ---->|
|<-------- integrity ------->|
AFTER APPLYING ESP, OUTER v4 ADDRESSES
----------------------------------------------------
| outer IP hdr | | | | ESP | ESP |
| (any options) | ESP | TCP | Data | Trailer | ICV |
----------------------------------------------------
|<---- encryption ---->|
|<-------- integrity ------->|
AFTER APPLYING ESP, OUTER v6 ADDRESSES
------------------------------------------------------
| outer | new ext | | | | ESP | ESP |
| IP hdr | hdrs | ESP | TCP | Data | Trailer| ICV |
------------------------------------------------------
|<--- encryption ---->|
|<------- integrity ------->|
AFTER APPLYING ESP, OUTER v6 ADDRESSES
------------------------------------------------------
| outer | new ext | | | | ESP | ESP |
| IP hdr | hdrs | ESP | TCP | Data | Trailer| ICV |
------------------------------------------------------
|<--- encryption ---->|
|<------- integrity ------->|
IPv4 INNER ADDRESSES with options
---------------------------------
IPv4 INNER ADDRESSES with options
---------------------------------
BEFORE APPLYING ESP
------------------------------
| inner IP hdr | | |
| + options | TCP | Data |
------------------------------
BEFORE APPLYING ESP
------------------------------
| inner IP hdr | | |
| + options | TCP | Data |
------------------------------
AFTER APPLYING ESP, OUTER v4 ADDRESSES
----------------------------------------------------------
| outer IP hdr | | | | | ESP | ESP |
| (any options) | ESP | PH | TCP | Data | Trailer | ICV |
----------------------------------------------------------
|<------- encryption ------->|
|<----------- integrity ---------->|
AFTER APPLYING ESP, OUTER v4 ADDRESSES
----------------------------------------------------------
| outer IP hdr | | | | | ESP | ESP |
| (any options) | ESP | PH | TCP | Data | Trailer | ICV |
----------------------------------------------------------
|<------- encryption ------->|
|<----------- integrity ---------->|
AFTER APPLYING ESP, OUTER v6 ADDRESSES
------------------------------------------------------------
| outer | new ext | | | | | ESP | ESP |
| IP hdr | hdrs | ESP | PH | TCP | Data | Trailer| ICV |
------------------------------------------------------------
|<------ encryption ------->|
|<---------- integrity ---------->|
AFTER APPLYING ESP, OUTER v6 ADDRESSES
------------------------------------------------------------
| outer | new ext | | | | | ESP | ESP |
| IP hdr | hdrs | ESP | PH | TCP | Data | Trailer| ICV |
------------------------------------------------------------
|<------ encryption ------->|
|<---------- integrity ---------->|
PH Pseudo Header for IPv4 options
IPv4选项的PH伪标头
IPv6 INNER ADDRESSES
--------------------
IPv6 INNER ADDRESSES
--------------------
BEFORE APPLYING ESP
------------------------------------------
| | ext hdrs | | |
| inner IP hdr | if present | TCP | Data |
------------------------------------------
BEFORE APPLYING ESP
------------------------------------------
| | ext hdrs | | |
| inner IP hdr | if present | TCP | Data |
------------------------------------------
AFTER APPLYING ESP, OUTER v6 ADDRESSES
--------------------------------------------------------------
| outer | new ext | | dest | | | ESP | ESP |
| IP hdr | hdrs | ESP | opts.| TCP | Data | Trailer | ICV |
--------------------------------------------------------------
|<---- encryption ---->|
|<------- integrity ------>|
AFTER APPLYING ESP, OUTER v6 ADDRESSES
--------------------------------------------------------------
| outer | new ext | | dest | | | ESP | ESP |
| IP hdr | hdrs | ESP | opts.| TCP | Data | Trailer | ICV |
--------------------------------------------------------------
|<---- encryption ---->|
|<------- integrity ------>|
AFTER APPLYING ESP, OUTER v4 ADDRESSES
----------------------------------------------------
| outer | | dest | | | ESP | ESP |
| IP hdr | ESP | opts.| TCP | Data | Trailer | ICV |
----------------------------------------------------
|<------- encryption -------->|
|<----------- integrity ----------->|
AFTER APPLYING ESP, OUTER v4 ADDRESSES
----------------------------------------------------
| outer | | dest | | | ESP | ESP |
| IP hdr | ESP | opts.| TCP | Data | Trailer | ICV |
----------------------------------------------------
|<------- encryption -------->|
|<----------- integrity ----------->|
The outgoing packets MUST be protected exactly as in ESP transport mode [RFC4303]. That is, the upper-layer protocol packet is wrapped into an ESP header, encrypted, and authenticated exactly as if regular transport mode was used. The resulting ESP packet is subject to IP header processing as defined in Appendices B.1.4 and B.1.5. The incoming ESP protected messages are verified and decrypted exactly as if regular transport mode was used. The resulting cleartext packet is subject to IP header processing as defined in Appendices B.1.4 and B.1.6.
必须严格按照ESP传输模式[RFC4303]保护传出数据包。也就是说，上层协议数据包被包装到ESP报头中，进行加密和身份验证，就像使用常规传输模式一样。根据附录B.1.4和B.1.5中的定义，生成的ESP数据包将接受IP报头处理。传入的受ESP保护的消息将完全按照使用常规传输模式的方式进行验证和解密。产生的明文数据包要进行附录B.1.4和B.1.6中定义的IP报头处理。
The biggest difference between BEET mode and the other two modes is in IP header processing. In the regular transport mode, the IP header is kept intact. In the regular tunnel mode, an outer IP header is created on output and discarded on input. In BEET mode, the IP header is replaced with another one on both input and output.
BEET模式与其他两种模式的最大区别在于IP报头处理。在常规传输模式下，IP报头保持不变。在常规隧道模式下，在输出时创建外部IP头，在输入时丢弃。在BEET模式下，输入和输出端的IP报头都被另一个报头替换。
On the BEET mode output side, the IP header processing MUST first ensure that the IP addresses in the original IP header contain the inner addresses as specified in the SA. This MAY be ensured by proper policy processing, and it is possible that no checks are needed at the time of SA processing. Once the IP header has been verified to contain the right IP inner addresses, it is discarded. A new IP header is created, using the fields of the discarded inner header (except the IP addresses) to populate the fields of the new outer header. The IP addresses in the new header MUST be the outer tunnel addresses.
在BEET模式输出端，IP报头处理必须首先确保原始IP报头中的IP地址包含SA中指定的内部地址。这可以通过适当的策略处理来确保，并且在SA处理时可能不需要检查。一旦验证IP头包含正确的IP内部地址，它将被丢弃。创建一个新的IP头，使用丢弃的内部头的字段（IP地址除外）填充新的外部头的字段。新标头中的IP地址必须是外部隧道地址。
On the input side, the received IP header is simply discarded. Since the packet has been decrypted and verified, no further checks are necessary. A new IP header corresponding to a BEET mode inner header is created, using the fields of the discarded outer header (except the IP addresses) to populate the fields of the new inner header. The IP addresses in the new header MUST be the inner addresses.
在输入端，接收到的IP报头被简单地丢弃。由于数据包已被解密和验证，因此无需进一步检查。创建与甜菜模式内部报头对应的新IP报头，使用丢弃的外部报头的字段（IP地址除外）填充新内部报头的字段。新标头中的IP地址必须是内部地址。
As the outer header fields are used as a hint for creating the inner header, it must be noted that the inner header differs as compared to a tunnel mode inner header. In BEET mode, the inner header will have the Time to Live (TTL), Don't Fragment (DF) bit, and other option values from the outer header. The TTL, DF bit, and other option values of the inner header MUST be processed by the stack.
由于外部标头字段用作创建内部标头的提示，因此必须注意，内部标头与隧道模式内部标头不同。在BEET模式下，内部标头将具有生存时间（TTL）、不分段（DF）位以及来自外部标头的其他选项值。堆栈必须处理内部标头的TTL、DF位和其他选项值。
The outgoing BEET mode packets are processed as follows:
输出甜菜模式数据包的处理如下：
1. The system MUST verify that the IP header contains the inner source and destination addresses, exactly as defined in the SA. This verification MAY be explicit, or it MAY be implicit, for example, as a result of prior policy processing. Note that in some implementations there may be no real IP header at this time but the source and destination addresses may be carried out of band. If the source address is still unassigned, it SHOULD be ensured that the designated inner source address would be selected at a later stage.
1. 系统必须验证IP报头是否包含内部源地址和目标地址，完全符合SA中的定义。此验证可能是显式的，也可能是隐式的，例如，作为先前策略处理的结果。注意，在一些实现中，此时可能没有真正的IP报头，但源地址和目标地址可能在带外执行。如果源地址仍然未分配，则应确保在稍后阶段选择指定的内部源地址。
2. The IP payload (the contents of the packet beyond the IP header) is wrapped into an ESP header as defined in Section 3.3 of [RFC4303].
2. 按照[RFC4303]第3.3节的规定，将IP有效负载（IP报头之外的数据包内容）包装到ESP报头中。
3. A new IP header is constructed, replacing the original one. The new IP header MUST contain the outer source and destination addresses, as defined in the SA. Note that in some implementations there may be no real IP header at this time but the source and destination addresses may be carried out of band.
3. 构建了一个新的IP头，取代了原来的IP头。新IP头必须包含SA中定义的外部源地址和目标地址。注意，在一些实现中，此时可能没有真正的IP报头，但源地址和目标地址可能在带外执行。
In the case where the source address must be left unassigned, it SHOULD be ensured that the right source address is selected at a later stage. Other than the addresses, it is RECOMMENDED that the new IP header copies the fields from the original IP header.
在源地址必须保持未分配的情况下，应确保在稍后阶段选择正确的源地址。除了地址之外，建议新的IP头从原始IP头复制字段。
4. If there are any IPv4 options in the original packet, it is RECOMMENDED that they are discarded. If the inner header contains one or more options that need to be transported between the tunnel endpoints, the sender MUST encapsulate the options as defined in Appendix B.1.7.
4. 如果原始数据包中存在任何IPv4选项，建议将其丢弃。如果内部标题包含一个或多个需要在隧道端点之间传输的选项，则发送方必须封装附录B.1.7中定义的选项。
Instead of literally discarding the IP header and constructing a new one, a conforming implementation MAY simply replace the addresses in an existing header. However, if the RECOMMENDED feature of allowing the inner and outer addresses from different address families is used, this simple strategy does not work.
一致性实现可以简单地替换现有报头中的地址，而不是从字面上丢弃IP报头并构建新的报头。但是，如果使用了允许来自不同地址族的内部和外部地址的推荐功能，那么这个简单的策略就不起作用。
The incoming BEET mode packets are processed as follows:
传入的BEET模式数据包处理如下：
1. The system MUST verify and decrypt the incoming packet successfully, as defined in Section 3.4 of [RFC4303]. If the verification or decryption fails, the packet MUST be discarded.
1. 系统必须按照[RFC4303]第3.4节的规定，成功验证和解密传入数据包。如果验证或解密失败，则必须丢弃数据包。
2. The original IP header is simply discarded, without any checks. Since the ESP verification succeeded, the packet can be safely assumed to have arrived from the right sender.
2. 原始IP报头被简单地丢弃，没有任何检查。由于ESP验证成功，可以安全地假定数据包来自正确的发送方。
3. A new IP header is constructed, replacing the original one. The new IP header MUST contain the inner source and destination addresses, as defined in the SA. If the sender has set the ESP Next Header field to 94 and included the pseudo header as described in Appendix B.1.7, the receiver MUST include the options after the constructed IP header. Note that in some implementations the real IP header may have already been discarded and the source and destination addresses are carried out of band. In such a case, the out-of-band addresses MUST be the inner addresses. Other than the addresses, it is RECOMMENDED that the new IP header copies the fields from the original IP header.
3. 构建了一个新的IP头，取代了原来的IP头。新IP头必须包含SA中定义的内部源地址和目标地址。如果发送方已将ESP Next Header字段设置为94并包含附录B.1.7中所述的伪报头，则接收方必须在构建的IP报头后包含选项。注意，在一些实现中，实际IP报头可能已经被丢弃，并且源地址和目标地址在带外执行。在这种情况下，带外地址必须是内部地址。除了地址之外，建议新的IP头从原始IP头复制字段。
Instead of literally discarding the IP header and constructing a new one, a conforming implementation MAY simply replace the addresses in an existing header. However, if the RECOMMENDED feature of allowing the inner and outer addresses from different address families is used, this simple strategy does not work.
一致性实现可以简单地替换现有报头中的地址，而不是从字面上丢弃IP报头并构建新的报头。但是，如果使用了允许来自不同地址族的内部和外部地址的推荐功能，那么这个简单的策略就不起作用。
In BEET mode, if IPv4 options are transported inside the tunnel, the sender MUST include a pseudo header after the ESP header. The pseudo header indicates that IPv4 options from the original packet are to be applied to the packet on the input side.
在BEET模式下，如果IPv4选项在隧道内传输，则发送方必须在ESP报头之后包含一个伪报头。伪报头表示原始数据包中的IPv4选项将应用于输入端的数据包。
The sender MUST set the Next Header field in the ESP header to 94. The resulting pseudo header, including the IPv4 options, MUST be padded to an 8-octet boundary. The padding length is expressed in octets; valid padding lengths are 0 or 4 octets, as the original IPv4 options are already padded to a 4-octet boundary. The padding MUST be filled with No Operation (NOP) options as defined in Section 3.1 ("Internet Header Format") of [RFC0791] ("Internet Protocol"). The padding is added in front of the original options to ensure that the receiver is able to reconstruct the original IPv4 datagram. The Header Length field contains the length of the IPv4 options, and padding in 8-octet units.
发件人必须将ESP标题中的下一个标题字段设置为94。生成的伪报头（包括IPv4选项）必须填充到8个八位字节的边界。填充长度以八位字节表示；有效的填充长度为0或4个八位字节，因为原始IPv4选项已填充到4个八位字节的边界。填充必须填充[RFC0791]（“互联网协议”）第3.1节（“互联网头格式”）中定义的无操作（NOP）选项。在原始选项前面添加填充，以确保接收器能够重建原始IPv4数据报。Header Length字段包含IPv4选项的长度，以及以8个八位字节为单位的填充。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Len | Pad Len | Reserved |
+---------------+---------------+-------------------------------+
| Padding (if needed) |
+---------------------------------------------------------------+
| IPv4 options ... |
| |
+---------------------------------------------------------------+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Len | Pad Len | Reserved |
+---------------+---------------+-------------------------------+
| Padding (if needed) |
+---------------------------------------------------------------+
| IPv4 options ... |
| |
+---------------------------------------------------------------+
Next Header identifies the data following this header. Length in octets 8-bit unsigned integer. Length of the pseudo header in 8-octet units, not including the first 8 octets.
下一个标题标识此标题后面的数据。长度（以八位字节为单位）8位无符号整数。伪头的长度，以8个八位字节为单位，不包括前8个八位字节。
The receiver MUST remove this pseudo header and padding as a part of BEET processing, in order to reconstruct the original IPv4 datagram. The IPv4 options included in the pseudo header MUST be added after the reconstructed IPv4 (inner) header on the receiving side.
作为BEET处理的一部分，接收方必须删除此伪报头和填充，以便重建原始IPv4数据报。伪报头中包含的IPv4选项必须添加到接收端重建的IPv4（内部）报头之后。
Acknowledgments
致谢
This document was separated from the base Host Identity Protocol specification in the beginning of 2005. Since then, a number of people have contributed to the text by providing comments and modification proposals. The list of people includes Tom Henderson, Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. Especially, the authors want to thank Pekka Nikander for his invaluable contributions to the document since the first draft version. The authors also want to thank Charlie Kaufman for reviewing the document with his eye on the usage of crypto algorithms.
本文档于2005年初从基本主机标识协议规范中分离出来。自那时以来，许多人通过提供评论和修改建议对案文作出了贡献。名单上的人包括汤姆·亨德森、杰夫·阿伦霍尔茨、扬·梅伦、朱卡·叶利塔洛和米卡·科姆。特别是，作者要感谢佩卡·尼坎德（Pekka Nikander），感谢他自初稿以来对该文件做出的宝贵贡献。作者还想感谢查理·考夫曼（Charlie Kaufman）对该文件的审查，他着眼于加密算法的使用。
Due to the history of this document, most of the ideas are inherited from the base Host Identity Protocol specification. Thus, the list of people in the Acknowledgments section of that specification is also valid for this document. Many people have given valuable feedback, and our apologies to anyone whose name is missing.
由于本文档的历史，大部分思想都继承自基本主机标识协议规范。因此，该规范的确认部分中的人员列表也适用于本文档。许多人都给出了宝贵的反馈，我们向所有姓名不见的人道歉。
Authors' Addresses
作者地址
Petri Jokela Ericsson Research NomadicLab JORVAS FIN-02420 Finland
Petri Jokela Ericsson研究实验室JORVAS FIN-02420芬兰
Phone: +358 9 299 1
EMail: petri.jokela@nomadiclab.com
Phone: +358 9 299 1
EMail: petri.jokela@nomadiclab.com
Robert Moskowitz HTT Consulting Oak Park, MI United States
美国密苏里州奥克公园罗伯特·莫斯科维茨咨询公司
EMail: rgm@labs.htt-consult.com
EMail: rgm@labs.htt-consult.com
Jan Melen Ericsson Research NomadicLab JORVAS FIN-02420 Finland
Jan Melen Ericsson研究实验室JORVAS FIN-02420芬兰
Phone: +358 9 299 1
EMail: jan.melen@nomadiclab.com
Phone: +358 9 299 1
EMail: jan.melen@nomadiclab.com