[要約] 要約：RFC 5202は、Host Identity Protocol（HIP）とEncapsulating Security Payload（ESP）トランスポートフォーマットの組み合わせに関する仕様です。 目的：このRFCの目的は、HIPとESPを組み合わせることで、ネットワーク通信のセキュリティとプライバシーを向上させることです。
Network Working Group P. Jokela
Request for Comments: 5202 Ericsson Research NomadicLab
Category: Experimental R. Moskowitz
ICSAlabs
P. Nikander
Ericsson Research NomadicLab
April 2008
Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)
ホストIDプロトコル（HIP）を使用して、セキュリティペイロード（ESP）トランスポートフォーマットを使用する
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
IESG Note
IESGノート
The following issues describe IESG concerns about this document. The IESG expects that these issues will be addressed when future versions of HIP are designed.
以下の問題は、このドキュメントに関するIESGの懸念について説明しています。IESGは、将来のバージョンのHIPが設計されたときにこれらの問題に対処することを期待しています。
In case of complex Security Policy Databases (SPDs) and the co-existence of HIP and security-related protocols such as IKE, implementors may encounter conditions that are unspecified in these documents. For example, when the SPD defines an IP address subnet to be protected and a HIP host is residing in that IP address area, there is a possibility that the communication is encrypted multiple times. Readers are advised to pay special attention when running HIP with complex SPD settings. Future specifications should clearly define when multiple encryption is intended, and when it should be avoided.
複雑なセキュリティポリシーデータベース（SPD）とIKEなどの股関節とセキュリティ関連のプロトコルの共存の場合、実装者はこれらのドキュメントで特定されていない条件に遭遇する場合があります。たとえば、SPDがIPアドレスサブネットを保護するサブネットを定義し、股関節ホストがそのIPアドレス領域に存在する場合、通信が複数回暗号化される可能性があります。読者は、複雑なSPD設定で股関節を実行する際に特別な注意を払うことをお勧めします。将来の仕様は、複数の暗号化が意図されている場合と、避けるべき時期を明確に定義する必要があります。
Abstract
概要
This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP).
このメモは、ホストIDプロトコル（HIP）で使用するユーザーデータパケットの送信のためのカプセル化されたセキュリティペイロード（ESP）ベースのメカニズムを指定します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 4
3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 4
3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 4
3.2.1. Semantics of the Security Parameter Index (SPI) . . . 5
3.3. Security Association Establishment and Maintenance . . . . 6
3.3.1. ESP Security Associations . . . . . . . . . . . . . . 6
3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.3. Security Association Management . . . . . . . . . . . 7
3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 7
3.3.5. Supported Transforms . . . . . . . . . . . . . . . . . 7
3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 8
3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 8
3.4. IPsec and HIP ESP Implementation Considerations . . . . . 8
4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Setting Up an ESP Security Association . . . . . . . . 9
4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 10
5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 10
5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 13
5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 14
5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 14
5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 14
5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 16
5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 16
5.3.2. Responding to the Rekeying Initialization . . . . . . 17
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 17
5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 17
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Processing Outgoing Application Data . . . . . . . . . . . 18
6.2. Processing Incoming Application Data . . . . . . . . . . . 19
6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 19
6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 19
6.5. Processing Incoming Initialization Reply (I2) . . . . . . 20
6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 20
6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 20
6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 20
6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 22
6.9.1. Processing UPDATE Packet: No Outstanding Rekeying
Request . . . . . . . . . . . . . . . . . . . . . . . 22
6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 23
6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 24
7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative references . . . . . . . . . . . . . . . . . . . 26
11.2. Informative references . . . . . . . . . . . . . . . . . . 26
Appendix A. A Note on Implementation Options . . . . . . . . . . 28
In the Host Identity Protocol Architecture [RFC4423], hosts are identified with public keys. The Host Identity Protocol [RFC5201] 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.
ホストIDプロトコルアーキテクチャ[RFC4423]では、ホストはパブリックキーで識別されます。ホストIDプロトコル[RFC5201]ベースエクスチェンジにより、2つの股関節サポートホストがお互いを認証し、自分自身の間に股関節関連を作成できます。基本交換中、ホストは、認証されたDiffie-Hellman Exchangeを使用して共有キーイング素材を生成します。
The HIP base exchange specification [RFC5201] 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 Encapsulated Security Payload (ESP) [RFC4303] based transport format and method. This document specifies how ESP is used with HIP to carry actual user data.
HIPベース交換仕様[RFC5201]は、実際の通信中に使用されるユーザーデータの輸送形式または方法を説明していません。カプセル化されたセキュリティペイロード（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.
より具体的には、このドキュメントは、股関節プロトコル拡張セットとその取り扱いを指定します。これらの拡張機能を使用して、ベースエクスチェンジ中にホスト間に1組のESPセキュリティ協会（SAS）が作成されます。結果として生じるESPセキュリティ協会は、基本交換中に生成されたキーイングマテリアル（キーマット）から描かれたキーを使用します。股関節関連と必要な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アドレスとの組み合わせの可能性）が間接的に使用され、ホストコンテキストを識別するため、追加の明示的なプロトコルヘッダーを回避します。
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.
股関節ベース交換は、2つのホスト間で股関節関連を設定するために使用されます。ベースエクスチェンジは、双方向のホスト認証と主要な材料生成を提供しますが、ホスト間のデータ通信を保護する手段を提供しません。このドキュメントでは、股関節ベース交換後のユーザーデータトラフィックを保護するための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 a new 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 new 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の使用をサポートするために、股関節ベース交換メッセージには、輸送されるパラメーターにいくつかの小さな追加が必要です。R1パケットでは、レスポンダーは、イニシエーターに送信する前に、新しいESP_TRANSFORMパラメーターに可能なESP変換を追加します。イニシエーターは、提案された変換を取得し、提案された変換の1つを選択し、ESP_TRANSFORMパラメーターのI2パケットに追加します。このI2パケットでは、イニシエーターは、応答者からイニシエーターに流れるESPトラフィックに使用したいSPI値も送信します。この情報は、新しいESP_INFOパラメーターを使用して実行されます。ESP SAのセットアップを完成させると、ResponderはSPI値をR2パケットのイニシエーターに送信し、ESP_INFOを使用して再び送信します。
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.
ESPパケット処理は、股関節でさまざまな方法で実装できます。標準に準拠していないIPSEC実装[RFC4303]を使用できるように実装することができます。
When a standards compliant IPsec implementation that uses IP addresses in the SPD and Security Association Database (SAD) is used, the packet processing may take the following steps. For outgoing packets, assuming that the upper-layer pseudoheader 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 to 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およびSecurity Associationデータベース（SAD）でIPアドレスを使用する標準に準拠したIPSEC実装が使用される場合、パケット処理は次の手順を実行する場合があります。発信パケットの場合、上層層の擬似ヘッダーがIPアドレスを使用して構築されていると仮定すると、実装はホストIDタグ（ヒット）を使用して上層層チェックサムを再計算し、その後、パケットソースと宛先アドレスを対応するIPアドレスに変更します。パケットは、トランスポートモードの処理のためにIPSEC ESPに送信され、そこから暗号化されたパケットがネットワークに送信されます。ESPパケットが受信されると、パケットが最初にIPSEC ESPトランスポートモードの処理に配置され、復号化後、ソースと宛先のIPアドレスがヒットに置き換えられ、最後に、上層層チェックサムが検証されてから、パケットを上部に渡す前に検証されます。層。
An alternative way to implement packet processing is the BEET (Bound End-to-End Tunnel) [ESP-BEET] mode. 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.
パケット処理を実装する別の方法は、ビート（エンドツーエンドトンネル）[ESP-Beet]モードです。ビートモードでは、ESPパケットはトランスポートモードパケットとしてフォーマットされますが、接続のセマンティクスはトンネルモードの場合と同じです。パケットの「外側」アドレスはIPアドレスであり、「内側」アドレスはヒットです。発信トラフィックの場合、パケットが暗号化された後、パケットのIPヘッダーはヒットの代わりにIPアドレスを含む新しいヘッダーに変更され、パケットがネットワークに送信されます。ESPパケットを受信すると、SPI値は、整合性保護とともに、パケットを適切なヒットペアに安全に関連付けることができます。パケットヘッダーは、ヒットを含む新しいヘッダーに置き換えられ、パケットが復号化されます。
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は、股関節で使用すると重要性が追加されています。それらは一対のヒットの圧縮表現です。したがって、SPIは、アドレスマッピングなどのサービスを提供する際に、中間システムで使用できます。SPIは受信機で重要であるため、DSTは宛先IPアドレスである<DST、SPI>のみが、特定の時点でレシーバーヒットを一意に識別することに注意してください。いくつかのホストが同じ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の選択はランダムでなければなりません。ESP仕様[RFC4303]のセクション2.1のルールに従う必要があります。特定のホストとの股関節交換ごとに別のSPIを使用する必要があります。これは、リプレイ攻撃を避けるためです。さらに、ホストが再キーになった場合、SPIを変更する必要があります。さらに、ホストが別のIPアドレスを使用して変更すると、SPIが変更される場合があります。
One method for SPI creation that meets the above criteria would be to concatenate the HIT with a 32-bit random or sequential number, hash this (using SHA1), and then use the high-order 32 bits as the SPI.
上記の基準を満たすSPI作成の1つの方法は、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は、ベース股関節交換の3番目（I2）および4番目（R2）パケットでピアに通信されます。SPIの変化は、ESP_INFOパラメーターで通知されます。
In HIP, ESP Security Associations are setup between the HIP nodes during the base exchange [RFC5201]. 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.
股関節では、ESPセキュリティ関連は、基本交換中に股関節ノード間にセットアップされます[RFC5201]。既存のESP SASは、更新メッセージを使用して後で更新できます。ESP SAを後で更新する理由は、たとえば、シーケンス番号のロールオーバーのためにSAを再キーする必要がある可能性があります。
Upon setting up a HIP association, each association is linked to two ESP SAs, one for incoming packets and one for outgoing packets. The Initiator's incoming SA corresponds with the Responder's outgoing one, and vice versa. The Initiator defines the SPI for its incoming association, as defined in Section 3.2.1. This SA is herein called 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.
股関節関連を設定すると、各関連付けは2つのESP SASにリンクされています。1つは着信パケット用、もう1つは発信パケット用です。イニシエーターの着信SAは、レスポンダーの発信者と対応し、その逆も同様です。イニシエーターは、セクション3.2.1で定義されているように、その着信関連のSPIを定義します。このSAはここでは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で定義されているキーマットから派生しています。レスポンダーは、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 [RFC5201].
最初のセッションキーは、[RFC5201]で指定されているように、ヒップキーが描画された後、生成されたキーイング材料であるキーマットから描かれています。
When the HIP association is removed, the related ESP SAs MUST also be removed.
股関節関連が削除された場合、関連するESP SASも削除する必要があります。
After the initial HIP base exchange and SA establishment, both hosts are in the ESTABLISHED state. There are no longer Initiator and Responder roles and the association is symmetric. In this subsection, the party that initiates the rekey procedure is denoted with I' and the peer with R'.
最初の股関節ベース交換とSA施設の後、両方のホストが確立された状態にあります。イニシエーターとレスポンダーの役割はなく、関連付けは対称です。このサブセクションでは、Rekey手順を開始する当事者は、I 'とPeer with 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.
既存の股関節が作成したESP SAは、股関節関連の存続期間中に更新する必要がある場合があります。このドキュメントは、更新メッセージを使用して、既存の股関節が作成した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を参照）。必要な情報を含む更新パケットを作成し、ピアノードに送信します。古いSASはまだ使用されており、ローカルポリシーが許可されています。
R', after receiving and processing the UPDATE (see Section 6.9), generates new SAs: SA-I'R' and SA-R'I'. It does not take the new outgoing SA into use, but still uses the old one, so there temporarily exists 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 'は、更新を受信および処理した後（セクション6.9を参照）、新しいSAS：SA-I'R'とSA-R'I 'を生成します。新しい発信SAを使用することはありませんが、それでも古いSAを使用しているため、同じピアホストに向かって2つのSAペアが一時的に存在します。新しい発信SAであるSPI-R'I 'のSPIは、更新パケットの受信ESP_INFOパラメーターで指定されています。新しい着信SAの場合、R 'は新しいSPI値、SPI-I'R'を生成し、Response 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.
rから応答更新を受信すると、セクション6.9：SA-I'R 'およびSA-R'I'で説明されているように、新しいSASが生成されます。新しい発信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のトラフィックを受け取ったとき、またはRekeyingの完了を確認するUpdate ACKを受信したときに、新しい発信SAの使用を開始します。この後、r 'は古いSASを削除できます。同様に、I 'が新しい着信SAからトラフィックを受け取ると、古いSASを安全に削除できます。
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つのヒットによってインデックス付けされています（システムが複数ヒットする可能性があるため、ローカルとリモートの両方のヒット）。すべてのSASには不活動タイマーが推奨されます。状態が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 IKE.
ESPのSPIは、股関節交換後のすべてのパケットからの股関節データの簡単な圧縮を提供します。これには、ヒットペアセキュリティ協会（およびSPI）が必要であり、IKEのような他の主要な管理プロトコルに対する政策の粒度の低下が必要です。
When a host updates the ESP SA, it provides a new inbound SPI to and gets a new outbound SPI from its partner.
ホストがESP SAを更新すると、新しいインバウンドSPIを提供し、パートナーから新しいアウトバウンドSPIを取得します。
All HIP implementations MUST support AES-CBC [RFC3602] and HMAC-SHA-1-96 [RFC2404]. 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-CBC [RFC3602]およびHMAC-SHA-1-96 [RFC2404]をサポートする必要があります。イニシエーターがレスポンダーが提供する変換のいずれをサポートしていない場合、交渉を放棄し、サポートされていない変換に関する通知メッセージでピアに通知する必要があります。
In addition to AES-CBC, all implementations MUST implement the ESP NULL encryption algorithm. When the ESP NULL encryption is used, it MUST be used together with SHA1 or MD5 authentication as specified in Section 5.1.2
AES-CBCに加えて、すべての実装はESP Null暗号化アルゴリズムを実装する必要があります。ESP Null暗号化を使用する場合、セクション5.1.2で指定されているように、SHA1またはMD5認証と一緒に使用する必要があります。
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が股関節で使用される場合、シーケンス番号フィールドは必須です。アンチレプレイ保護は、股関節で確立されたESP SAで使用する必要があります。ESPを股関節で使用する場合、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. The default timeout value is 15 minutes. 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.
股関節は生涯を交渉しません。すべての寿命はローカルポリシーです。股関節の実装がサポートする必要がある唯一の寿命は、シーケンス番号ロールオーバー（リプレイ保護のため）であり、非アクティブなESP SASのタイミングをサポートする必要があります。SAは、そのSAを使用してパケットを受信していない場合はタイムアウトします。デフォルトのタイムアウト値は15分です。実装は、さまざまなESP変換の寿命をサポートする場合があります。各実装は、非アクティビティタイムアウトのヒットごとの構成を実装して、不活性であっても、静的に構成された股関節関連を数日間生き続けることができます。
When HIP is run on a node where a standards compliant IPsec is used, some issues have to be considered.
標準に準拠したIPSECが使用されるノードで股関節を実行する場合、いくつかの問題を考慮する必要があります。
The HIP implementation must be able to co-exist with other IPsec keying protocols. When the HIP implementation selects the SPI value, it may lead to a collision if not implemented properly. To avoid the possibility for a collision, the HIP implementation MUST ensure that the SPI values used for HIP SAs are not used for IPsec or other SAs, and vice versa.
HIPの実装は、他のIPSECキーイングプロトコルと共存できる必要があります。股関節の実装がSPI値を選択すると、適切に実装されないと衝突につながる可能性があります。衝突の可能性を回避するために、股関節の実装は、股関節SASに使用されるSPI値がIPSECまたは他のSASに使用されないことを保証する必要があります。
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 checksum recalculated (as described in Section 3.2, paragraph 2) and data MUST NOT be passed to the SP or SA created by the HIP.
アウトバウンドトラフィックの場合、2つ（股関節用に1つ、IPSEC用に1つ）がある場合、SPDまたは（調整された）SPDSは、股関節処理用のパケットに股関節対応SAが与えられ、IPSEC処理用のパケットにIPSECが与えられていることを確認する必要があります。-Enabled SA。その後、SPは一致するSAにバインドする必要があり、非ヒップパケットはこのSAによって処理されません。股関節を使用していないソケットに由来するデータは、チェックサムが再計算されてはならない（セクション3.2、パラグラフ2で説明）、データを股関節によって作成したSPまたはSAに渡すことはできません。
Incoming data 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 [RFC5201].
股関節によってネゴシエートされていないSAを使用した着信データパケットは、セクション3.2、パラグラフ2に記載されているように処理してはなりません。SPIは、パケットの復号化のための正しいSAを識別し、パケットに上層層チェックサムがあることを識別するために使用する必要があります。これは[RFC5201]で指定されているように計算されます。
In this section, the protocol for setting up an ESP association to be used with HIP association is described.
このセクションでは、股関節関連で使用するESP関連を設定するためのプロトコルについて説明します。
Setting up an ESP Security Association between hosts using HIP consists of three messages passed between the hosts. The parameters are included in R1, I2, and R2 messages during base exchange.
HIPを使用してホスト間でESPセキュリティアソシエーションを設定することは、ホスト間で渡された3つのメッセージで構成されています。パラメーターは、基本交換中のR1、I2、およびR2メッセージに含まれています。
Initiator Responder
イニシエーターレスポンダー
I1
---------------------------------->
R1: ESP_TRANSFORM
<----------------------------------
I2: ESP_TRANSFORM, ESP_INFO
---------------------------------->
R2: ESP_INFO
<----------------------------------
Setting up an ESP Security Association between HIP hosts requires three messages to exchange the information that is required during an ESP communication.
HIPホスト間のESPセキュリティ関連のセットアップには、ESP通信中に必要な情報を交換するために3つのメッセージが必要です。
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変換を定義します。
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への応答が含まれています。送信者は、R1メッセージのESP_TRANSFORMパラメーターから提案されているESP変換のいずれかを選択し、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 two messages. The HIP UPDATE message is used to update the parameters of an existing ESP SA. The UPDATE mechanism and message is defined in [RFC5201], and the additional parameters for updating an existing ESP SA are described here.
更新プロセスは、2つのメッセージを使用して達成されます。HIP更新メッセージは、既存のESP SAのパラメーターを更新するために使用されます。更新メカニズムとメッセージは[RFC5201]で定義されており、既存の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.
次の写真は、既存のESPSAが更新されたときの典型的な交換を示しています。メッセージには、更新メカニズムに必要な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 [RFC5201].
ESP SAの更新を希望するホストは、更新メッセージを作成して送信します。このメッセージには、使用された古いSPI値、使用する新しいSPI値、キーイング材料のインデックス値を含むESP_INFOパラメーターが含まれており、次のキーが描画される場所からポイントを与えます。新しいキーイング材料を生成する必要がある場合、更新メッセージには[RFC5201]で定義されている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.
既存のESPSAの更新を要求する更新メッセージを受信するホストは、更新メッセージで返信する必要があります。返信メッセージでは、ホストは、対応する値（古いSPI、新しいSPI、キーイングマテリアルインデックス）を含むESP_INFOパラメーターを送信します。着信アップデートにdiffie_hellmanパラメーターが含まれている場合、返信パケットにはdiffie_hellmanパラメーターも含まれている必要があります。
In this section, new and modified HIP parameters are presented, as well as modified HIP packets.
このセクションでは、新しい修正された股関節パラメーターと、変更された股関節パケットを提示します。
Two new HIP parameters are defined for setting up ESP transport format associations in HIP communication and for rekeying existing ones. Also, the NOTIFY parameter, described in [RFC5201], has two new error parameters.
HIP通信におけるESP輸送形式の関連付けを設定し、既存のものを再キーするために、2つの新しい股関節パラメーターが定義されています。また、[RFC5201]で説明されているNotifyパラメーターには、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 LETIMEの古いSPI、新しいSPI、およびその他の情報ESP_TRANSFORM4095変数ESP暗号化と認証変換
During the establishment and update of an ESP SA, the SPI value of both hosts must be transmitted between the hosts. During the establishment and update of an ESP SA, the SPI value of both hosts must be transmitted between the hosts. In addition, hosts need the index value to the KEYMAT when they are drawing keys from the generated keying material. The ESP_INFO parameter is used to transmit the SPI values and the KEYMAT index information between the hosts.
ESP SAの確立と更新中、両方のホストのSPI値をホスト間で送信する必要があります。ESP SAの確立と更新中、両方のホストのSPI値をホスト間で送信する必要があります。さらに、ホストは、生成されたキーイング素材からキーを描画しているときに、キーマットのインデックス値を必要とします。ESP_INFOパラメーターは、ホスト間のSPI値とキーマットインデックス情報を送信するために使用されます。
During the initial ESP SA setup, the hosts send the SPI value that they want the peer to use when sending ESP data to them. The value is set in the NEW SPI field of the ESP_INFO parameter. In the initial setup, an old value for the SPI does not exist, thus the OLD SPI value field 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 case of multihomed HIP hosts [RFC5206]. However, such use is beyond the scope of this specification.
最初のESP SAセットアップ中、ホストは、ESPデータを送信するときにピアに使用したいSPI値を送信します。値は、ESP_INFOパラメーターの新しいSPIフィールドに設定されています。最初のセットアップでは、SPIの古い値は存在しません。したがって、古いSPI値フィールドはゼロに設定されます。股関節ホストの間に追加のSAがセットアップされると、古いSPIフィールド値もゼロになる場合があります。ただし、このような使用は、この仕様の範囲を超えています。
RFC 4301 [RFC4301] describes how to establish multiple SAs to properly support QoS. If different classes of traffic (distinguished by Differentiated Services Code Point (DSCP) bits [RFC3474], [RFC3260]) are sent on the same SA, and if the receiver is employing the optional anti-replay feature available in ESP, this could result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. Therefore, a sender SHOULD put traffic of different classes but with the same selector values on different SAs to support Quality of Service (QoS) appropriately. To permit this, the implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver with the same selectors. Distribution of traffic among these parallel SAs to support QoS is locally determined by the sender and is not negotiated by HIP. The receiver MUST process the packets from the different SAs without prejudice. It is possible that the DSCP value changes en route, but this should not cause problems with respect to IPsec processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation.
RFC 4301 [RFC4301]は、QoSを適切にサポートするために複数のSAを確立する方法について説明します。異なるクラスのトラフィック（差別化されたサービスコードポイント（DSCP）ビット[RFC3474]、[RFC3260]によって区別される）が同じSAで送信され、受信機がESPで利用可能なオプションのアンチレプレイ機能を使用している場合、これは結果として生じる可能性があります。この機能で使用されている風のメカニズムにより、優先度の低いパケットの不適切な破棄。したがって、送信者は異なるクラスのトラフィックを配置する必要がありますが、異なるSASに同じセレクター値を使用して、サービス品質（QO）を適切にサポートする必要があります。これを許可するには、実装により、同じセレクターを持つ特定の送信者とレシーバー間の複数のSAの確立とメンテナンスが許可されなければなりません。QoSをサポートするためのこれらの並列SAS間のトラフィックの分布は、送信者によってローカルに決定され、股関節によって交渉されません。受信者は、偏見なく異なるSASからパケットを処理する必要があります。DSCP値が途中で変更される可能性はありますが、これはSA選択に値が使用されていないため、IPSEC処理に関して問題を引き起こすべきではなく、SA/パケット検証の一部としてチェックしてはなりません。
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.
キーマットインデックス値は、ESP SASのキーイング素材が描かれているキーマットの場所を指します。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 use of a key. Rekeying ends the current SAs and starts new ones on both peers.
股関節によって確立されたSAの存続期間中、ホストの1人がシーケンス番号を1つとRekeyにリセットする必要がある場合があります。再キーイングの理由は、ESPでの近づいたシーケンス番号ラップ、またはキーの使用に関するローカルポリシーの可能性があります。再キーイングは現在のSASを終了し、両方のピアで新しいSASを開始します。
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.
タイプ65の長さ12キーマットインデックス、バイトで、キーマットからESPキーを引き続き描画し続けます。パケットに新しいdiffie-hellmanキーが含まれ、esp_infoが更新パケットに送信される場合、フィールドはゼロでなければなりません。ESP_INFOが基本交換メッセージに含まれている場合、KeyMatインデックスには、ESP SAキーが描かれている場所からのインデックス値が必要です。このフィールドの長さは、keymatから描画できるキーイング素材の量を制限することに注意してください。その量を超えた場合、パケットには新しいdiffie-hellmanキーが含まれている必要があります。このSAに関連付けられたアドレスに送信されたデータの古いSPI古いSPI。これが最初のSAセットアップである場合、古いSPI値はゼロです。
NEW SPI new SPI for data sent to address(es) associated with this SA.
このSAに関連付けられたアドレスに送信されたデータの新しいSPI新しい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パラメーターに変換ファミリの選択を送信し、ピアは提案された値のいずれかを選択し、応答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長さの長さはオクテットの長さで、送信時にタイプ、長さ、およびパディングは予約されたゼロを除く、受信したときに無視されます。
The following Suite IDs are defined in RFC 5201 [RFC5201]:
次のスイートIDは、RFC 5201 [RFC5201]で定義されています。
Suite ID Value
スイートID値
RESERVED 0
AES-CBC with HMAC-SHA1 1
3DES-CBC with HMAC-SHA1 2
3DES-CBC with HMAC-MD5 3
BLOWFISH-CBC with HMAC-SHA1 4
NULL with HMAC-SHA1 5
NULL with HMAC-MD5 6
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 transport 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-CBC with HMAC-SHA1 and NULL with HMAC-SHA1.
必須の実装：HMAC-SHA1を使用したAES-CBCおよびHMAC-SHA1を使用したnull。
Under some conditions, it is possible to use Traffic Flow Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the definition of such operation is future work and must be done in a separate specification.
いくつかの条件下では、ESPを使用してトラフィックフローの機密性（TFC）[RFC4303]を使用することができます。ただし、このような操作の定義は将来の作業であり、別の仕様で行う必要があります。
The HIP base specification defines a set of NOTIFY error types. The following error types are required for describing errors in ESP Transform crypto suites during negotiation.
ヒップベースの仕様は、通知エラータイプのセットを定義します。交渉中にESP変換暗号スイートのエラーを説明するには、次のエラータイプが必要です。
NOTIFY PARAMETER - ERROR TYPES Value
------------------------------ -----
NO_ESP_PROPOSAL_CHOSEN 18
NO_ESP_PROPOSAL_CHOSEN 18
None of the proposed ESP Transform crypto suites was acceptable.
提案されているESP Transform Crypto Suitesのいずれも受け入れられませんでした。
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 Transform Crypto Suiteは、Responderが提供するものに対応していません。
The ESP Security Association is set up during the base exchange. The following subsections define the ESP SA setup procedure using both base exchange messages (R1, I2, R2) and UPDATE messages.
ESPセキュリティ協会は、基本交換中に設定されます。次のサブセクションでは、ベース交換メッセージ（R1、I2、R2）と更新メッセージの両方を使用して、ESP SAセットアップ手順を定義します。
The ESP_TRANSFORM contains the ESP modes supported by the sender, in the order of preference. All implementations MUST support AES-CBC [RFC3602] with HMAC-SHA-1-96 [RFC2404].
ESP_TRANSFORMには、設定の順に、送信者がサポートするESPモードが含まれています。すべての実装は、HMAC-SHA-1-96 [RFC2404]でAES-CBC [RFC3602]をサポートする必要があります。
The following figure shows the resulting R1 packet layout.
次の図は、結果のR1パケットレイアウトを示しています。
The HIP parameters for the R1 packet:
R1パケットのヒップパラメーター：
IP ( HIP ( [ R1_COUNTER, ] PUZZLE, DIFFIE_HELLMAN, HIP_TRANSFORM, ESP_TRANSFORM, HOST_ID, [ ECHO_REQUEST, ] HIP_SIGNATURE_2 ) [, ECHO_REQUEST ])
IP（HIP（[r1_counter、]パズル、diffie_hellman、hip_transform、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キーが描かれるキーマットインデックスが含まれています。古いSPI値はゼロに設定されています。
The ESP_TRANSFORM contains the ESP mode selected by the sender of R1. All implementations MUST support AES-CBC [RFC3602] with HMAC-SHA-1-96 [RFC2404].
ESP_TRANSFORMには、R1の送信者によって選択されたESPモードが含まれています。すべての実装は、HMAC-SHA-1-96 [RFC2404]でAES-CBC [RFC3602]をサポートする必要があります。
The following figure shows the resulting I2 packet layout.
次の図は、結果のi2パケットレイアウトを示しています。
The HIP parameters for the I2 packet:
i2パケットのヒップパラメーター：
IP ( HIP ( ESP_INFO, [R1_COUNTER,] SOLUTION, DIFFIE_HELLMAN, HIP_TRANSFORM, ESP_TRANSFORM, ENCRYPTED { HOST_ID }, [ ECHO_RESPONSE ,] HMAC, HIP_SIGNATURE [, ECHO_RESPONSE] ) )
IP（hip（esp_info、[r1_counter、] solution、diffie_hellman、hip_transform、esp_transform、necrypted {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には、この関連付けのR2の送信者のSPI値があるESP_INFOパラメーターが含まれています。ESP_INFOには、ESP SAキーが描かれている場所を指定するキーマットインデックス値もあります。
The following figure shows the resulting R2 packet layout.
次の図は、結果のR2パケットレイアウトを示しています。
The HIP parameters for the R2 packet:
R2パケットのヒップパラメーター：
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での更新は、SEQ_Rを使用したアップデートでピギーバックする必要はありません。それは別々にAckedにされているかもしれません（この場合、シーケンスには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で股関節を使用すると、更新パケットは再キーイングを開始するために使用されます。更新パケットはESP_INFOを運ぶ必要があり、diffie_hellmanパラメーターを運ぶ場合があります。
Intermediate systems that use the SPI will have to inspect HIP packets for those that carry rekeying information. The packet is signed for the benefit of the intermediate systems. Since intermediate systems may need the new SPI values, the contents cannot be encrypted.
SPIを使用する中間システムでは、情報を再キーキングしている人が股関節パケットを検査する必要があります。パケットは、中間システムの利益のために署名されています。中間システムには新しいSPI値が必要になる場合があるため、内容を暗号化することはできません。
The following figure shows the contents of a rekeying initialization UPDATE packet.
次の図は、再キーイングの初期化更新パケットの内容を示しています。
The HIP parameters for the UPDATE packet initiating rekeying:
再キーイングを開始する更新パケットのヒップパラメーター：
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.
更新ACKは、初期化の再キーイングの更新を確認するために使用されます。承認更新パケットはESP_INFOを運ぶ必要があり、diffie_hellmanパラメーターを搭載する場合があります。
Intermediate systems that use the SPI will have to inspect HIP packets for packets carrying rekeying information. The packet is signed for the benefit of the intermediate systems. Since intermediate systems may need the new SPI values, the contents cannot be encrypted.
SPIを使用する中間システムでは、情報を運ぶパケットの股関節パケットを検査する必要があります。パケットは、中間システムの利益のために署名されています。中間システムには新しいSPI値が必要になる場合があるため、内容を暗号化することはできません。
The following figure shows the contents of a rekeying acknowledgment UPDATE packet.
次の図は、再キーイングの確認更新パケットの内容を示しています。
The HIP parameters for the UPDATE packet:
更新パケットのヒップパラメーター：
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 [RFC5201]. In this section, we describe the actions related to ESP security associations.
ICMPメッセージ処理は、主にヒップベース仕様[RFC5201]で説明されています。このセクションでは、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 SPI field in the ESP header.
HIP実装が認識されていないSPI番号を持つESPパケットを受信した場合、ESPのSPIフィールドの開始を指すポインターが型「パラメーター問題」を持つICMPパケットで応答する場合があります（応答を制限するレートの対象となります）ヘッダ。
Packet processing is mainly defined in the HIP base specification [RFC5201]. 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 253) MUST bypass ESP processing.
パケット処理は、主に股関節ベース仕様[RFC5201]で定義されています。このセクションでは、ESP輸送形式が使用されている場合のパケット処理の変更と新しい要件について説明します。すべての股関節パケット（現在はプロトコル253）がESP処理をバイパスする必要があることに注意してください。
Outgoing application data handling is specified in the HIP base specification [RFC5201]. 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. In a typical implementation, this will result in a BEET-mode ESP packet being sent. BEET-mode [ESP-BEET] was introduced above in Section 3.2. The following additional steps define the conceptual processing rules for outgoing ESP protected datagrams.
発信アプリケーションデータ処理は、HIPベース仕様[RFC5201]で指定されています。ESP輸送形式が使用され、指定された<ソース、宛先>ヒットペアのアクティブなヒップセッションがある場合、発信データグラムはESPセキュリティ協会を使用して保護されます。典型的な実装では、これによりビートモードESPパケットが送信されます。ビートモード[ESP-Beet]は、上記のセクション3.2で紹介されました。次の追加の手順は、発信ESP保護されたデータグラムの概念処理ルールを定義します。
1. Detect the proper ESP SA using the HITs in the packet header or other information associated with the packet
1. パケットヘッダーのヒットまたはパケットに関連するその他の情報を使用して、適切なESP SAを検出します
2. Process the packet normally, as if the SA was a transport mode SA.
2. SAが輸送モードSAであるかのように、通常、パケットを処理します。
3. Ensure that the outgoing ESP protected packet has proper IP header format depending on the used IP address family, and proper IP addresses in its IP header, e.g., by replacing HITs left by the ESP processing. Note that this placement of proper IP addresses MAY also be performed at some other point in the stack, e.g., before ESP processing.
3. 発信ESP保護されたパケットには、使用済みのIPアドレスファミリに応じて適切なIPヘッダー形式があり、IPヘッダーの適切なIPアドレス、たとえばESP処理を残したヒットを交換することにより、確実に。適切なIPアドレスのこの配置は、ESP処理前のスタックの他のポイントでも実行される場合があることに注意してください。
Incoming HIP user data packets arrive as ESP protected packets. In the usual case, the receiving host has a corresponding ESP security association, identified by the SPI and destination IP address in the packet. However, if the host has crashed or otherwise lost its HIP state, it may not have such an SA.
着信股関節ユーザーデータパケットは、ESP保護されたパケットとして到着します。通常の場合、受信ホストには、パケット内のSPIおよび宛先IPアドレスによって識別される対応するESPセキュリティ協会があります。ただし、ホストがクラッシュしたか、その他の股関節状態を失った場合、そのような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.
基本的な着信データ処理は、ヒップベースの仕様で指定されています。データトラフィックを保護するために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が非ヒップESP SAである場合、標準のIPSECルールに従ってパケットを処理します。SPIでSASが識別されていない場合、ホストはセクション5.4で定義されているようにICMPパケットを送信できます。失われた状態を処理する方法は、実装の問題です。
2. If the SPI matches with an active HIP-based ESP SA, the IP addresses in the datagram are replaced with the HITs associated with the SPI. Note that this IP-address-to-HIT conversion step MAY also be performed at some other point in the stack, e.g., after ESP processing. Note also that if the incoming packet has IPv4 addresses, the packet must be converted to IPv6 format before replacing the addresses with HITs (such that the transport checksum will pass if there are no errors).
2. SPIがアクティブなHIPベースのESP SAと一致する場合、データグラムのIPアドレスはSPIに関連付けられたヒットに置き換えられます。このIPアドレスからヒットへの変換ステップは、ESP処理後のスタックの他のポイントでも実行される場合があることに注意してください。また、着信パケットにIPv4アドレスがある場合、アドレスをヒットに置き換える前にパケットをIPv6形式に変換する必要があることに注意してください（エラーがない場合は輸送チェックサムが通過するように）。
3. The transformed packet is next processed normally by ESP, as if the packet were a transport mode packet. The packet may be dropped by ESP, as usual. In a typical implementation, the result of successful ESP decryption and verification is a datagram with the associated HITs as source and destination.
3. 変換されたパケットは、まるでパケットがトランスポートモードパケットであるかのように、ESPによって通常処理されます。パケットは、いつものようにESPによってドロップされる場合があります。典型的な実装では、ESPの復号化と検証が成功した結果は、関連するヒットをソースと宛先として持つデータグラムです。
4. The datagram is delivered to the upper layer. Demultiplexing the datagram to the right upper layer socket is performed as usual, except that the HITs are used in place of IP addresses during the demultiplexing.
4. データグラムは上層に配信されます。Datagramを右上層ソケットに逆流させることは、通常どおり実行されますが、非脱脂中にIPアドレスの代わりにヒットが使用されます。
The new HIP parameters described in this document, ESP_INFO and ESP_TRANSFORM, must be protected using HMAC and signature calculations. In a typical implementation, they are included in R1, I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as described in [RFC5201].
このドキュメントで説明されている新しい股関節パラメーターであるESP_INFOおよびESP_TRANSFORMは、HMACと署名計算を使用して保護する必要があります。典型的な実装では、[RFC5201]で説明されているように、R1、I2、R2、および更新パケットHMACおよび署名計算に含まれています。
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メッセージで初期化されています。受信ホスト（Initiator）は、提示された値から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 [RFC5201]).
I2で着信ESP SAの初期化応答を処理するには、次の手順が必要です。以下の手順では、I2が処理に受け入れられていることを想定しています（たとえば、[RFC5201]で説明されているようにヒット比較のためにドロップされていません）。
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の新しいSPIフィールドは、レスポンダーからインバウンドからイニシエーターにアウトバウンドするセキュリティ協会に使用されるSPIを取得するために解析されます。この最初のESP SA設立では、古いSPI値はゼロでなければなりません。KeyMatインデックスフィールドには、ESP SAキーが描かれているキーマットのインデックス値を含める必要があります。
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 初期化応答メッセージの処理が成功すると、可能な古いセキュリティ関連（股関節関連の以前の化身から残されているように）が削除され、新しいものがインストールされ、ファイナライズパケット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の新しいSPIフィールドを解析して、ESPセキュリティ協会にファイナライゼーションメッセージR2の送信者にインバウンドする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.
股関節ベースの仕様に記載されているように、システムが股関節関連をドロップする場合、関連する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 Rekeying中に、ホストは既存のキーイング素材から新しいキーを描くか、新しいキーが描かれている場所から生成されます。
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 Rekeing手順を開始する場合があります。その着信ESPシーケンスカウンターがオーバーフローしようとしている場合、再キーを開始する必要があります。システムは、再キーイングパケット交換が正常に完了するまで、キーリング素材を置き換えてはなりません。
Optionally, a system may include a new Diffie-Hellman key for use in new KEYMAT generation. New KEYMAT generation occurs prior to drawing the new keys.
オプションで、システムには、新しいキーマット生成で使用するための新しいdiffie-hellmanキーが含まれる場合があります。新しいキーマット生成は、新しいキーを描く前に発生します。
The rekeying procedure uses the UPDATE mechanism defined in [RFC5201]. 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 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.
再キーイング手順では、[RFC5201]で定義された更新メカニズムを使用します。各ピアは、セキュリティ協会のペアの半分（新しいSPI作成を含む）を更新する必要があるため、再キーイングプロセスでは、各側が更新を送信して受信する必要があります。次に、システムがピアにパラメーターを送信し、関連する更新メッセージのACKと対応するピアのパラメーターの両方を受け取ったときに、ESP SAを再キーします。ACKと必要な股関節パラメーターが異なる更新メッセージに到着する可能性があります。これは、システムがESP SAの更新を開始しないが、ピアからの更新リクエストに応答する場合、常に真実であり、2つのシステムがほぼ同時に更新を開始する場合にも発生する可能性があります。そのような場合、システムに未解決の更新リクエストがある場合、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. システムは、既存のキーマットを引き続き使用し続けるか、新しいキーマットを生成するかを決定します。後者の場合、システムは新しいdiffie-hellmanの公開キーを生成する必要があります。
2. The system creates an UPDATE packet, which contains the ESP_INFO parameter. In addition, the host may include the optional DIFFIE_HELLMAN parameter. If the UPDATE contains the DIFFIE_HELLMAN parameter, the KEYMAT Index in the ESP_INFO parameter MUST be zero, and the Diffie-Hellman group ID must be unchanged from that used in the initial handshake. If the UPDATE does not contain DIFFIE_HELLMAN, the ESP_INFO KEYMAT Index MUST be greater than or equal to the index of the next byte to be drawn from the current KEYMAT.
2. システムは、ESP_INFOパラメーターを含む更新パケットを作成します。さらに、ホストにはオプションのdiffie_hellmanパラメーターが含まれる場合があります。更新にdiffie_hellmanパラメーターが含まれている場合、ESP_INFOパラメーターのキーマットインデックスはゼロでなければならず、Diffie-hellmanグループIDは、最初の握手で使用されるものから変更されていなければなりません。更新にdiffie_hellmanが含まれていない場合、ESP_INFOキーマットインデックスは、現在のキーマットから描画される次のバイトのインデックスよりも大きくなければなりません。
3. The system sends the UPDATE packet. For reliability, the underlying UPDATE retransmission mechanism MUST be used.
3. システムは更新パケットを送信します。信頼性のために、基礎となる更新再送信メカニズムを使用する必要があります。
4. The system MUST NOT delete its existing SAs, but continue using them if its policy still allows. The rekeying procedure SHOULD be initiated early enough to make sure that the SA replay counters do not overflow.
4. システムは、既存のSASを削除してはなりませんが、ポリシーが許可されている場合は、それらを使用し続けてください。再キーキング手順は、SAリプレイカウンターがオーバーフローしないことを確認するのに十分な早期に開始する必要があります。
5. In case a protocol error occurs and the peer system acknowledges the UPDATE but does not itself send an ESP_INFO, the system may not finalize the outstanding ESP SA update request. To guard against this, a system MAY re-initiate the ESP SA update procedure after some time waiting for the peer to respond, or it MAY decide to abort the ESP SA after waiting for an implementation-dependent time. The system MUST NOT keep an outstanding ESP SA update request for an indefinite time.
5. プロトコルエラーが発生し、ピアシステムが更新を認めたが、それ自体がESP_INFOを送信しない場合、システムは未払いのESP SAアップデートリクエストを完成させない場合があります。これを防ぐために、システムは、ピアが応答するのを待ってしばらくしてESP SAアップデート手順を再インテッドするか、実装依存時間を待ってからESP SAを中止することを決定する場合があります。システムは、無期限に傑出したESP SAアップデートリクエストを維持してはなりません。
To simplify the state machine, a host MUST NOT generate new UPDATEs while it has an outstanding ESP SA update request, unless it is restarting the update process.
状態マシンを簡素化するために、ホストは、更新プロセスを再起動しない限り、未解決のESP SAアップデートリクエストを持っている間に新しい更新を生成してはなりません。
When a system receives an UPDATE packet, it must be processed if the following conditions hold (in addition to the generic conditions specified for UPDATE processing in Section 6.12 of [RFC5201]):
システムが更新パケットを受信した場合、次の条件が保持されている場合は処理する必要があります（[RFC5201]のセクション6.12で更新処理に指定された汎用条件に加えて）：
1. A corresponding HIP association must exist. This is usually ensured by the underlying UPDATE mechanism.
1. 対応する股関節関連が存在する必要があります。これは通常、基礎となる更新メカニズムによって保証されます。
2. The state of the HIP association is ESTABLISHED or R2-SENT.
2. 股関節協会の状態は確立されています。
If the above conditions hold, the following steps define the conceptual processing rules for handling the received UPDATE packet:
上記の条件が当てはまる場合、次の手順で、受信した更新パケットを処理するための概念処理ルールを定義します。
1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the received KEYMAT Index MUST be zero and the Group ID must match the Group ID in use on the association. If this test fails, the packet SHOULD be dropped and the system SHOULD log an error message.
1. 受信した更新にdiffie_hellmanパラメーターが含まれている場合、受信したキーマットインデックスはゼロでなければならず、グループIDは関連性で使用されているグループIDと一致する必要があります。このテストが失敗した場合、パケットをドロップし、システムがエラーメッセージを記録する必要があります。
2. If there is no outstanding rekeying request, the packet processing continues as specified in Section 6.9.1.
2. 未解決の再キーイングリクエストがない場合、セクション6.9.1で指定されているようにパケット処理が継続されます。
3. If there is an outstanding rekeying request, the UPDATE MUST be acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN) parameters must be saved, and the packet processing continues as specified in Section 6.10.
3. 未解決の再キーイングリクエストがある場合、更新を確認する必要があり、受信したESP_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パラメーターを使用して受信した更新パケットを処理するための概念処理ルールを定義します。
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アップデートを完了したときに、KeyMat生成で使用するために、新しく生成または受信されたDiffie-Hellmanキーを記録します。
2. If the system generated a new Diffie-Hellman key in the previous step, or if it received a DIFFIE_HELLMAN parameter, it sets the ESP_INFO KEYMAT Index to zero. Otherwise, the ESP_INFO KEYMAT Index MUST be greater than or equal to the index of the next byte to be drawn from the current KEYMAT. In this case, it is RECOMMENDED that the host use the KEYMAT Index requested by the peer in the received ESP_INFO.
2. システムが前のステップで新しいdiffie-hellmanキーを生成した場合、またはdiffie_hellmanパラメーターを受信した場合、esp_info keymatインデックスをゼロに設定します。それ以外の場合、ESP_INFO KeyMatインデックスは、現在のキーマットから描画される次のバイトのインデックス以上でなければなりません。この場合、ホストは受信したESP_INFOでピアが要求したキーマットインデックスを使用することをお勧めします。
3. The system creates an UPDATE packet, which contains an ESP_INFO parameter and the optional DIFFIE_HELLMAN parameter. This UPDATE would also typically acknowledge the peer's UPDATE with an ACK parameter, although a separate UPDATE ACK may be sent.
3. システムは、ESP_INFOパラメーターとオプションのdiffie_hellmanパラメーターを含む更新パケットを作成します。また、このアップデートは、通常、ACKパラメーターを使用したピアの更新を確認しますが、別の更新ACKが送信される場合があります。
4. The system sends the UPDATE packet and stores any received ESP_INFO and DIFFIE_HELLMAN parameters. At this point, it only needs to receive an acknowledgment for the newly sent UPDATE to finish ESP SA update. In the usual case, the acknowledgment is handled by the underlying UPDATE mechanism.
4. システムは更新パケットを送信し、受信したESP_INFOおよびDIFFIE_HELLMANパラメーターを格納します。この時点で、ESP SAアップデートを完了するために、新しく送信された更新の謝辞を受け取る必要があります。通常の場合、承認は基礎となる更新メカニズムによって処理されます。
A system finalizes rekeying when it has both received the corresponding UPDATE acknowledgment packet from the peer and it has successfully received the peer's UPDATE. The following steps are taken:
システムは、Peerから対応するアップデート確認パケットを受信し、ピアの更新を正常に受信したときに再キーイングを完成させます。次の手順が取られます。
1. If the received UPDATE messages contain a new Diffie-Hellman key, the system has a new Diffie-Hellman key due to initiating ESP SA update, or both, the system generates a new KEYMAT. If there is only one new Diffie-Hellman key, the old existing key is used as the other key.
1. 受信した更新メッセージに新しいdiffie-hellmanキーが含まれている場合、システムにはESP SAの更新を開始するため、またはその両方が新しいDiffie-Hellmanキーがあります。システムは新しいキーマットを生成します。新しい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. システムが前のステップで新しいキーマットを生成した場合、受信されたアップデートにdiffie-hellmanキーが含まれているかどうかに関係なく、キーマットインデックスをゼロに設定します。システムが新しいキーマットを生成しなかった場合、2つの（送信および受信）ESP_INFOパラメーターのより大きなキーマットインデックスを使用します。
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.
3. このシステムは、KeyMatインデックスから始まる新しい着信と発信のESP SASのキーを描き、新しい受信と発信のESP SASを準備します。発信SAのSPIは、ESP_INFOパラメーターで受信した新しいSPI値です。ESP_INFOがピアに送られたときに、着信SAのSPIが生成されました。再キーマットからキーマットから取得されたキーの順序は、セクション7で説明されているものと似ています。
Note, that only IPsec ESP keys are retrieved during the rekeying process, not the HIP keys.
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に関するデータを受信すると、古いSASを安全に削除する場合があります。
The processing of NOTIFY packets is described in the HIP base specification.
Notifyパケットの処理は、ヒップベースの仕様で説明されています。
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:
キーイング材料は、股関節ベースの仕様に記載されているように生成されます。基本交換中、初期キーは生成された材料から引き出されます。股関節関連のキーが描かれた後、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は、ヒット値が大きいホストを示し、HOST_Lはホストを低いヒット値で示します。ヒット値を比較すると、それらはネットワークバイトの順序で正の（符号なし）128ビット整数と解釈されます。
The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 exchange. Subsequent rekeys using UPDATE will only draw the four ESP keys from KEYMAT. Section 6.9 describes the rules for reusing or regenerating KEYMAT based on the rekeying.
4つのヒップキーは、股関節I1-> R2交換中にキーマットからのみ描かれています。更新を使用した後続のRekeysは、KeyMatから4つのESPキーのみを描画します。セクション6.9では、再キーイングに基づいてキーマットを再利用または再生するためのルールについて説明します。
The number of bits drawn for a given algorithm is the "natural" size of the keys. For the mandatory algorithms, the following sizes apply:
特定のアルゴリズムに描かれたビットの数は、キーの「自然な」サイズです。必須アルゴリズムの場合、次のサイズが適用されます。
AES 128 bits
AES 128ビット
SHA-1 160 bits
SHA-1 160ビット
NULL 0 bits
null 0ビット
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.
このドキュメントでは、データトラフィックを保護するための股関節ホスト間の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 [RFC4306]. This document specifies how the Host Identity Protocol is used to establish ESP Security Associations.
2つのノード間にESPセキュリティ関連を確立するには、さまざまな方法があります。これは、たとえばIKE [RFC4306]を使用して実行できます。このドキュメントは、ESPセキュリティ協会を確立するためにホストIDプロトコルを使用する方法を指定します。
The following issues are new or have changed from the standard ESP usage:
以下の問題は新品か、標準のESP使用量から変更されました。
o Initial keying material generation
o 初期キーイング材料生成
o Updating the keying material
o キーイング素材の更新
The initial keying material is generated using the Host Identity Protocol [RFC5201] 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 SA between the hosts is done during the base exchange, and the message exchange is protected using methods provided by base exchange. Changes in connection parameters means basically 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 is used.
最初のキーイング材料は、diffie-hellman手順を使用して、ホストIDプロトコル[RFC5201]を使用して生成されます。このドキュメントは、既存のESP SASを変更するために、ベース仕様で定義されている更新パケットの使用を拡張します。ホストは、diffie-hellman手順を使用して、新しいキーイング材料の生成を強制することができます。ホスト間のESP SAの初期セットアップは基本交換中に行われ、メッセージ交換はベース交換によって提供される方法を使用して保護されます。接続パラメーターの変更は、基本的に、更新メッセージの交換が完了すると、古いESP SAが削除され、新しいエスパンが生成されることを意味します。メッセージ交換は、HIP Associationキーを使用して保護されています。HMACとパケットの署名の両方が使用されます。
This document defines additional parameters and NOTIFY error types for the Host Identity Protocol [RFC5201].
このドキュメントでは、追加のパラメーターを定義し、ホストIDプロトコル[RFC5201]のエラータイプを通知します。
The new parameters and their type numbers are defined in Section 5.1.1 and Section 5.1.2, and they have been added to the Parameter Type namespace specified in [RFC5201].
新しいパラメーターとそのタイプ番号は、セクション5.1.1およびセクション5.1.2で定義されており、[RFC5201]で指定されたパラメータータイプ名空間に追加されています。
The new NOTIFY error types and their values are defined in Section 5.1.3, and they have been added to the Notify Message Type namespace specified in [RFC5201].
新しいNotifyエラータイプとその値はセクション5.1.3で定義されており、[RFC5201]で指定されたNotifyメッセージタイプ名空間に追加されています。
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 include Tom Henderson, Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. The authors also want to thank Charlie Kaufman for reviewing the document with his eye on the usage of crypto algorithms.
このドキュメントは、2005年の初めに基本「ホストIDプロトコル」仕様から分離されました。それ以来、多くの人々がコメントと修正提案を提供することにより、テキストに貢献してきました。人々のリストには、Tom Henderson、Jeff Ahrenholz、Jan Melen、Jukka Ylitalo、Miika Komuが含まれます。著者はまた、Cryptoアルゴリズムの使用に目を向けてドキュメントをレビューしてくれた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.
このドキュメントの履歴により、ほとんどのアイデアはベース「ホストIDプロトコル」仕様から継承されます。したがって、その仕様の謝辞セクションにある人々のリストは、このドキュメントにも有効です。多くの人々が貴重なフィードバックを与えており、名前が足りない人に謝罪しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404] Madson、C。およびR. Glenn、「ESPおよびAH内のHMAC-SHA-1-96の使用」、RFC 2404、1998年11月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]フランケル、S。、グレン、R。、およびS.ケリー、「AES-CBC暗号アルゴリズムとIPSECでの使用」、RFC 3602、2003年9月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P.、Ed。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[ESP-BEET] Nikander, P. and J. Melen, "A Bound End-to-End Tunnel (BEET) mode for ESP", Work in Progress, November 2007.
[ESP-Beet] Nikander、P。およびJ. Melen、「ESPのエンドツーエンドトンネル（ビート）モード」、2007年11月、作業中。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。
[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 3474, March 2003.
[RFC3474] Lin、Z。およびD. Pendarakis、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）リソース予約プロトコル - トラフィックエンジニアリング（RSVP -TE）の使用（ASON）（ASON）の拡張機能のためのIANA割り当てのドキュメント」、RFC3474、2003年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「Host Identity Protocol（HIP）Architecture」、RFC 4423、2006年5月。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] Henderson、T.、ed。、「ホストIDプロトコルによるエンドホストモビリティとマルチホミング」、RFC 5206、2008年4月。
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.
この仕様を複数の異なる方法で実装することができます。上記のように、これを実装する1つの可能な方法は、IPSECの下にIPヘッダーを書き換えることです。このような実装では、IPSECはIPv6トランスポートモードパケットを処理しているかのように使用され、IPv6ヘッダーはソースおよび宛先アドレスフィールドのIPアドレスの代わりにヒットを含みます。発信パケットでは、IPSEC処理後、ヒットとSPIに基づいて、ヒットが実際のIPアドレスに置き換えられます。着信パケットでは、IPSEC処理の前に、着信パケットのSPIに基づいて、IPアドレスがヒットに置き換えられます。このような実装では、すべてのIPSECポリシーはヒットに基づいており、上層層にはIPアドレスの代わりにヒットがあるパケットのみが表示されます。その結果、SPIスペースが別々に保たれている限り、股関節のサポートはIPSECの他の使用と矛盾しません。
Another way to implement this specification is to use the proposed BEET mode (A Bound End-to-End mode for ESP, [ESP-BEET]). The BEET mode provides some features from both IPsec tunnel and transport modes. The HIP uses HITs as the "inner" addresses and IP addresses as "outer" addresses, like IP addresses are used in the 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).
この仕様を実装する別の方法は、提案されたビートモード（ESPのバインドエンドツーエンドモード[ESP-Beet]）を使用することです。ビートモードは、IPSECトンネルモードと輸送モードの両方からいくつかの機能を提供します。HIPは、「内側」アドレスとしてヒットを使用し、IPアドレスはトンネルモードで使用されるように、「外側」アドレスとしてIPアドレスを使用します。ホスト間でパケットをトンネリングする代わりに、内側のアドレスと外側のアドレス間の変換が終了時に行われ、内側のアドレスが最初の股関節ネゴシエーションの後にワイヤーに送信されることはありません。ビートは、限られたトンネルモードセマンティクスを備えたIPSECトランスポートモードの構文（内側ヘッダーなし）を提供します（固定された論理内側アドレス - ヒット - および変更可能な外部IPアドレス）。
Compared to the option of implementing the required address rewrites outside of IPsec, BEET has one implementation level benefit. The BEET-way of implementing the address rewriting keeps all the configuration information 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 separate address rewriting DB are kept in synchrony. As a result, the BEET-mode-based way of implementing this specification is RECOMMENDED over the separate implementation.
必要なアドレスを実装するオプションと比較して、IPSEC以外で書き換えますが、BEETには1つの実装レベルの利点があります。アドレスの書き換えを実装するビートウェイは、すべての構成情報を1つの場所に保持します。一方、アドレス書き換えが個別に実装される場合、実装は、SADおよび別のアドレス書き換えDBの情報が同期して保持されることを確認する必要があります。その結果、この仕様を実装するビートモードベースの方法は、個別の実装よりも推奨されます。
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 ICSAlabs, An Independent Division of Verizon Business Systems 1000 Bent Creek Blvd, Suite 200 Mechanicsburg, PA USA
Robert Moskowitz Icsalabs、Verizon Business Systems 1000 Bent Creek Blvd、Suite 200 Mechanicsburg、ペンシルベニア州アメリカの独立部門1000
EMail: rgm@icsalabs.com
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
Pekka Nikander Ericsson Research Nomadiclab Jorvas Fin-02420フィンランド
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。