[要約] 要約：RFC 7402は、Host Identity Protocol（HIP）とEncapsulating Security Payload（ESP）トランスポートフォーマットの組み合わせに関する仕様です。 目的：このRFCの目的は、HIPとESPの組み合わせを使用して、セキュリティとプライバシーを強化し、ネットワーク通信の保護を向上させることです。
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)
ホストアイデンティティプロトコル（HIP）でのカプセル化セキュリティペイロード（ESP）トランスポートフォーマットの使用
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.
このメモは、ホストアイデンティティプロトコル（HIP）で使用される、ユーザーデータパケットの送信用のカプセル化セキュリティペイロード（ESP）ベースのメカニズムを指定します。このドキュメントはRFC 5202を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
Host Identity Protocol Architecture [HIP-ARCH]では、ホストは公開鍵で識別されます。 Host Identity Protocol（HIP）[RFC7401]ベース交換により、2つの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ベース交換仕様[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 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.
より具体的には、このドキュメントでは、一連のHIPプロトコル拡張とその処理を指定しています。これらの拡張機能を使用して、ベース交換中にホスト間にESPセキュリティアソシエーション（SA）のペアが作成されます。結果のESPセキュリティアソシエーションは、ベース交換中に生成されたキー情報（KEYMAT）から取得したキーを使用します。ホスト間でHIPアソシエーションと必要なESP SAが確立された後、ユーザーデータ通信は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.
ホストIDの表現は、ユーザーデータパケットのヘッダーでは明示的に伝えられないことに注意してください。代わりに、ESPセキュリティパラメータインデックス（SPI）を使用して、適切なホストコンテキストを示します。 SPIは、HIP ESPセットアップ交換中に選択されます。ユーザーデータパケットの場合、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]は実験的な仕様であり、その他は開発中です。）Middleboxトラバーサルはこのドキュメントの範囲外です。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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ベース交換は、2つのホスト間のHIPアソシエーションをセットアップするために使用されます。ベースエクスチェンジは、双方向のホスト認証とキーマテリアル生成を提供しますが、ホスト間のデータ通信を保護する手段を提供しません。このドキュメントでは、HIPベース交換後のユーザーデータトラフィックを保護するための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ベース交換メッセージで、転送されるパラメーターにいくつかのマイナーな追加が必要です。 R1パケットでは、レスポンダは可能なESPトランスフォームをESP_TRANSFORMパラメータに追加してから、イニシエータに送信します。イニシエーターは提案された変換を取得し、それらの提案された変換の1つを選択し、ESP_TRANSFORMパラメーターでI2パケットに追加します。このI2パケットでは、イニシエーターは、レスポンダーからイニシエーターに流れるESPトラフィックに使用したいSPI値も送信します。この情報は、ESP_INFOパラメータを使用して伝達されます。 ESP SAセットアップを完了すると、レスポンダは再びESP_INFOを使用して、R2パケットでSPI値をイニシエータに送信します。
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でさまざまな方法で実装できます。標準に準拠した変更されていないIPsec実装[RFC4303]を、その上の追加のトランスポートチェックサム処理と組み合わせて使用できるように、およびIPアドレスが正しいホストコンテキストへのインデックスとして使用されている場合に、それを実装することが可能です。
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アドレスを使用して構築されていると仮定して、実装はホストIDタグ（HIT）を使用して上位層のチェックサムを再計算し、その後、パケットの送信元アドレスと宛先アドレスを対応するIPアドレスに戻します。 。パケットはトランスポートモード処理のためにIPsec ESPに送信され、そこから暗号化されたパケットがネットワークに送信されます。 ESPパケットが受信されると、パケットは最初にIPsec ESPトランスポートモード処理を通過し、復号化後、送信元と宛先のIPアドレスがHITに置き換えられ、最後に上位層のチェックサムが検証されてからパケットが上層。
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アドレスであり、「内部」アドレスはHITです。発信トラフィックの場合、パケットが暗号化された後、パケットのIPヘッダーがHITではなくIPアドレスを含む新しいヘッダーに変更され、パケットがネットワークに送信されます。 ESPパケットを受信すると、SPI値と完全性保護により、パケットを適切なHITペアに安全に関連付けることができます。パケットヘッダーがHITを含む新しいヘッダーに置き換えられ、パケットが復号化されます。 BEETモードは完全にホストの内部であり、対応するホストがそれを実装する必要はありません。代わりに、対応するホストにESPトランスポートモードを設定し、ESP外でHIT 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と共に使用すると重要性が増します。それらはHITのペアの圧縮表現です。したがって、SPIは、アドレスマッピングなどのサービスを提供する際に中間システムによって使用される場合があります。 SPIは受信側で重要であるため、DSTが宛先IPアドレスである<DST、SPI>のみが、任意の時点で受信側HITを一意に識別します。同じ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のルールに従う必要があります。特定のホストとの各HIP交換には、異なるSPIを使用する必要があります（SHOULD）。これは、リプレイ攻撃を回避するためです。さらに、ホストがキーを再生成するとき、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作成の1つの方法は、HITを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交換の3番目（I2）および4番目（R2）のパケットでピアに伝達されます。 SPIの変更は、ESP_INFOパラメータで通知されます。
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では、ベース交換[RFC7401]中にHSPノード間にESPセキュリティアソシエーションがセットアップされます。既存のESP SAは、UPDATEメッセージを使用して後で更新できます。 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アソシエーションをセットアップすると、各アソシエーションは2つのESP SAにリンクされます。1つは着信パケット用で、もう1つは発信パケット用です。イニシエーターの着信SAはレスポンダーの発信SAに対応し、その逆も同様です。イニシエータは、セクション3.2.1で定義されているように、着信アソシエーションのSPIを定義します。この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.
イニシエーターは、セクション6.4で説明されているように、I2を送信する前に、R1処理の一部としてSA-RIを作成します。セクション7で定義されているように、キーはKEYMATから派生します。レスポンダはI2処理の一部としてSA-RIを作成します。セクション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を送信する前に、I2処理の一部としてSA-IRを作成します。セクション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]で指定されているようにHIPキーが描画された後、生成されたキー生成情報KEYMATから描画されます。
When the HIP association is removed, the related ESP SAs MUST also be removed.
HIPアソシエーションが削除されると、関連する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'.
最初のHIPベース交換とSAの確立後、両方のホストはESTABLISHED状態になります。イニシエーターとレスポンダーの役割はなくなり、関連付けは対称的です。このサブセクションでは、キー再生成手順を開始するパーティを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アソシエーションの存続期間中に更新が必要になる場合があります。このドキュメントでは、UPDATEメッセージを使用して、既存のHIPで作成されたESP SAの鍵の再生成を指定します。上記で紹介した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.
必要に応じて、ESP SA更新プロセスを開始します（セクション6.8を参照）。必要な情報を含むUPDATEパケットを作成し、それをピアノードに送信します。古いSAはまだ使用されており、ローカルポリシーで許可されています。
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.
R 'は、UPDATEを受信して処理した後（セクション6.9を参照）、新しいSA（SA-I'R'およびSA-R'I '）を生成します。新しい発信SAは使用されませんが、古い発信SAは引き続き使用されるため、同じピアホストに対して2つのSAペアが一時的に存在します。新しい発信SAのSPI、SPI-R'I 'は、UPDATEパケットの受信したESP_INFOパラメータで指定されます。新しい着信SAの場合、R 'は新しいSPI値SPI-I'R'を生成し、それを応答UPDATEパケットに含めます。
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'で説明されているように、R 'から応答UPDATEを受信すると、新しい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でトラフィックを受信したとき、またはキー更新の完了を確認するUPDATE ACKを受信したときに、新しい発信SAの使用を開始します。この後、R 'は古いSAを削除できます。同様に、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つのHIT（システムには複数のHITがあるため、ローカルとリモートの両方のHIT）によってインデックスが作成されます。非アクティブタイマーはすべての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データの単純な圧縮を提供します。これには、HITペアごとのセキュリティアソシエーション（およびSPI）が必要であり、インターネットキーエクスチェンジ（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]をサポートする必要があります。イニシエーターがレスポンダーによって提供される変換のいずれもサポートしない場合、それはネゴシエーションを放棄し、サポートされていない変換についてのNOTIFYメッセージでピアに通知する必要があります。
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 NULL暗号化アルゴリズムを実装する必要があります（SHOULD）。 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は例です）、ピアホストに関するローカルポリシー構成が明示的に許可するように設定されていない限り、ピアによって提供された場合、スイートは受け入れられません（MUST NOT）。認証専用モード。これは、一方のポリシーがセッションのプライバシーを要求したときに、セッションが認証専用モードにダウングレードされるのを防ぐためです。
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のタイムアウトをサポートする必要があります（SHOULD）。そのSAを使用してパケットが受信されない場合、SAはタイムアウトします。実装は、構成可能なSAタイムアウト値をサポートする必要があります（SHOULD）。実装は、さまざまなESP変換のライフタイムをサポートする場合があります。各実装は、非アクティブタイムアウトのHITごとの構成を実装する必要があります。これにより、静的に構成されたHIPアソシエーションが非アクティブな場合でも数日間存続できるようになります。
When HIP is run on a node where a standards compliant IPsec is used, some issues have to be considered.
標準に準拠したIPsecが使用されているノードでHIPを実行する場合、いくつかの問題を考慮する必要があります。
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].
HIPでネゴシエートされていないSAを使用する着信パケットは、セクション3.2、パラグラフ2で説明されているように処理してはなりません（MUST NOT）。 [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（または、2つある場合は調整されたSPD-1つはHIP用、もう1つはIPsec用）は、HIP処理用のパケットにHIP対応のSAが与えられ、IPsec処理用のパケットにIPsec対応SA。次に、SPは一致するSAにバインドする必要があり、HIP以外のパケットはこのSAによって処理されません。 HIPを使用していないソケットからのデータは、チェックサムを再計算してはならず（セクション3.2、パラグラフ2で説明）、データはHIPによって作成されたSPまたはSAに渡してはなりません（MUST NOT）。
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の両方で処理される可能性があります。この場合、IPsec SAはHIPホストとセキュリティゲートウェイ間の暗号化用であるのに対し、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アドレスを対応するHITにマッピングするには、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.
このセクションでは、HIPアソシエーションで使用するESPアソシエーションをセットアップするためのプロトコルについて説明します。
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_TRANSFORMパラメータのタイプ番号、つまり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セキュリティアソシエーションのセットアップは、4つのメッセージのHIPベース交換の最後の3つのメッセージ（R1、I2、およびR2メッセージ）にパラメーターを含めることによって実行されます。
Initiator Responder
イニシエーターレスポンダー
I1
---------------------------------->
R1: ESP_TRANSFORM
<----------------------------------
I2: ESP_TRANSFORM, 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パラメータを含めると、TRANSPORT_FORMAT_LISTが明確になりますが、選択されていない可能性のある変換のネゴシエーションが開始される場合があります。ただし、リソースに制約のあるデバイスは、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_TRANSFORMへの応答が含まれています。送信者は、提案されたESP変換の1つをR1メッセージのESP_TRANSFORMパラメーターから選択し、選択したものをI2パケットのESP_TRANSFORMパラメーターに含める必要があります。トランスフォームに加えて、ホストには、ピアホストが使用する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.
更新プロセスは、3つのメッセージを使用して実行されます。 HIP UPDATEメッセージは、既存のESP SAのパラメーターを更新するために使用されます。 UPDATEメカニズムとメッセージは[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が更新されたときの一般的な交換を示しています。メッセージには、UPDATEメカニズムで必要なSEQおよびACKパラメータが含まれます。
H1 H2
UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN]
----------------------------------------------------->
UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN]
<-----------------------------------------------------
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を更新するホストは、UPDATEメッセージを作成して送信します。メッセージには、使用された古いSPI値、使用される新しいSPI値、およびキーイングマテリアルのインデックス値を含むESP_INFOパラメータが含まれ、次のキーが描画されるポイントを示します。新しい鍵素材を生成する必要がある場合、UPDATEメッセージには、[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の更新を要求するUPDATEメッセージを受信するホストは、UPDATEメッセージで応答する必要があります。ホストは応答メッセージで、対応する値を含むESP_INFOパラメータを送信します：古いSPI、新しいSPI、およびキーマテリアルインデックス。着信UPDATEにDIFFIE_HELLMANパラメータが含まれている場合、応答パケットにはDIFFIE_HELLMANパラメータも含まれている必要があります。
In this section, new and modified HIP parameters are presented, as well as modified HIP packets.
このセクションでは、新しいHIPパラメータと変更された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通信でESPトランスポート形式の関連付けを設定するため、および既存の関連付けを再生成するために、2つのHIPパラメータが定義されています。また、[RFC7401]で説明されているNOTIFICATIONパラメータには、この仕様で定義された2つのエラー値があります。
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値がホスト間で送信される必要があります。さらに、ホストは、生成されたキー情報からキーを描画するときに、KEYMATへのインデックス値を必要とします。 ESP_INFOパラメータは、ホスト間でSPI値とKEYMATインデックス情報を送信するために使用されます。
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パラメータのNEW SPIフィールドに設定されます。初期設定では、SPIの古い値は存在しません。したがって、OLD SPIフィールドの値はゼロに設定されます。マルチホームHIPホストの場合など、HIPホスト間に追加のSAが設定されている場合は、OLD SPIフィールドの値もゼロになることがあります[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インデックス値は、ESM SAのキー情報が描画されるKEYMAT内の場所を指します。 KEYMATインデックス値がゼロになるのは、鍵の再生成プロセス中にESP_INFOが送信され、新しい鍵材料が生成される場合のみです。
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つがシーケンス番号を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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_INFOがUPDATEパケットで送信される場合、フィールドはゼロでなければなりません。 ESP_INFOがベース交換メッセージに含まれている場合、KEYMATインデックスには、ESP SAキーが描画されるポイントのインデックス値が必要です。このフィールドの長さは、KEYMATから描画できるキー情報の量を制限することに注意してください。その量を超える場合、パケットには新しいDiffie-Hellmanキーが含まれている必要があります。 OLD SPIこのSAに関連付けられたアドレスに送信されたデータの古いSPI。これが初期のSAセットアップである場合、OLD SPI値はゼロです。 NEW 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_TRANSFORMパラメータで選択した変換ファミリを送信し、ピアは提案された値の1つを選択し、それを応答ESP_TRANSFORMパラメータに含める必要があります。
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]
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変換パラメーターの送信者は、1つのESP変換パラメーターに6つ以下のスイートIDがあることを確認する必要があります。逆に、受信者は、6つを超えるスイートIDを含む受信した変換パラメーターを処理する準備をする必要があります。スイートIDの数が限られているため、ESP_TRANSFORMパラメータの最大サイズが設定されます。デフォルトの構成として、ESP_TRANSFORMパラメータには必須のスイートIDの少なくとも1つが含まれている必要があります。管理者がこのデフォルトを上書きできるようにする構成オプションがある場合があります。
Mandatory implementations: AES-128-CBC with HMAC-SHA-256. NULL with HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5).
必須の実装：HMAC-SHA-256を備えたAES-128-CBC。 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.
状況によっては、トラフィックフロー機密性（TFC）[RFC4303]とESPをBEETモードで使用することができます。ただし、このような操作の定義は将来の作業に委ねられており、別の仕様で行う必要があります。
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基本仕様は、一連のNOTIFICATIONエラータイプを定義しています。ネゴシエーション中のESP変換暗号スイートのエラーを説明するには、次のエラータイプが必要です。
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
NO_ESP_PROPOSAL_CHOSEN 18
の＿えＳＰ＿ＰろぽさＬ＿ちょせん １８
None of the proposed ESP Transform crypto suites was acceptable.
提案されたESP Transform暗号スイートはどれも受け入れられませんでした。
INVALID_ESP_TRANSFORM_CHOSEN 19
INVALID_ESP_TRANSFORM_CHOSEN 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）とUPDATEメッセージの両方を使用した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_TRANSFORMには、送信者がサポートするESPモードが優先順に含まれています。すべての実装は、HMAC-SHA-256 [RFC4868]でAES-128-CBC [RFC3602]をサポートする必要があります。
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_COUNTER、] PUZZLE、DIFFIE_HELLMAN、HIP_CIPHER、ESP_TRANSFORM、HOST_ID、[ECHO_REQUEST、] HIP_SIGNATURE_2）[、ECHO_REQUEST]）
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_INFOには、この関連付けの送信者の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_TRANSFORMには、R1の送信者が選択したESPモードが含まれています。すべての実装は、HMAC-SHA-256 [RFC4868]でAES-128-CBC [RFC3602]をサポートする必要があります。
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] ) )
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_INFOには、ESP SAキーが描画される場所を指定するKEYMATインデックス値もあります。
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_INFO、HMAC_2、HIP_SIGNATURE））
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_SIGNATUREは図示されておらず、DIFFIE_HELLMANキーはオプションです。 ACK_Iを使用したUPDATEは、SEQ_Rを使用したUPDATEに便乗する必要はありません。個別にACKされる場合があります（この場合、シーケンスには4つのパケットが含まれます）。
I' R'
私は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.
以下では、この図の最初の2つのパケットについて説明します。
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.
ESPでHIPを使用する場合、UPDATEパケットを使用してキーの再生成を開始します。 UPDATEパケットはESP_INFOを伝達しなければならず（MUST）、DIFFIE_HELLMANパラメータを伝達してもよい（MAY）。
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.
次の図は、鍵再生成初期化UPDATEパケットの内容を示しています。
The HIP parameters for the UPDATE packet initiating rekeying:
鍵更新を開始するUPDATEパケットのHIPパラメータ：
IP ( HIP ( ESP_INFO, SEQ, [DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) )
IP（HIP（ESP_INFO、SEQ、[DIFFIE_HELLMAN、] HMAC、HIP_SIGNATURE））
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.
UPDATE ACKは、受信したUPDATEキー再生成の初期化を確認するために使用されます。肯定応答UPDATEパケットはESP_INFOを運ばなければならず（MUST）、DIFFIE_HELLMANパラメータを運んでもよい（MAY）。
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.
次の図は、鍵更新確認応答UPDATEパケットの内容を示しています。
The HIP parameters for the UPDATE packet:
UPDATEパケットのHIPパラメータ：
IP ( HIP ( ESP_INFO, SEQ, ACK, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) )
IP（HIP（ESP_INFO、SEQ、ACK、[DIFFIE_HELLMAN、] HMAC、HIP_SIGNATURE））
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パケットを受信した場合、それは（応答をレート制限することを条件として）タイプ「パラメーターの問題」のICMPパケットで応答してもよく（MAY）、ポインターはSPIフィールドの先頭を指します。 ESPヘッダー。
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ベース仕様[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トランスポート形式が使用され、指定された<ソース、宛先> HITペアのアクティブなHIPセッションがある場合、発信データグラムはESPセキュリティアソシエーションを使用して保護されます。次の追加の手順では、ESPで保護された送信データグラムの概念的な処理規則を定義します。
1. Detect the proper ESP SA using the HITs in the packet header or other information associated with the packet.
1. パケットヘッダーのHITまたはパケットに関連するその他の情報を使用して、適切な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処理によって残されたHITを置き換えるなどして、使用されるIPアドレスファミリー、およびIPヘッダー内の適切なIPアドレスに応じて、ESPで保護された送信パケットが適切なIPヘッダー形式であることを確認します。この適切な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ベース仕様で指定されています。 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パケットを送信してもよい（MAY）。失われた状態を処理する方法は実装の問題です。
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に関連付けられたHITに置き換えられます。このIPアドレスからHITへの変換ステップは、ESP処理後など、スタック内の他のポイントでも実行される場合があります。また、着信パケットにIPv4アドレスが含まれている場合は、アドレスをHITで置き換える前にパケットをIPv6形式に変換する必要があることにも注意してください（エラーがなければトランスポートチェックサムが通過します）。
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の復号化と検証が成功した結果、関連するHITが送信元と送信先として含まれるデータグラムになります。
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. データグラムは上位層に配信されます。右側の上位層ソケットへのデータグラムの逆多重化は、逆多重化中にIPアドレスの代わりにHITが使用されることを除いて、通常どおり実行されます。
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および署名計算を使用して保護する必要があります。一般的な実装では、[RFC7401]で説明されているように、R1、I2、R2、およびUPDATEパケットのHMACおよびSIGNATUREの計算に含まれます。
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変換の1つを選択します。適切な値が見つからない場合、ネゴシエーションは終了します。選択した値は、暗号化キーを生成して使用するとき、および応答パケットを送信するときに使用されます。提案された代替案がシステムに受け入れられない場合、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]で説明されているように、HIT比較のためにドロップされていません）。
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パラメーターが検証され、パラメーターに単一の値が含まれている必要があります。また、初期化パケットで提供される値の1つと一致する必要があります。
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が取得されます。この最初の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フィールドが解析され、ファイナライズメッセージR2の送信者に着信するESPセキュリティアソシエーションに使用されるSPIが取得されます。システムはこの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シーケンスカウンターがオーバーフローしそうな場合は、キーの再生成を開始する必要があります。再キーイングパケット交換が正常に完了するまで、システムはそのキーイング情報を置き換えてはなりません（MUST NOT）。
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.
オプションとして、新しいKEYMAT生成で使用するための新しい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]で定義されているUPDATEメカニズムを使用します。各ピアは、セキュリティアソシエーションペアの半分（新しいSPIの作成を含む）を更新する必要があるため、鍵の再生成プロセスでは、両側でUPDATEを送受信する必要があります。システムは、パラメーターをピアに送信し、関連するUPDATEメッセージのACKと対応するピアのパラメーターの両方を受信すると、ESP SAのキーを再生成します。 ACKと必要なHIPパラメータが異なるUPDATEメッセージで到着する場合があります。これは、システムがESP SA更新を開始しないが、ピアからの更新要求に応答する場合は常に当てはまり、2つのシステムが更新をほぼ同時に開始する場合にも発生する可能性があります。このような場合、システムに未解決の更新要求があると、1つのパラメーターが保存され、もう1つのパラメーターを待ってからキーの再生成が完了します。
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. システムは、既存のKEYMATを引き続き使用するか、新しいKEYMATを生成するかを決定します。後者の場合、システムは新しい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パラメータを含むUPDATEパケットを作成します。さらに、ホストにはオプションのDIFFIE_HELLMANパラメータが含まれている場合があります。 UPDATEにDIFFIE_HELLMANパラメータが含まれている場合、ESP_INFOパラメータのKEYMATインデックスはゼロである必要があり、Diffie-HellmanグループIDは最初のハンドシェイクで使用されたものから変更されていない必要があります。 UPDATEにDIFFIE_HELLMANが含まれていない場合、ESP_INFO KEYMATインデックスは、現在のKEYMATから描画される次のバイトのインデックス以上でなければなりません。
3. The system sends the UPDATE packet. For reliability, the underlying UPDATE retransmission mechanism MUST be used.
3. システムはUPDATEパケットを送信します。信頼性のために、基になるUPDATE再送信メカニズムを使用する必要があります。
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を削除してはならない（MUST NOT）が、ポリシーで許可されている場合は、それらを引き続き使用する必要がある。キー再生成手順は、SAリプレイカウンターがオーバーフローしないことを確認するのに十分早い時期に開始する必要があります（SHOULD）。
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. プロトコルエラーが発生し、ピアシステムがUPDATEを確認したが、それ自体がESP_INFOを送信しない場合、システムは未解決のESP SA更新要求を確定しない可能性があります。これを防ぐために、ピアが応答するのをしばらく待ってからシステムがESP SA更新手順を再開するか、実装に依存する時間を待ってからESP SAを中止することを決定する場合があります。システムは、未解決のESP SA更新要求を無期限に保持してはなりません（MUST NOT）。
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更新要求がある間は、新しいUPDATEを生成してはなりません（MUST NOT）。
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]):
システムがUPDATEパケットを受信すると、（[RFC7401]のセクション6.12でUPDATE処理に指定された一般的な条件に加えて）次の条件が満たされている場合に処理する必要があります。
1. A corresponding HIP association must exist. This is usually ensured by the underlying UPDATE mechanism.
1. 対応するHIPアソシエーションが存在している必要があります。これは通常、基になるUPDATEメカニズムによって保証されます。
2. The state of the HIP association is ESTABLISHED or R2-SENT.
2. HIPアソシエーションの状態はESTABLISHEDまたはR2-SENTです。
If the above conditions hold, the following steps define the conceptual processing rules for handling the received UPDATE packet:
上記の条件が満たされている場合、次の手順で、受信したUPDATEパケットを処理するための概念的な処理規則を定義します。
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. 受信したUPDATEにDIFFIE_HELLMANパラメータが含まれている場合、受信したKEYMATインデックスはゼロである必要があり、グループIDは、関連付けで使用されているグループIDと一致する必要があります。このテストが失敗した場合は、パケットをドロップする必要があり（SHOULD）、システムはエラーメッセージをログに記録する必要があります（SHOULD）。
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. 未処理のキー更新要求がある場合は、UPDATEを確認する必要があり、受信したESP_INFO（および場合によっては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パラメータを使用して受信したUPDATEパケットを処理するための概念的な処理規則を定義します。
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キーを記録して、KEYMAT生成で使用します。
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_INFO KEYMATインデックスは、現在のKEYMATから描画される次のバイトのインデックス以上でなければなりません。この場合、ホストは、受信したESP_INFOのピアによって要求されたKEYMATインデックスを使用することをお勧めします。
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パラメーターを含むUPDATEパケットを作成します。このUPDATEは通常、ACKパラメータを使用してピアのUPDATEを確認応答しますが、別のUPDATE 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. システムはUPDATEパケットを送信し、受信したESP_INFOおよびDIFFIE_HELLMANパラメータを格納します。この時点で、ESP SAの更新を完了するには、新しく送信されたUPDATEの確認を受信するだけです。通常の場合、確認応答は基礎となるUPDATEメカニズムによって処理されます。
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:
システムは、対応するUPDATE確認応答パケットをピアから受信し、ピアのUPDATEを正常に受信したときに、鍵の再生成を完了します。次の手順を実行します。
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. 受信したUPDATEメッセージに新しいDiffie-Hellmanキーが含まれている場合、ESP SA更新の開始、またはその両方が原因で、システムに新しいDiffie-Hellmanキーが存在する場合、システムは新しいKEYMATを生成します。新しいDiffie-Hellmanキーが1つしかない場合は、古い既存のキーが他のキーとして使用されます。
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を生成した場合、受信したUPDATEにDiffie-Hellman鍵が含まれていたかどうかに関係なく、KEYMATインデックスをゼロに設定します。システムが新しいKEYMATを生成しなかった場合、2つの（送信および受信された）ESP_INFOパラメーターのより大きいKEYMATインデックスが使用されます。
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_INFOがピアに送信されたときに生成されました。再入力プロセス中にKEYMATから取得されるキーの順序は、セクション7で説明したものと同様です。HIPキーではなく、IPsec ESPキーのみが再入力プロセス中に取得されることに注意してください。
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.
NOTIFYパケットの処理は、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基本仕様に記載されているように生成されます。ベース交換中に、初期キーは生成されたマテリアルから取得されます。 HIPアソシエーションキーが描画された後、ESPキーは次の順序で描画されます。
SA-gl ESP encryption key for HOST_g's outgoing traffic
HOST_gの送信トラフィックのSA-gl ESP暗号化キー
SA-gl ESP authentication key for HOST_g's outgoing traffic
HOST_gの送信トラフィックのSA-gl ESP認証キー
SA-lg ESP encryption key for HOST_l's outgoing traffic
HOST_lの発信トラフィックのSA-lg ESP暗号化キー
SA-lg ESP authentication key for HOST_l's outgoing traffic
HOST_lの発信トラフィックの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はHIT値が大きいホストを示し、HOST_lはHIT値が小さいホストを示します。 HIT値を比較すると、ネットワークバイトオーダーで正の（符号なしの）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.
4つのHIPキーは、HIP I1-> R2交換中にのみKEYMATから取得されます。 UPDATEを使用したその後のキー再生成では、KEYMATから4つのESPキーのみが取得されます。セクション6.9では、キーの再生成に基づいてKEYMATを再利用または再生成するためのルールについて説明します。
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.
2つのノード間に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 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.
oキーイングマテリアルの更新最初のキーイングマテリアルは、Diffie-Hellmanプロシージャを使用したホストアイデンティティプロトコル[RFC7401]を使用して生成されます。このドキュメントでは、基本仕様で定義されているUPDATEパケットの使用法を拡張して、既存のESP SAを変更します。ホストは、キーの再生成、つまり、Diffie-Hellman手順を使用して新しいキー生成情報の生成を強制できます。ホスト間のESP SAの初期設定はベース交換中に行われ、メッセージ交換はベース交換によって提供される方法を使用して保護されます。接続パラメーターの変更は、基本的に古いESP SAが削除され、UPDATEメッセージの交換が完了すると新しい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].
このドキュメントでは、ホストIDプロトコル[RFC7401]の2つのパラメータタイプと2つのNOTIFYメッセージタイプを定義しています。
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.
新しいNOTIFICATIONエラータイプとその値はセクション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は、新しい値の「IETFレビュー」登録手順[RFC5226]を使用して、新しいIANAレジストリに登録される「ESP Transform Suite ID」の値を定義しています。
[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、「The Use of HMAC-SHA-1-96 within ESP and AH」、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、「NULL暗号化アルゴリズムと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]フランケルS.、グレンR.、およびS.ケリー、「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、「The Use of Galois / Counter Mode（GCM）in IPsec Encapsulating Security Payload（ESP）」、RFC 4106、2005年6月、<http：//www.rfc-editor。 org / info / rfc4106>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005, <http://www.rfc-editor.org/ info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月、<http://www.rfc-editor.org/ info / 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。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）CCMモードの使用」、RFC 4309、2005年12月、<http://www.rfc-editor.org/ info / 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、「The AES-CMAC Algorithm」、RFC 4493、2006年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 4494、2006年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、「The Use of Galois Message Authentication Code（GMAC）in IPsec ESP and AH」、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]ケリーS.およびS.フランケル、「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。、編、Heer、T.、Jokela、P。、およびT. Henderson、「Host Identity Protocol Version 2（HIPv2）」、RFC 7401、2015年4月、<http：// www。 rfc-editor.org/ info / 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、「Host Identity Protocol Architecture」、Work in Progress、draft-ietf-hip-rfc4423-bis-09、2014年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 791、1981年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 4301、2005年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、「ホストアイデンティティプロトコル（HIP）でのカプセル化セキュリティペイロード（ESP）トランスポートフォーマットの使用」、RFC 5202、2008年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、「End-Host Mobility and Multihoming with the Host Identity Protocol」、RFC 5206、2008年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] Stiemerling、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、「RFCで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、「Basic Host Identity Protocol（HIP）Extensions for Traversal of Network Address Translators」、RFC 5770、2010年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 7296、2014年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.
この仕様を複数の異なる方法で実装することが可能です。上記のように、これを実装する1つの可能な方法は、IPsecの下のIPヘッダーを書き換えることです。このような実装では、IPsecはIPv6トランスポートモードパケットを処理しているかのように使用され、IPv6ヘッダーには送信元アドレスフィールドと宛先アドレスフィールドのIPアドレスの代わりにHITが含まれます。発信パケットでは、IPsec処理の後、HITはHITおよびSPIに基づいて実際のIPアドレスに置き換えられます。着信パケットでは、IPsec処理の前に、着信パケットのSPIに基づいてIPアドレスがHITに置き換えられます。このような実装では、すべてのIPsecポリシーはHITに基づいており、上位層はIPアドレスの代わりにHITを持つパケットのみを認識します。したがって、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には1つの実装レベルの利点があります。 BEETモードベースの実装では、アドレス書き換え情報はSADの1つの場所に保持されます。一方、アドレス書き換えが個別に実装されている場合、実装では、SADの情報と個別のアドレス書き換えデータベースの情報が同期していることを確認する必要があります。その結果、この仕様を実装するBEETモードベースの方法は、ID、暗号化、およびロケーターを緊密にバインドするため、個別の実装よりも推奨されます。動作はホストの内部でのみ表示されるため、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は、IPアドレスがトンネルモードで使用されるのと同様に、HITを「内部」アドレスとして使用し、IPアドレスを「外部」アドレスとして使用します。ホスト間でパケットをトンネリングする代わりに、エンドホストで内部アドレスと外部アドレス間の変換が行われ、最初のHIPネゴシエーション後に内部アドレスがネットワーク上に送信されることはありません。 BEETは、制限されたトンネルモードセマンティクス（固定された論理内部アドレス-HIT-および変更可能な外部IPアドレス）を持つIPsecトランスポートモード構文（内部ヘッダーなし）を提供します。
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:
BEETモードのセキュリティアソシエーションには、通常のトンネルモードのセキュリティアソシエーションと同じデータが含まれますが、内部セレクターは単一のアドレスでなければならず、サブネットにすることはできません。データには以下が含まれます。
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.
適合実装は、通常のトンネルモードセキュリティアソシエーションと同様の方法でデータを格納することができます（MAY）。
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の両方のトンネリングをサポートする必要があります（SHOULD）。
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
--------------------
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 v6 ADDRESSES
------------------------------------------------------
| outer | new ext | | | | ESP | ESP |
| IP hdr | hdrs | ESP | TCP | Data | Trailer| ICV |
------------------------------------------------------
|<--- encryption ---->|
|<------- integrity ------->|
IPv4 INNER ADDRESSES with options
---------------------------------
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 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
--------------------
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 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ヘッダーにラップされ、暗号化され、通常のトランスポートモードが使用された場合とまったく同じように認証されます。結果のESPパケットは、付録B.1.4およびB.1.5で定義されている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モードと他の2つのモードの最大の違いは、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ヘッダーは単に破棄されます。パケットは復号化および検証されているため、これ以上のチェックは必要ありません。 BEETモードの内部ヘッダーに対応する新しい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モードでは、内部ヘッダーにはTime to Live（TTL）、Do n't Fragment（DF）ビット、および外部ヘッダーからの他のオプション値が含まれます。内部ヘッダーのTTL、DFビット、およびその他のオプション値は、スタックによって処理される必要があります。
The outgoing BEET mode packets are processed as follows:
発信BEETモードパケットは次のように処理されます。
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オプションがある場合、それらを破棄することをお勧めします。内部ヘッダーにトンネルエンドポイント間で転送する必要がある1つ以上のオプションが含まれている場合、送信者は付録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ヘッダーを破棄して新しいものを作成する代わりに、適合実装は単に既存のヘッダーのアドレスを置き換えてもよい（MAY）。ただし、異なるアドレスファミリからの内部アドレスと外部アドレスを許可する推奨機能が使用されている場合、この単純な戦略は機能しません。
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で定義されているように、システムは着信パケットを正常に検証して復号化する必要があります。検証または復号化が失敗した場合、パケットは破棄されなければなりません（MUST）。
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ヘッダーが置き換えられます。 SAで定義されているように、新しいIPヘッダーには内部の送信元アドレスと宛先アドレスが含まれている必要があります。送信者が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ヘッダーを破棄して新しいものを作成する代わりに、適合実装は単に既存のヘッダーのアドレスを置き換えてもよい（MAY）。ただし、異なるアドレスファミリからの内部アドレスと外部アドレスを許可する推奨機能が使用されている場合、この単純な戦略は機能しません。
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オクテットの境界までパディングする必要があります。パディングの長さはオクテットで表されます。元のIPv4オプションはすでに4オクテットの境界に埋め込まれているため、有効なパディング長は0または4オクテットです。 [RFC0791]（ "インターネットプロトコル"）のセクション3.1（ "インターネットヘッダーフォーマット"）で定義されているように、パディングは操作なし（NOP）オプションで埋める必要があります。レシーバーが元のIPv4データグラムを再構築できるように、元のオプションの前にパディングが追加されます。ヘッダー長フィールドには、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 ... |
| |
+---------------------------------------------------------------+
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.
受信者は、元のIPv4データグラムを再構築するために、BEET処理の一部としてこの疑似ヘッダーとパディングを削除する必要があります。疑似ヘッダーに含まれる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年の初めにベースのホストアイデンティティプロトコル仕様から分離されました。それ以来、コメントや変更提案を提供することにより、多くの人々がテキストに貢献してきました。人々のリストには、トムヘンダーソン、ジェフアーレンホルツ、ヤンメレン、ユッカイリタロ、およびミイカコムが含まれます。特に、最初のドラフト版以降、ペッカニカンデルが文書に多大な貢献をしてくれたことに感謝します。著者はまた、暗号アルゴリズムの使用に目を向けてドキュメントをレビューしてくれた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 Research NomadicLab JORVAS FIN-02420フィンランド
Phone: +358 9 299 1
EMail: petri.jokela@nomadiclab.com
Robert Moskowitz HTT Consulting Oak Park, MI United States
Robert Moskowitz HTT Consultingオークパーク、MI米国
EMail: rgm@labs.htt-consult.com
Jan Melen Ericsson Research NomadicLab JORVAS FIN-02420 Finland
Jan Melen Ericsson Research NomadicLab JORVAS FIN-02420フィンランド
Phone: +358 9 299 1
EMail: jan.melen@nomadiclab.com