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)
ホスト識別プロトコル（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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
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などHIPおよびセキュリティ関連プロトコルの共存の場合、実装者は、これらの文書に指定されていない状況が発生する場合があります。例えば、SPDを保護するIPアドレスのサブネットを定義し、HIPホストがそのIPアドレス領域内に存在し、通信が複数回暗号化されている可能性があります。読者は、複雑なSPDの設定でHIPを実行するときに特別な注意を払うことをお勧めします。将来の仕様は、複数の暗号化が意図されたときに明確に定義する必要があり、それは避けるべきであるとき。
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).
このメモは、カプセル化セキュリティペイロード（ESP）ユーザデータパケットを伝送するためのベースのメカニズムは、ホストアイデンティティプロトコル（HIP）で使用するように指定します。
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.
ホストアイデンティティプロトコルアーキテクチャ[RFC4423]では、ホストは、公開鍵と識別されます。ホストアイデンティティプロトコル[RFC5201]塩基交換は、任意の2つのHIP支持ホストが互いを認証すると自身との間のHIPアソシエーションを作成することを可能にします。塩基交換の際に、ホストは、認証のDiffie-Hellman交換を使用して、共有鍵材料の一部を生成します。
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.
具体的には、この文書では、HIPプロトコル拡張とその取り扱いのセットを指定します。これらの拡張機能を使用して、ESPセキュリティアソシエーション（SA）のペアは、塩基交換時にホスト間で作成されます。得られたESPセキュリティアソシエーションは、塩基交換中に生成鍵材料（KEYMAT）から引き出されたキーを使用します。ホストとの間で確立されてきたESP SAを必要HIPアソシエーション後、ユーザデータ通信は、ESPを使用して保護されています。また、この文書では、既存のESPセキュリティアソシエーションを更新する方法を指定します。
It should be noted that representations of Host Identity are not carried explicitly in the headers of user data packets. Instead, the ESP Security Parameter Index (SPI) is used to indicate the right host context. The SPIs are selected during the HIP ESP setup exchange. For user data packets, ESP SPIs (in possible combination with IP addresses) are used indirectly to identify the host context, thereby avoiding any additional explicit protocol headers.
ホストのアイデンティティの表現がユーザデータパケットのヘッダに明示的に行われていないことに留意すべきです。その代わり、ESPセキュリティパラメータインデックス（SPI）は、右のホストコンテキストを示すために使用されます。 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.
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 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の使用をサポートするために、HIP基本交換メッセージが輸送パラメータにいくつかのマイナーな追加を必要としています。 R1パケットでは、Responderは可能ESPは、イニシエータに送信する前に、新しいESP_TRANSFORMパラメータに変換追加されます。イニシエータは、提案されたトランスフォームを取得し、それらの提案の変換のいずれかを選択し、ESP_TRANSFORMパラメータでI2パケットに追加します。このI2パケットでは、イニシエータはまた、イニシエータとレスポンダから流れるESPトラフィックに使用することを希望するSPI値を送信します。この情報は、新しいESP_INFOパラメータを使用して行われます。 ESP SAの設定を確定する場合、Responderは再び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.
ESPパケット処理は、HIPの異なる方法で実装することができます。標準規格に準拠し、無修正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とセキュリティアソシエーションデータベース（SAD）でIPアドレスを使用して標準に準拠IPsec実装を使用する場合は、パケット処理は、次の手順を実行することがあります。発信パケットのために、上層擬似ヘッダは、IPアドレスを使用して構築されていると仮定すると、実装は、ホストアイデンティティタグ（ヒット）を使用し、上層のチェックサムを再計算し、その後、バック対応する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値、一緒に整合性の保護と、パケットはしっかりと右HITペアに関連付けることができます。パケットヘッダは、ヒットを含む新しいヘッダに置き換えられ、パケットが復号化されます。
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で使用されています。 HIPで使用する場合ESPのSPIは、重要性を追加しました。彼らはヒットのペアの圧縮された表現です。したがって、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の規則に従わなければなりません。異なるSPIは、特定のホストと各HIP交換に使用されるべきです。これは、リプレイ攻撃を回避することです。また、時にホストキー更新、SPIを変更する必要があります。ホストは異なるIPアドレスを使用するように切り替わる場合はさらに、それはSPIを変更することがあります。
One method for SPI creation that meets the above criteria would be to concatenate the HIT with a 32-bit random or sequential number, hash this (using SHA1), and then use the high-order 32 bits as the SPI.
上記の基準を満たすSPIを作成するための一つの方法は、32ビットのランダム又は連続番号、ハッシュこの（使用SHA1）を有するHITを連結し、次にSPIとして上位32ビットを使用することであろう。
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は、第三（I2）内のピアとベースHIP交換の第（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.
HIPにおいて、ESPセキュリティアソシエーションは、塩基交換[RFC5201]の間HIPノード間で設定されています。既存の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 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.
HIPの関連付けを設定する際に、各アソシエーションは、二つESP SAを、着信パケットのための1つのパケットと発信パケットのための1つに連結されています。イニシエータの着信SAはレスポンダの発信1、およびその逆に対応します。セクション3.2.1で定義されるようにイニシエータは、その着信アソシエーションのためにSPIを定義します。このSAは、本明細書SA-RIと呼ばれ、対応するSPIは、SPI-RIと呼ばれています。それぞれ、レスポンダの受信SAはSPIがSPI-IR呼び出されると、イニシエータの発信SAに対応し、SA-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を作成します。レスポンダはI2処理の一部として、SA-RIを生成項7で定義されたキーは、KEYMATから誘導されます。 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]で指定されるように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の確立後、両方のホストは、確立された状態にあります。そこイニシエータとレスポンダの役割はもはやありませんとの関連は対称的です。このサブセクションでは、キーの再生成手順を開始する当事者は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.
私は」（6.8節を参照）に必要なESP SAの更新処理を開始します。これは、必要な情報を持つ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 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 'UPDATEを受信して処理した後は、（セクション6.9を参照）、新しいSAが生成：SA-I'R' とSA-R'I」。これは、使用されるように、新たな送信SAを取るが、それでも一時的に同じピアのホストに向けて2 SAのペアが存在しているので、そこに、古いものを使用していません。新しい発信SAのSPIは、SPI-R'I」、UPDATEパケットで受信ESP_INFOパラメータで指定されています。新しい着信SAのために、R「は新しいSPI値、SPI-I'Rを生成」、および応答更新パケットでそれを含みます。
When I' receives a response UPDATE from R', it generates new SAs, as described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the new outgoing SA immediately.
SA-I'R「とSA-R'I」I「はRからの応答UPDATEを受信した」とき、セクション6.9で説明したように、それは、新しい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を削除することができます。私は「新しい着信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.
（システムが複数のHITを有することができるので、ローカルとリモートの両方のヒット）SA対が2つのSPIと2本のヒットによってインデックスされます。非アクティブタイマーは、すべてのSAにお勧めです。状態はSAの削除を指示した場合、タイマーは、任意の遅れて到着したパケットを許可するように設定されています。
The SPIs in ESP provide a simple compression of the HIP data from all packets after the HIP exchange. This does require a per HIT-pair Security Association (and SPI), and a decrease of policy granularity over other Key Management Protocols like IKE.
ESPでのSPIは、HIP交換後のすべてのパケットからHIPデータの簡単な圧縮を提供しています。これはあたりHIT-ペアセキュリティアソシエーション（および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]をサポートしなければなりません。イニシエータは、レスポンダが提供するトランスフォームのいずれかをサポートしていない場合、それは交渉を放棄し、サポートされていない変換についてNOTIFYメッセージをピアに通知する必要があります。
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は、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. 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.
HIPは、任意の寿命を交渉しません。すべてのESPの寿命は、ローカルポリシーです。唯一のHIP実装がサポートしなければならない寿命が（再生保護のための）シーケンス番号のロールオーバーであり、非アクティブESP SAをタイミングをサポートすべきです。 SA回パケットがそのSAを使用して受信されない場合はアウト。デフォルトのタイムアウト値は15分です。実装は、様々なESPトランスフォームのための寿命をサポートするかもしれません。非アクティブ時に各実装でも、静的に設定されたHIP団体が日生きて滞在することができ、無活動タイムアウトのあたり-HITの構成を実装する必要があります。
When HIP is run on a node where a standards compliant IPsec is used, some issues have to be considered.
HIPは、標準に準拠したIPsecが使用されているノード上で実行されている場合、いくつかの問題を考慮しなければなりません。
The HIP implementation must be able to co-exist with other IPsec keying protocols. When the HIP implementation selects the SPI value, it may lead to a collision if not implemented properly. To avoid the possibility for a collision, the HIP implementation MUST ensure that the SPI values used for HIP SAs are not used for IPsec or other SAs, and vice versa.
HIPの実装は、他のIPsecキーイングプロトコルと共存できなければなりません。 HIP実装がSPI値を選択すると、正しく実装されていない場合、それは衝突につながる可能性があります。衝突の可能性を回避するために、HIP実装はHIPのSAのために使用されるSPI値は、IPSecまたは他の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,
アウトバウンドトラフィックのために、SPD又は存在する場合（協調）のSPD 2つ（HIP用とIPsecのためのもの）HIP処理のために意図されたパケットが与えられていることを確認しなければならないHIP対応SAおよびIPSec処理のために意図されたパケットは、IPsec与えられていますSAを-enabled。 SPは、SAと非HIPパケットは、このSAによって処理されることはありませんマッチングにバインドする必要があります。 HIPを使用していないソケットからのデータは、3.2節で説明したように（チェックサムが再計算されていてはなりません
paragraph 2) and data MUST NOT be passed to the SP or SA created by the HIP.
第2項）及びデータは、HIPによって作成された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].
セクション3.2で説明したようにHIPによって交渉されていないSAを使用して、着信データパケットを処理してはいけません、SPI 2段落は、パケット復号化のための正しいSAを識別し、パケットを上位層チェックサムを持っていることを識別するために使用されなければなりません[RFC5201]で指定されるようにそれが計算されます。
In this section, the protocol for setting up an ESP association to be used with HIP association is described.
このセクションでは、HIPの関連で使用する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は、ESP SAのために使用する意思がある変換定義するESP_TRANSFORMパラメータを含んでいます。
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パラメータで選択された1つを含める必要があります。変換に加えて、ホストは、ピア・ホストによって使用される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 UPDATEメッセージは、既存の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.
既存のESP SAが更新された場合は、以下の画像は、典型的な交換を示します。メッセージは、更新機構によって必要とされる配列と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を更新して喜んでホストが作成し、UPDATEメッセージを送信します。メッセージには、次のキーが描画される場所からポイントを与えて、使用された古いSPI値、使用される新しいSPI値、及び鍵素材のインデックス値を含むESP_INFOパラメータが含まれています。新しい鍵素材を生成しなければならない場合は、UPDATEメッセージも[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.
既存のESP SAの更新を要求する更新メッセージを受信したホストは、UPDATEメッセージで応答しなければなりません。古いSPI、新しいSPI、および鍵材料インデックス：応答メッセージでは、ホストは、対応する値を含むESP_INFOパラメータを送信します。入ってくるUPDATEがDIFFIE_HELLMANパラメータが含まれている場合は、応答パケットもDIFFIE_HELLMANパラメータを含まなければなりません。
In this section, new and modified HIP parameters are presented, as well as modified HIP packets.
このセクションでは、新規および改変HIPパラメータが提示、ならびに改変HIPパケットです。
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パラメータは、HIP通信でESPトランスポートフォーマットの関連付けを設定するために、既存のものを再入力するために定義されています。また、NOTIFYパラメータ、[RFC5201]に記載さは、二つの新しいエラーパラメータを有します。
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暗号化と認証トランスフォーム（S）
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値は、ホスト間で送信されなければなりません。それらが生成キーイング材料からキーを描画しているときに加えて、ホストは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 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パラメータのNEW SPIフィールドに設定されています。初期設定では、SPIの古い値は、このようにOLD SPI値フィールドはゼロに設定され、存在しません。追加のSAがマルチホームHIPホスト[RFC5206]の場合には、例えば、HIPホスト間に設定されているときに、古い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で利用可能な任意の抗再生機能を用いている場合、これが生じ得る場合この機能によって使用されるウィンドウ・メカニズムに起因より低い優先度のパケットの不適切な廃棄しました。したがって、送信者は、適切にサービス品質（QoS）をサポートするために、異なるクラスのが、別のSAで同じセレクタ値のトラフィックを置くべきです。これを可能にするために、実装は同じセレクタで指定した送信者と受信者との間で複数のSAの確立と維持を許可する必要があります。 QoSをサポートするために、これらの並列SAの間でトラフィックの配布は、ローカル送信者によって決定され、HIPによって交渉されていません。受信機は、偏見なしに異なるのSAからのパケットを処理しなければなりません。これは、途中でDSCP値が変化している可能性があり、その値は、SAの選択のために採用されておらず、SA /パケットの検証の一部としてチェックしてはならないので、これはIPsec処理に関して問題が発生することはありません。
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 SAの鍵材料が描かれる場所からKEYMAT内の場所に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 use of a key. Rekeying ends the current SAs and starts new ones on both peers.
HIPによって確立されたSAの寿命の間に、ホストの1は1とリキーにシーケンス番号をリセットする必要があります。再入力した理由は、ESPで近づいてシーケンス番号ラップ、またはキーの使用上のローカルポリシーであるかもしれません。鍵の再生成は、現在の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.
タイプ65の長さ12 KEYMAT索引索引は、バイト単位で、どこKEYMATからESPキーを描画するために続行します。パケットが含まれている場合は新しいDiffie-HellmanキーとESP_INFOがUPDATEパケットで送信され、フィールドはゼロでなければなりません。 ESP_INFOがベース交換メッセージに含まれている場合は、KEYMAT指数はESP SAキーが描かれているところから、ポイントのインデックス値を持っている必要があります。このフィールドの長さはKEYMATから引き出すことができる鍵材料の量を制限することに留意されたいです。その量を超えた場合、パケットは、新しいDiffie-Hellman鍵を含まなければなりません。アドレスに送られたデータのためのOLD SPI古いSPI（ES）は、このSAに関連付けられています。これは初期SAの設定がある場合は、OLD SPI値はゼロです。
NEW SPI new SPI for data sent to address(es) associated with this SA.
このSAに関連付けられたアドレスに送られたデータのためのNEW SPI新しいSPI（ES）。
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長さタイプ、長さを除いたオクテットの長さ、およびパディングがゼロを予約済み、受信スイートのIDを使用するESPスイートを定義するときに無視
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
HMAC-SHA1、HMAC-MD5 6にHMAC-SHA1 5 NULLとHMAC-SHA1 4 NULLとHMAC-MD5 3 BLOWFISH-CBCとHMAC-SHA1 2つの3DES-CBCと1つの3DES-CBCと0 AES-CBC予約
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がパラメータが変換されていないことを確認する必要があります。逆に、受信者は半年以上スイートのIDが含まれている受信したトランスポートパラメータを処理するために準備しなければなりません。スイートIDの数は限られてESP_TRANSFORMパラメータの最大サイズを設定します。デフォルトの設定として、ESP_TRANSFORMパラメータは必須スイートIDの少なくとも一つを含まなければなりません。管理者は、このデフォルトを上書きすることを可能にする設定オプションがあるかもしれません。
Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL with HMAC-SHA1.
必須の実装：AES-CBC HMAC-SHA1と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.
いくつかの条件下では、BEETモードの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.
HIP基本仕様は、NOTIFYエラータイプのセットを定義します。次のエラーの種類は、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のいずれも許容ませんでした。
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-CBC [RFC3602] with HMAC-SHA-1-96 [RFC2404].
ESP_TRANSFORMは、優先順に、送信側でサポートされているESPモードが含まれています。すべての実装は、AES-CBC HMAC-SHA-1-96 [RFC2404]と[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_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キーが描画される場所からKEYMATインデックスが含まれています。古い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モードが含まれています。すべての実装は、AES-CBC HMAC-SHA-1-96 [RFC2404]と[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_TRANSFORM, ESP_TRANSFORM, ENCRYPTED { HOST_ID }, [ ECHO_RESPONSE ,] HMAC, HIP_SIGNATURE [, ECHO_RESPONSE] ) )
IP（HIP（ESP_INFO、[R1_COUNTER、】溶液DIFFIE_HELLMAN、HIP_TRANSFORM、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は、この関連付けのためのR2の送信者のSPI値を有するESP_INFOパラメータを含んでいます。 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).
概念的には、プロセスは、I「及びR」は、セクション3.3.2で定義されたホスト名を使用して、次のメッセージシーケンスによって表すことができます。簡単にするために、HMACとHIP_SIGNATUREが描かれ、DIFFIE_HELLMANキーはオプションではありません。 ACK_IとUPDATEはSEQ_RとUPDATEで便乗する必要はありません。これは、（この場合、シーケンスは、4つのパケットを含むであろう）を別々ACKされてもよいです。
I' R'
I '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.
HIPは、ESPで使用される場合、UPDATEパケットは再入力を開始するために使用されます。 UPDATEパケットは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を使用する中間システムを再入力情報を運ぶもののための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、配列、[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を運ばなければなりませんし、DIFFIE_HELLMANパラメータを運ぶことができます。
Intermediate systems that use the SPI will have to inspect HIP packets for packets carrying rekeying information. The packet is signed for the benefit of the intermediate systems. Since intermediate systems may need the new SPI values, the contents cannot be encrypted.
SPIを使用する中間システムを再入力情報を搬送するパケットのためのHIPパケットを検査する必要があります。パケットは中間システムの利益のために署名されます。中間システムは、新しいSPI値が必要になる場合がありますので、内容を暗号化することはできません。
The following figure shows the contents of a rekeying acknowledgment UPDATE packet.
次の図は、再入力確認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 [RFC5201]. In this section, we describe the actions related to ESP security associations.
ICMPメッセージの処理は、主にHIP基本仕様[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.
パケット処理は、主にHIP基本仕様[RFC5201]で定義されています。このセクションでは、ESPのトランスポートフォーマットが使用されている変更やパケット処理のための新たな要件について説明します。すべてのHIPパケット（現在のプロトコル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のトランスポートフォーマットが使用され、所与の<ソース、宛先> HITペアのアクティブHIPセッションが存在している場合、発信データグラムは、ESPセキュリティアソシエーションを使用して保護されています。典型的な実装では、これはBEETモードESPパケットが送信されることになります。 BEETモード[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パケットがESP処理によって残されヒットを置換することにより、例えば、使用されるIPアドレスファミリに応じ適切なIPヘッダフォーマット、およびそのIPヘッダ内の適切な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.
ESPは、パケットを保護するよう着信HIPのユーザデータパケットが到着します。通常の場合、受信ホストは、パケット内のSPIと宛先IPアドレスによって識別され、対応するESPセキュリティアソシエーションを有しています。ホストがクラッシュしたか、そうでなければその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パケットを送信することができます。失われた状態を処理する方法の実装上の問題です。
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アドレス対HIT変換ステップは、また、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.データグラムを上位層に配信されます。右の上層ソケットにデータグラムを逆多重化することはヒットが分離時に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].
この文書で説明した新しいHIPパラメータ、ESP_INFOとESP_TRANSFORMは、HMACと署名の計算を使用して保護されなければなりません。 [RFC5201]に記載されているように典型的な実装では、それらは、R1、I2、R2、及びUPDATEパケット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メッセージで初期化されます。受信ホスト（イニシエータ）はESPの提示値から変換を選択します。もし適切な値が見つからない場合は、ネゴシエーションが終了されます。返信パケットを送信するときに生成した暗号鍵を使用して、いつ選択された値は、その後使用されています。提案された代替システムに受け入れられない場合は、ESP SA確立ネゴシエーションを放棄することができる、またはそれは再試行範囲内I1メッセージを再送信することができます。
After selecting the ESP transform and performing other R1 processing, the system prepares and creates an incoming ESP security association. It may also prepare a security association for outgoing traffic, but since it does not have the correct SPI value yet, it cannot activate it.
変換ESPを選択し、他のR1の処理を行った後、システムは、着信ESPセキュリティアソシエーションを作成し、作成します。また、発信トラフィックのためのセキュリティアソシエーションを作成することができるが、それはまだ正しいSPI値を持っていないので、それをアクティブにすることはできません。
The following steps are required to process the incoming ESP SA initialization replies in I2. The steps below assume that the I2 has been accepted for processing (e.g., has not been dropped due to HIT comparisons as described in [RFC5201]).
次のステップは、I2で、着信ESP SAの初期化応答を処理するために必要とされています。以下の手順は、（例えば、[RFC5201]に記載されているように比較をヒットすることにより削除されていない）I2は、処理のために受理されたと仮定する。
o The ESP_TRANSFORM parameter is verified and it MUST contain a single value in the parameter, and it MUST match one of the values offered in the initialization packet.
O ESP_TRANSFORMパラメータが検証され、それはパラメータに単一の値を含まなければなりません、そして、それが初期化パケットで提供される値のいずれかと一致しなければなりません。
o The ESP_INFO NEW SPI field is parsed to obtain the SPI that will be used for the Security Association outbound from the Responder and inbound to the Initiator. For this initial ESP SA establishment, the old SPI value MUST be zero. The KEYMAT Index field MUST contain the index value to the KEYMAT from where the ESP SA keys are drawn.
O ESP_INFO NEW SPIフィールドがイニシエータにセキュリティアソシエーションレスポンダからのアウトバウンドとインバウンドのために使用されるSPIを取得するために解析されます。この最初のESP SAの確立のために、古いSPI値はゼロでなければなりません。 ESP SAキーが描かれているところからKEYMAT Indexフィールドは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を取得するために解析されます。システムは、ピアにパケットを送信するために使用され、発信ESPセキュリティアソシエーションを作成したり、アクティブにするために、このSPIを使用しています。
When the system drops a HIP association, as described in the HIP base specification, the associated ESP SAs MUST also be dropped.
システムは、HIPアソシエーションを低下すると、HIP基本仕様に記載されているように、関連するESP SAはまた、削除する必要があります。
During ESP SA rekeying, the hosts draw new keys from the existing keying material, or new keying material is generated from where the new keys are drawn.
ESP SAの再入力時には、ホストは新しいキーが描かれているところから生成されている既存のキーイングマテリアル、または新しい鍵素材から新しい鍵を描きます。
A system may initiate the SA rekeying procedure at any time. It MUST initiate a rekey if its incoming ESP sequence counter is about to overflow. The system MUST NOT replace its keying material until the rekeying packet exchange successfully completes.
システムは、いつでもSAのキー更新手順を開始することができます。その入ってくるESPシーケンスカウンタがオーバーフローしそうであるならば、それはキー再生成を開始しなければなりません。キーの再発行パケット交換が正常に完了するまで、システムはその鍵材料を置き換えてはなりません。
Optionally, a system may include a new Diffie-Hellman key for use in new KEYMAT generation. New KEYMAT generation occurs prior to drawing the new keys.
必要に応じて、システムは、新しいKEYMAT生成に使用するための新しいDiffie-Hellmanキーを含んでもよいです。新KEYMATの世代が新しいキーを描画する前に発生します。
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の作成を含む）セキュリティアソシエーションペアのその半分を更新する必要があるため、リキー処理は、各辺が更新を送信および受信の両方ことを必要とします。次に、システムは、それがピアにパラメータを送信したと関連UPDATEメッセージのACKおよび対応するピアのパラメータの両方を受信したときにESP SAをリキーします。これはACK、必要なHIPパラメータが異なるUPDATEメッセージに到着することであってもよいです。システムは、ESP SAの更新を開始するが、ピアからの更新要求に応答し、2つのシステムがほぼ同時に更新を開始した場合にも発生する可能性がない場合、これは常に真です。システムは、未処理の更新要求を有する場合、このような場合に、それは一つのパラメータを保存し、キー更新を完了する前に他のを待ちます。
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を削除するが、その政策はまだ許可されている場合、それらを引き続き使用してはなりません。再入力手順は、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.対応HIPアソシエーションが存在しなければなりません。これは通常、基礎となるUPDATEメカニズムによって保証されます。
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.受信UPDATEがDIFFIE_HELLMANパラメータが含まれている場合は、受信KEYMAT指数はゼロでなければならないとグループIDは、アソシエーション上で使用中のグループIDと一致する必要があります。このテストが失敗した場合、パケットはドロップする必要があり、システムはエラー・メッセージをログに記録すべきです。
2. If there is no outstanding rekeying request, the packet processing continues as specified in Section 6.9.1.
2.未解決の再入力要求がない場合は、セクション6.9.1で指定されるように、パケット処理が継続されます。
3. If there is an outstanding rekeying request, the UPDATE MUST be acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN) parameters must be saved, and the packet processing continues as specified in Section 6.10.
3.未処理リキー要求があった場合、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パラメータを使用して受信された更新パケットを処理するための概念的な処理ルールを定義します。
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索引以上現在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 ACKを送信することができるが、このアップデートでは、一般的に、ACKパラメーターを指定して、ピアのUPDATEを認めるだろう。
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.
前記システムは、任意のESP_INFOとDIFFIE_HELLMANパラメータを受信したアップデートパケットとストアを送信します。この時点で、それが唯一のESP SAの更新を完了するために、新たに送信されるUPDATEに対する肯定応答を受信する必要があります。通常の場合、肯定応答は、基礎となる更新メカニズムによって処理されます。
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:
それは、両方のピアから対応する更新確認応答パケットを受信し、それがピアのUPDATEを正常に受信した場合、システムは、キー更新を確定します。以下のステップがとられます：
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.
受信したUPDATEメッセージは、新しいDiffie-Hellmanキーが含まれている場合1.システムが原因ESP SAの更新を開始する新しいDiffie-Hellman鍵を持っている、またはその両方、システムが新しいKEYMATを生成します。一つだけ新しいDiffie-Hellmanキーがある場合は、古い既存のキーは他のキーとして使用されます。
2. If the system generated a new KEYMAT in the previous step, it sets the KEYMAT Index to zero, independent of whether the received UPDATE included a Diffie-Hellman key or not. If the system did not generate a new KEYMAT, it uses the greater KEYMAT Index of the two (sent and received) ESP_INFO parameters.
2.システムが前のステップで新しいKEYMATを生成した場合、受信した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.
3.システムがKEYMATインデックスから始まる、新しい着信と発信ESP SAの鍵を描画し、新しい着信と発信ESP SAを準備します。送信SAのSPIはESP_INFOパラメータで受信した新しいSPI値です。 ESP_INFOがピアに送信されたときに、着信SAのSPIを生成しました。リキー処理中KEYMATから検索キーの順番は、セクション7で説明したものと同様です。
Note, that only IPsec ESP keys are retrieved during the rekeying
process, not the HIP keys.
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. 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.
この文書では、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 [RFC4306]. This document specifies how the Host Identity Protocol is used to establish ESP Security Associations.
2つのノード間でESPセキュリティアソシエーションを確立するために、さまざまな方法があります。これは、IKE [RFC4306]を使用して、例えば、行うことができます。この文書では、ホストアイデンティティプロトコルはESPセキュリティアソシエーションを確立するために使用される方法を指定します。
The following issues are new or have changed from the standard ESP usage:
次の問題は、新しいされているか、または標準ESPの使用状況から変更されました：
o Initial keying material generation
O初期鍵材料世代
o Updating the keying material
鍵素材を更新するO
The initial keying material is generated using the Host Identity Protocol [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.
初期鍵材料は、ディフィー - ヘルマン・プロシージャを使用してホストアイデンティティプロトコル[RFC5201]を使用して生成されます。この文書では、既存のESP SAを変更するために、基本仕様で定義され、UPDATEパケットの使用を拡張します。ホストは、すなわち、リキーのDiffie-Hellman手順を使用して、新しいキーイングマテリアルの生成を強制することができます。ホスト間ESP SAの初期設定は、基本交換の間に行われ、メッセージ交換は、塩基交換によって提供される方法を使用して保護されています。接続パラメータの変更は、UPDATEメッセージの交換が完了した後に、古いESP SAが削除され、新しいものが生成されることを基本的に意味しています。メッセージ交換は、HIP関連キーを使用して保護されています。 HMACとパケットの署名の両方が使用されています。
This document defines additional parameters and NOTIFY error types for the Host Identity Protocol [RFC5201].
この文書では、追加のパラメータを定義し、ホスト識別プロトコル[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]で指定された通知メッセージタイプのネームスペースに追加されました。
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年の初めにベース「ホストアイデンティティプロトコル」仕様から分離し、人々の数は、コメントと修正案を提供することで、テキストに貢献してきました。人のリストはトム・ヘンダーソン、ジェフAhrenholz、ジャンメレン、ユッカYlitalo、およびMiikaこむが含まれます。著者らはまた、暗号アルゴリズムの使用状況に彼の目を持つ文書をレビューするチャーリー・カウフマンに感謝したいと思います。
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.
これによって文書の歴史に、アイデアのほとんどはベース「ホストアイデンティティプロトコル」仕様から継承されます。このように、その仕様の謝辞セクションの人々のリストには、このドキュメントに対して有効です。多くの人々が貴重なフィードバックを与えている、と誰もが名前に私たちの謝罪がありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.グレン、 "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]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]モスコウィッツ、R.、Nikander、P.、Jokela、P.、エド。、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、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.メレン、 "ESPのバウンドエンドツーエンドトンネル（BEET）モード"、進歩、2007年11月に作業。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]グロスマン、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]林、Z.およびD. Pendarakis、 - 、RFC「一般化マルチプロトコル・ラベルのためのIANAの割り当てのドキュメント（GMPLS）リソース予約プロトコルスイッチングトラフィックエンジニアリング（RSVP-TE）使用と拡張機能を自動的に交換光ネットワーク（ASON）のために」 3474、2003年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]ヘンダーソン、T.、エド。、「エンドホストモビリティとマルチホーミングをホストアイデンティティプロトコルで」、RFC 5206、2008年4月。
Appendix A. A Note on Implementation Options
インプリメンテーションオプションの付録A. A注
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ヘッダを書き換えることです。それはヒットの代わりに、送信元および宛先アドレスフィールド内のIPアドレスを含むIPv6ヘッダと、IPv6の転送モードパケットを処理したかのようにそのような実装では、IPsecが使用されます。発信パケットでは、IPsec処理の後、ヒットはヒットとSPIに基づいて、実際のIPアドレスに置き換えられます。着信パケットには、IPsec処理の前に、IPアドレスは、着信パケット内のSPIに基づいて、ヒットに置き換えられます。このような実装では、すべてのIPsecポリシーがヒットに基づいており、上位層は、IPアドレスの代わりにヒットを持つパケットを参照してください。その結果、HIPのサポートがあれば、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トンネルとトランスポートモードの両方からのいくつかの機能を提供します。 IPアドレスがトンネルモードで使用されるようなHIPは、「外側」アドレスと「内側」アドレスとIPアドレスとしてヒットを使用します。代わりに、ホスト間のトンネルパケットの内側と外側のアドレスの間の変換は、エンドホストで行われ、内部アドレスが初期HIPネゴシエーション後にワイヤ上で送信されることはありません。 BEETは、限られたトンネルモードセマンティクス（ - HITS - 及び可変外側IPアドレス固定論理内アドレス）とのIPsecトランスポート・モード・シンタックス（NO内部ヘッダ）を提供します。
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-方法はSADで、一箇所ですべての構成情報を保持します。アドレス書き換えが別々に実装されている場合一方、実装は、SADの情報とDBを書き換え、別のアドレスが同期して保持されていることを確認する必要があります。結果として、この仕様を実装するBEETモードベースの方法は、別の実装上推奨されます。
Authors' Addresses
著者のアドレス
Petri Jokela Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
ペトリJokelaエリクソン研究NomadicLab JORVAS FIN-02420フィンランド
Phone: +358 9 299 1 EMail: petri.jokela@nomadiclab.com
電話：+358 9 299 1 Eメール：petri.jokela@nomadiclab.com
Robert Moskowitz ICSAlabs, An Independent Division of Verizon Business Systems 1000 Bent Creek Blvd, Suite 200 Mechanicsburg, PA USA
ロバート・モスコウィッツICSAlabs、1000年ベントクリークブルバード、スイート200メカニクス、PA USAベライゾンビジネスシステムの独立した部門
EMail: rgm@icsalabs.com
メールアドレス：rgm@icsalabs.com
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
ペッカNikanderエリクソン研究NomadicLab JORVAS FIN-02420フィンランド
Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com
電話：+358 9 299 1 Eメール：pekka.nikander@nomadiclab.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。