RFC5202 日本語訳
5202 Using the Encapsulating Security Payload (ESP) Transport Formatwith the Host Identity Protocol (HIP). P. Jokela, R. Moskowitz, P.Nikander. April 2008. (Format: TXT=68195 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Jokela
Request for Comments: 5202 Ericsson Research NomadicLab
Category: Experimental R. Moskowitz
ICSAlabs
P. Nikander
Ericsson Research NomadicLab
April 2008
Jokelaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 5202年のエリクソン研究NomadicLabカテゴリ: 実験的なR.のP.Nikanderエリクソン研究NomadicLabマスコウィッツICSAlabs2008年4月
Using the Encapsulating Security Payload (ESP) Transport Format with the
Host Identity Protocol (HIP)
ホストアイデンティティプロトコルがある要約のセキュリティ有効搭載量(超能力)輸送形式を使用します。(クール)です。
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.
IKEなどのHIPとセキュリティ関連のプロトコルの複雑なSecurity Policy Databases(SPDs)と共同存在の場合には、作成者はこれらのドキュメントで不特定の状態に遭遇するかもしれません。 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).
このメモは、Host Identityプロトコル(HIP)と共に使用されるためにEncapsulated Security有効搭載量(超能力)に基づいているメカニズムをユーザデータ・パケットのトランスミッションに指定します。
Jokela, et al. Experimental [Page 1] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[1ページ]RFC5202
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 コンベンションは本書では.3 3を使用しました。 ヒップ. . . . . . . . . . . . . . . . . . . . . . 4 3.1がある超能力を使用します。 超能力パケット・フォーマット. . . . . . . . . . . . . . . . . . . . 4 3.2。 概念的な超能力パケット処理. . . . . . . . . . . . . 4 3.2.1。 セキュリティパラメタインデックス(SPI). . . 5 3.3の意味論 セキュリティ協会設立と維持. . . . 6 3.3.1。 超能力セキュリティ協会. . . . . . . . . . . . . . 6 3.3.2。 Rekeying. . . . . . . . . . . . . . . . . . . . . . . 6 3.3.3。 セキュリティ協会管理. . . . . . . . . . . 7 3.3.4。 セキュリティパラメタインデックス(SPI). . . . . . . . . . . . 7 3.3.5。 変換. . . . . . . . . . . . . . . . . 7 3.3.6を支持しました。 一連番号. . . . . . . . . . . . . . . . . . . 8 3.3.7。 生涯、タイマ. . . . . . . . . . . . . . . . . 8 3.4。 IPsecとクールな超能力実現問題. . . . . 8 4。 プロトコル. . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1。 ヒップ. . . . . . . . . . . . . . . . . . . . . . . . 9 4.1の.1における超能力。 セキュリティ協会. . . . . . . . 9 4.1.2を超能力に設定します。 既存の超能力SA. . . . . . . . . . . . . 10 5をアップデートします。 パラメタとパケット・フォーマット. . . . . . . . . . . . . . . . . 10 5.1。 新しいパラメタ. . . . . . . . . . . . . . . . . . . . . . 11 5.1.1。 超能力_インフォメーション. . . . . . . . . . . . . . . . . . . . . . . 11 5.1.2。 超能力_変換. . . . . . . . . . . . . . . . . . . . 13 5.1.3。 パラメタ. . . . . . . . . . . . . . . . . . . 14 5.2に通知してください。 クールな超能力セキュリティ協会セットアップ. . . . . . . . . . . . 14 5.2.1。 塩基置換. . . . . . . . . . . . . . 14 5.3の間、セットアップしてください。 クールな超能力Rekeying. . . . . . . . . . . . . . . . . . . . . 16 5.3.1。 Rekeying. . . . . . . . . . . . . . . . 16 5.3.2を初期化します。 Rekeying初期設定. . . . . . 17 5.4に応じます。 ICMPメッセージ. . . . . . . . . . . . . . . . . . . . . . 17 5.4.1。 未知のSPI. . . . . . . . . . . . . . . . . . . . . 17 6。 パケット処理. . . . . . . . . . . . . . . . . . . . . . 18 6.1。 送信するアプリケーションデータ. . . . . . . . . . . 18 6.2を処理します。 入って来るアプリケーションデータ. . . . . . . . . . . 19 6.3を処理します。 HMAC、署名計算、および検証. . . . . 19 6.4。 入って来る超能力SA初期設定(R1). . . . . . 19 6.5を処理します。 入って来る初期設定回答(I2). . . . . . 20 6.6を処理します。 処理の入って来る超能力SAは決定(R2). . . . 20 6.7をセットアップします。 クールな協会. . . . . . . . . . . . . . . . 20 6.8を落とします。 超能力SA Rekeying. . . . . . . . . . . . . . . . 20 6.9を開始します。 入って来るアップデートパケット. . . . . . . . . . . . 22 6.9.1を処理します。 処理アップデートパケット: どんな傑出しているRekeyingも.22 6.10を要求しません。 Rekeying. . . . . . . . . . . . . . . . . . . 23 6.11を成立させます。 処理して、パケット. . . . . . . . . . . . . . . . 24 7に通知してください。 材料. . . . . . . . . . . . . . . . . . . . . . . 24を合わせます。
Jokela, et al. Experimental [Page 2] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[2ページ]RFC5202
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
8. セキュリティ問題. . . . . . . . . . . . . . . . . . . 25 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 25 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 26 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 26 11.2。 Implementation Options. . . . . . . . . . 28の上の有益な参照. . . . . . . . . . . . . . . . . . 26Appendix A.A Note
1. Introduction
1. 序論
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.
Host IdentityプロトコルArchitecture[RFC4423]では、ホストは公開鍵と同一視されています。 Host Identityプロトコル[RFC5201]塩基置換で、どんな2人のHIPを支持しているホストも、互いを認証して、自分たちの間のHIP協会を創設します。 塩基置換の間、ホストは、認証されたディフィー-ヘルマンの交換を使用することで1つの共有された合わせることの材料を発生させます。
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]は実際のコミュニケーションの間、使用されるために利用者データのための少しの輸送形式や方法も説明しません。 それはそれを定義するだけです。Encapsulated Security有効搭載量(超能力)[RFC4303]のベースの輸送形式と方法を実行するのは義務的です。 このドキュメントは超能力が実施している者データを運ぶのに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プロトコル拡張子と彼らの取り扱いの1セットを指定します。 これらの拡張子を使用して、1組の超能力Security Associations(SAs)は塩基置換の間、ホストの間で作成されます。 結果として起こる超能力Security Associationsは材料(KEYMAT)が塩基置換の間に発生させた合わせるのから得られたキーを使用します。 HIP協会と必要な超能力SAsがホストの間に設立された後に、ユーザデータ通信は、超能力を使用することで保護されます。 さらに、このドキュメントは既存の超能力Security Associationをアップデートする方法を指定します。
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.
Host Identityの表現がユーザデータ・パケットのヘッダーで明らかに運ばれないことに注意されるべきです。 代わりに、超能力Security Parameter Index(SPI)は、正しいホスト文脈を示すのに使用されます。 SPIsはHIP ESPセットアップ交換の間、選択されます。 ユーザデータ・パケットに関しては、超能力SPIs(IPアドレスへの可能な組み合わせにおける)はホスト文脈を特定するのに間接的に使用されます、その結果、どんな追加明白なプロトコルヘッダーも避けます。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Jokela, et al. Experimental [Page 3] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[3ページ]RFC5202
3. Using ESP with HIP
3. ヒップがある超能力を使用します。
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が交換を基礎づけた後にユーザデータ通信量を保護する使用を指定します。 超能力のこの使用がホストからホストへの交通だけに意図することに注意してください。 セキュリティゲートウェイは支えられません。
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.
超能力使用を支持するために、HIPベース交換メッセージは輸送されたパラメタへのいくつかの小さい方の追加を必要とします。 R1パケットでは、Responderは、それをInitiatorに送る前に可能な超能力が新しい超能力_TRANSFORMパラメタで変形すると言い足します。 Initiatorは提案された変換を得て、それらの提案された変換の1つを選択して、超能力_TRANSFORMパラメタのI2パケットにそれを加えます。 また、このI2パケットでは、Initiatorは超能力交通にそれが使用されたがっているSPI値をResponderからInitiatorまで流れさせます。 この情報は、新しい超能力_INFOパラメタを使用することで運ばれます。 ESP SAセットアップを成立させるとき、ResponderはR2パケットのInitiatorにSPI値を送ります、再び超能力_INFOを使用して。
3.1. ESP Packet Format
3.1. 超能力パケット・フォーマット
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.
超能力仕様[RFC4303]はIPsecのために超能力パケット・フォーマットを定義します。 HIP ESPパケットはまさにIPsec超能力輸送形式パケットと同じに見えます。 意味論は、しかしながら、少し異なって、さらに詳細に次の小区分で説明されます。
3.2. Conceptual ESP Packet Processing
3.2. 概念的な超能力パケット処理
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.
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
SPDとSecurity Association Database(SAD)のIPアドレスを使用する規格対応することのIPsec実現が使用されているとき、パケット処理は以下の方法を採るかもしれません。 出発しているパケットに関しては、pseudoheaderにはある上側の層がHost Identity Tags(HITs)を使用しながらIPアドレス、実現recalculates上側の層のチェックサムを使用することで造られて、その後にパケットソースと目的地を変えると仮定するのが対応するIPアドレスに送って戻ります。 パケットによるIPsecに送って、交通機関取り扱いとそこからのコード化されたパケットのための超能力をネットワークに送るということです。 そして超能力パケットが受け取られているとき、パケットはIPsec超能力交通機関取り扱いと、復号化の後に最初に置かれます、ソース。
Jokela, et al. Experimental [Page 4] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[4ページ]RFC5202
destination IP addresses are replaced with HITs and finally, upper- layer checksums are verified before passing the packet to the upper layer.
送付先IPアドレスをHITsに取り替えます、そして、最終的に、上側の層にパケットを通過する前に、上側の層のチェックサムについて確かめます。
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.
パケット処理を実行する代替の方法はBEET(Endから終わりへの制限されたTunnel)[超能力-BEET]モードです。 BEETモードで、超能力パケットは交通機関パケットとしてフォーマットされますが、接続の意味論はトンネルモードのように同じです。 パケットの「外側」のアドレスはIPアドレスです、そして、「内側」のアドレスはHITsです。 パケットがコード化された後に外向的な交通において、パケットのIPヘッダーはHITsの代わりにIPアドレスを含む新しいものに変わります、そして、パケットをネットワークに送ります。 SPIは、超能力パケットが受け取られているときには保全保護と共に、パケットが正しいHIT組にしっかりと関連づけさせられるように評価します。 パケットのヘッダーをHITsを含んでいる新しいヘッダーに取り替えます、そして、パケットを解読します。
3.2.1. Semantics of the Security Parameter Index (SPI)
3.2.1. セキュリティパラメタインデックスの意味論(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.
SPIsは、容認されたパケットのために右のSecurity Associationを見つけるのに超能力に使用されます。 HIPと共に使用されると、超能力SPIsは意味を加えました。 それらは1組のHITsの圧縮された表現です。 したがって、SPIsは仲介者システムによってアドレス・マッピングのようなサービスを提供する際に使用されるかもしれません。 SPIが受信機に意味を持っているので<DST(DSTが送付先IPアドレスである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を選択します。 これで、それは異なった同輩のために異なったSPIsを選択できます。 SPI選択SHOULD、無作為であってください。 超能力仕様[RFC4303]のセクション2.1の規則に従わなければなりません。 異なったSPI SHOULD、それぞれのHIP交換には、特定のホストと共に使用されてください。 これは、反射攻撃を避けるためのものです。 aは「再-キー」、SPI MUSTを接待します。さらに、いつ、変えるか。 その上、ホストが異なった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つの方法は、SPIとして32ビットの無作為の、または、連続した数でHITを連結して、これ(SHA1を使用する)を論じ尽くして、次に、高位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はベースHIP交換の3番目の(I2)と4(R2)番目のパケットの同輩に伝えられます。 SPIにおける変化は超能力_INFOパラメタで合図されます。
Jokela, et al. Experimental [Page 5] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[5ページ]RFC5202
3.3. Security Association Establishment and Maintenance
3.3. セキュリティ協会設立と維持
3.3.1. ESP Security Associations
3.3.1. 超能力セキュリティ協会
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では、超能力Security Associationsは塩基置換[RFC5201]の間のHIPノードの間のセットアップです。 後でUPDATEメッセージを使用することで既存の超能力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.
HIP協会を設立すると、各協会は2超能力SAs、入って来るパケットのためのもの、および出発しているパケットのための1つにリンクされます。 Initiatorの入って来るSAはResponderの外向的な1つに対応しています、そして、逆もまた同様です。 Initiatorは入って来る協会のためにセクション3.2.1で定義されるようにSPIを定義します。 このSAはここにSA-ロードアイランドと呼ばれます、そして、対応するSPIはSPI-ロードアイランドと呼ばれます。 それぞれ、Responderの入って来るSAはInitiatorの出発している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を出す前に、InitiatorはR1処理の一部としてSA-ロードアイランドを作成します。 セクション7で定義されるようにKEYMATからキーを得ます。 ResponderはI2処理の一部としてSA-ロードアイランドを作成します。 セクション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を出す前に、ResponderはI2処理の一部としてSA-IRを作成します。 セクション6.5を見てください。 R2を処理するとき、Initiatorは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].
発生している合わせることの材料から初期のセッションキーを得ます、KEYMAT、HIPキーが[RFC5201]で指定されるように描かれた後に。
When the HIP association is removed, the related ESP SAs MUST also be removed.
また、HIP協会を取り除くとき、関連する超能力SAsを取り外さなければなりません。
3.3.2. Rekeying
3.3.2. Rekeyingします。
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'.
両方のホストはESTABLISHED状態の初期のHIPが交換とSA設立を基礎づける後です。 InitiatorとResponderの役割がもうありません、そして、協会は左右対称です。 'この小区分では、rekey手順に着手するパーティーは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を「再-合わせ」ることを指定します。 上で紹介された超能力_INFOパラメタはこのために使用されます。
Jokela, et al. Experimental [Page 6] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[6ページ]RFC5202
I' initiates the ESP SA updating process when needed (see Section 6.8). It creates an UPDATE packet with required information and sends it to the peer node. The old SAs are still in use, local policy permitting.
'私'は必要であると過程をアップデートするESP SAを開始します(セクション6.8を見てください)。 それは、必須情報でUPDATEパケットを作成して、同輩ノードにそれを送ります。 古い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.
UPDATE(セクション6.9を見る)を受けて、処理した後に、'R'は新しいSAsを発生させます: 'SA-I'R'とSA-R'I'。 それが新しい出発しているSAを使用に連れていきませんが、まだ古い方を使用しているので、同じ同輩ホストに向かった2SA組は一時存在しています。 '新しい出発しているSA、SPI-R'IのためのSPI'はUPDATEパケットの受信された超能力_INFOパラメタで指定されます。 '新しい入って来るSAに関して、Rは、'新しいSPI値、SPI-I'Rを発生し'て、応答UPDATEパケットにそれを含んでいます。
When I' receives a response UPDATE from R', it generates new SAs, as described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the new outgoing SA immediately.
応答UPDATEは、R'から'私であるときに'と受けて、セクション6.9で説明されるように新しいSAsを発生させます: 'SA-I'R'とSA-R'I'。 それはすぐに、新しい出発している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.
新しい入って来るSAにおける交通を受けるか、または「再-合わせ」ることの完成を確認しながらUPDATE ACKを受けるとき、'R'は新しい出発しているSAを使用し始めます。 'この後、R'は古いSAsを取り外すことができます。 'I'が新しい入って来るSAからの交通を受けるとき、同様に、それは安全に古いSAsを取り外すことができます。
3.3.3. Security Association Management
3.3.3. セキュリティ協会管理
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組は2SPIsと2HITsによって索引をつけられます(地方のものとシステム以来の同様にリモートなHITsは1HITを持つことができます)。 不活発タイマはすべてのSAsのためのRECOMMENDEDです。 州がSAの削除を書き取るなら、タイマがあらゆる遅い到着のためにパケットを許容するように設定されます。
3.3.4. Security Parameter Index (SPI)
3.3.4. セキュリティパラメタインデックス(SPI)
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.
超能力におけるSPIsはHIP交換の後にすべてのパケットからHIPデータの簡単な要約を提供します。 これはIKEのような他のKey Managementプロトコルに関してHIT-組Security Association(そして、SPI)あたりのa、および方針粒状の減少を必要とします。
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を手に入れます。
3.3.5. Supported Transforms
3.3.5. 支持された変換
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-SHA1-96[RFC2404]を支持しなければなりません。 InitiatorがResponderによって提供された変換のいずれも支持しないなら、それは、非サポートされた変換に関するNOTIFYメッセージで交渉を捨てて、同輩に知らせるべきです。
Jokela, et al. Experimental [Page 7] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[7ページ]RFC5202
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認証と共にそれを使用しなければなりません。
3.3.6. Sequence Number
3.3.6. 一連番号
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.
超能力がHIPと共に使用されるとき、Sequence Number分野はMANDATORYです。 HIPと共に設立されたESP SAで反反復操作による保護を使用しなければなりません。 超能力がHIPと共に使用されるとき、64ビットの一連番号を使用しなければなりません。 これは、各ホストは一連番号範囲2^64の前のrekeyがそうしなければならないことを意味します。
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ビットは、超能力ヘッダーに含まれていませんが、単に両方の同輩にとって地方に保たれます。 [RFC4301]を見てください。
3.3.7. Lifetimes and Timers
3.3.7. 生涯、タイマ
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はどんな生涯も交渉しません。 すべての超能力寿命がローカルの方針です。 HIP実現が支持しなければならない唯一の寿命が、一連番号ロールオーバー(反復操作による保護のための)と、SHOULDサポートタイミングの出ている不活発な超能力SAsです。 SA回のアウトはパケットでないならそのSAを使用するのにおいて受け取られています。 デフォルトタイムアウト価値は15分です。 実現は様々な超能力変換のために生涯を支持するかもしれません。各実現SHOULDは不活発タイムアウトの1HITあたりの構成を実行します、静的に何日も生きているままである協会を構成されたHIPに許容して、不活発であるときにさえ。
3.4. IPsec and HIP ESP Implementation Considerations
3.4. IPsecとクールな超能力実現問題
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 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,
アウトバウンドトラフィック、SPDまたは(連携する)のSPDsに関しては、2があれば、(HIPのためのものとIPsecのためのもの)は、HIP処理のために意図するパケットにHIPによって可能にされたSAを与えて、IPsec処理のために意図するパケットにIPsecによって可能にされたSAを与えるのを確実にしなければなりません。 次に、合っているSAにSPを縛らなければなりません、そして、非HIPパケットはこのSAによって処理されないでしょう。 HIP MUST NOTを使用していないソケットから発するデータでチェックサムについて再計算する、(セクション3.2で説明されるように
Jokela, et al. Experimental [Page 8] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[8ページ]RFC5202
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].
HIP MUST NOTによって交渉されないSAを使用する受信データパケットがセクション3.2で説明されるように処理されて、2について短い記事を書いてください。 SPIをパケット復号化のために正しいSAを特定して、パケットには[RFC5201]で指定されるように計算される上側の層のチェックサムがあるのを特定するのに使用しなければなりません。
4. The Protocol
4. プロトコル
In this section, the protocol for setting up an ESP association to be used with HIP association is described.
このセクションで、HIP関係と共に使用されるべき超能力協会を設立するためのプロトコルは説明されます。
4.1. ESP in HIP
4.1. ヒップの超能力
4.1.1. Setting Up an ESP Security Association
4.1.1. 超能力セキュリティ協会を設立します。
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を使用することでホストの間の超能力Security Associationをセットアップするのはホストの間で通過された3つのメッセージから成ります。 パラメタは塩基置換の間、R1、I2、およびR2メッセージに含まれています。
Initiator Responder
創始者応答者
I1
---------------------------------->
I1---------------------------------->。
R1: ESP_TRANSFORM
<----------------------------------
R1: 超能力_は<を変えます。----------------------------------
I2: ESP_TRANSFORM, ESP_INFO
---------------------------------->
I2: 超能力_変換、超能力_インフォメーション---------------------------------->。
R2: ESP_INFO
<----------------------------------
R2: 超能力_インフォメーション<。----------------------------------
Setting up an ESP Security Association between HIP hosts requires three messages to exchange the information that is required during an ESP communication.
HIPホストの間の超能力Security Associationをセットアップするのは超能力コミュニケーションの間必要である情報を交換する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メッセージは超能力_TRANSFORMパラメタを含んでいます。(送付ホストはそれでそれがESP SAのために使用しても構わないと思っている可能な超能力変換を定義します)。
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
I2メッセージはR1メッセージに受け取られた超能力_TRANSFORMへの応答を含んでいます。 送付者は、R1メッセージで超能力_TRANSFORMパラメタから提案された超能力変換の1つを選択して、I2の超能力_TRANSFORMパラメタで選択されたものを入れなければなりません。
Jokela, et al. Experimental [Page 9] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[9ページ]RFC5202
packet. In addition to the transform, the host includes the ESP_INFO parameter containing the SPI value to be used by the peer host.
パケット。 変換に加えて、同輩ホストによって使用されるように、ホストはSPI値を含む超能力_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のためにInitiatorによって必要とされたSPI情報を含んでいます。
4.1.2. Updating an Existing ESP SA
4.1.2. 既存の超能力SAをアップデートします。
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のパラメタをアップデートするのに使用されます。 UPDATEメカニズムとメッセージは[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をアップデートするかを典型的な交換に示します。 メッセージはSEQを含んでいます、そして、ACKパラメタがUPDATEメカニズムが必要です。
H1 H2
UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN]
----------------------------------------------------->
H1 H2は以下をアップデートします。 SEQ、超能力_インフォメーション[ディフィー_ヘルマン]----------------------------------------------------->。
UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN]
<-----------------------------------------------------
以下をアップデートしてください。 SEQ、ACK、超能力_インフォメーション[ディフィー_ヘルマン]<。-----------------------------------------------------
UPDATE: ACK
----------------------------------------------------->
以下をアップデートしてください。 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値、および合わせることの材料のためのインデックス値を含む超能力_INFOパラメタを含んでいます、次のキーが引かれるところから突きを入れて。 また、新しい合わせることの材料を生成しなければならないと、UPDATEメッセージは[RFC5201]で定義されたディフィー_ヘルマンパラメタを含むでしょう。
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.
UPDATEメッセージで既存のESP SA MUST回答のアップデートを要求するUPDATEメッセージを受け取るホスト。 応答メッセージでは、ホストは換算値を含む超能力_INFOパラメタを送ります: 古いSPI、新しいSPI、および合わせることの材料は索引をつけます。 また、入って来るUPDATEがディフィー_ヘルマンパラメタを含んだなら、回答パケットはディフィー_ヘルマンパラメタを含まなければなりません。
5. Parameter and Packet Formats
5. パラメタとパケット・フォーマット
In this section, new and modified HIP parameters are presented, as well as modified HIP packets.
このセクションでは、新しくて変更されたHIPパラメタは変更されたHIPパケットと同様に提示されます。
Jokela, et al. Experimental [Page 10] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[10ページ]RFC5202
5.1. New Parameters
5.1. 新しいパラメタ
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.
2つの新しいHIPパラメタが、HIPコミュニケーションに超能力輸送形式協会を設立して、既存のものを「再-合わせ」るために定義されます。 また、[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)
超能力_INFO、他のインフォメーションの65 12Remoteの古いSPI、新しいSPI、超能力_TRANSFORM4095の可変超能力Encryption、およびAuthentication Transform(s)
5.1.1. ESP_INFO
5.1.1. 超能力_インフォメーション
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に必要とします。 超能力_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セットアップの間、ホストは彼らが、超能力データをそれらに送るとき、同輩に使用して欲しいSPI値を送ります。 値は超能力_INFOパラメタのNEW SPI分野に設定されます。 初期のセットアップで、SPIのための古い値は存在していません、その結果、OLD SPI値の分野がゼロに設定されます。 また、追加SAsがHIPホストの間でセットアップされるとき、OLD SPI分野価値はゼロであるかもしれません、例えば、multihomed HIPホスト[RFC5206]の場合に。 しかしながら、そのような使用はこの仕様の範囲を超えています。
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
RFC4301[RFC4301]は適切にQoSをサポートするために複数のSAsを設立する方法を説明します。 異なったクラスのトラフィック(Differentiated Services Code Point(DSCP)ビット[RFC3474]、[RFC3260]で、区別される)を同じSAに送って、受信機が超能力で利用可能な任意の反再生機能を使っているなら、これはこの特徴によって使用されるウインドーメカニズムのため低優先度パケットを不適当な捨てることをもたらすかもしれません。 したがって、送付者SHOULDは異なったクラスのトラフィックを置きますが、異なったSAsで同じセレクタで適切にService(QoS)のQualityをサポートに評価します。 これを可能にするために、実装は同じセレクタによる与えられた送付者と受信機の間の複数のSAsの設立とメインテナンスを可能にしなければなりません。 QoSをサポートするこれらの平行なSAsの中のトラフィックの分配は、送付者によって局所的に決定されて、HIPによって交渉されません。 受信機はパケットを処理しなければなりません。
Jokela, et al. Experimental [Page 11] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[11ページ]RFC5202
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.
偏見のない異なったSAs。 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.
KEYMATインデックス価値は超能力SAsのための合わせることの材料が引かれるところからKEYMATの場所を示します。 「再-合わせ」るプロセスの間超能力_INFOを送るときだけ、KEYMATインデックス価値はゼロです、そして、新しい合わせることの材料は発生しています。
During the life of an SA established by HIP, one of the hosts may need to reset the Sequence Number to one and rekey. The reason for rekeying might be an approaching sequence number wrap in ESP, or a local policy on use of a key. Rekeying ends the current SAs and starts new ones on both peers.
HIPによって設立されたSAの寿命の間、ホストのひとりは、1とrekeyにSequence Numberをリセットする必要があるかもしれません。 「再-合わせ」る理由は、超能力における迫っている一連番号包装、またはキーの使用に関するローカルの方針であるかもしれません。 Rekeyingは現在のSAsを終わらせて、新しいものを両方の同輩に始めます。
During the rekeying process, the ESP_INFO parameter is used to transmit the changed SPI values and the keying material index.
「再-合わせ」るプロセスの間、超能力_INFOパラメタは、変えられたSPI値と合わせる原料指数を伝えるのに使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | KEYMAT Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLD SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEW SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| KEYMATインデックス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 古いSPI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 新しい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.
バイト、どこの65Length12KEYMAT Index Indexをタイプするか、そして、KEYMATから超能力キーを得続けてください。 パケットが新しいディフィー-ヘルマンキーを含んで、UPDATEパケットで超能力_INFOを送るなら、分野はゼロであるに違いありません。 超能力_INFOがベース交換メッセージに含まれているなら、KEYMAT Indexには、ESP SAキーが引かれるところからのポイントのインデックス値がなければなりません。 この分野の長さがKEYMATから得ることができる合わせることの材料の量を制限することに注意してください。 その量が超えられているなら、パケットは新しいディフィー-ヘルマンキーを含まなければなりません。 データのためのOLD SPIの古いSPIは、このSAに関連している(es)を扱うために発信しました。 これが初期のSAセットアップであるなら、OLD SPI値はゼロです。
Jokela, et al. Experimental [Page 12] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[12ページ]RFC5202
NEW SPI new SPI for data sent to address(es) associated
with this SA.
データのためのNEW SPIの新しいSPIは、このSAに関連している(es)を扱うために発信しました。
5.1.2. ESP_TRANSFORM
5.1.2. 超能力_は変形します。
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.
超能力_TRANSFORMパラメタはESP SA設立の間、使用されます。 最初のパーティーが超能力_TRANSFORMパラメタでいくつかの変換ファミリーを送って、同輩は、提案された値の1つを選択して、応答超能力_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| スイートID#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | スイートID#2| スイートID#3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | スイートID#n| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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年のLengthの長さを八重奏にタイプしてください、と容認されたSuite IDが使用されるために超能力Suiteを定義するとき、Typeを除く、Length、および詰め物Reservedゼロは送ると無視しました。
The following Suite IDs are defined in RFC 5201 [RFC5201]:
以下のSuite IDはRFC5201[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-MD5 6があるHMAC-SHA1 5ヌルがあるHMAC-SHA1 4ヌルがあるHMAC-MD5 3フグ-CBCとHMAC-SHA1 2 3DES-CBCとHMAC-SHA1 1 3DES-CBCと予約された0AES-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
超能力変換パラメタの送付者は、1つの超能力変換パラメタには6(6)スイートIDしかないのを確実にしなければなりません。 逆に、受取人は6つ以上のSuite IDを含む受信された輸送パラメタを扱う用意ができていなければなりません。 Suite IDの限られた数は超能力_TRANSFORMパラメタの最大サイズを設定します。 デフォルト設定として、超能力_TRANSFORMパラメタはそうしなければなりません。
Jokela, et al. Experimental [Page 13] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[13ページ]RFC5202
contain at least one of the mandatory Suite IDs. There MAY be a configuration option that allows the administrator to override this default.
少なくとも義務的なSuite IDの1つを含んでください。 管理者がこのデフォルトをくつがえすことができる設定オプションがあるかもしれません。
Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL with HMAC- SHA1.
義務的な実装: HMAC-SHA1とAES-CBCとHMAC- SHA1があるヌル。
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モードで超能力を伴うTraffic Flow Confidentiality(TFC)[RFC4303]を使用するのは可能です。 しかしながら、そのような操作の定義を今後の活動であり、別々の仕様でしなければなりません。
5.1.3. NOTIFY Parameter
5.1.3. パラメタに通知してください。
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基礎仕様は1セットのNOTIFY誤りタイプを定義します。 以下の誤りタイプが、交渉の間、超能力Transform暗号スイートで誤りについて説明するのに必要です。
NOTIFY PARAMETER - ERROR TYPES Value
------------------------------ -----
パラメタに通知してください--誤りは値をタイプします。------------------------------ -----
NO_ESP_PROPOSAL_CHOSEN 18
選ばれた_超能力_提案がない_、18
None of the proposed ESP Transform crypto suites was
acceptable.
提案された超能力Transform暗号スイートのいずれも許容できませんでした。
INVALID_ESP_TRANSFORM_CHOSEN 19
病人_超能力_が選ばれた_を変える、19
The ESP Transform crypto suite does not correspond to
one offered by the Responder.
超能力Transform暗号スイートはResponderによって提供された1つに対応していません。
5.2. HIP ESP Security Association Setup
5.2. クールな超能力セキュリティ協会セットアップ
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.
超能力Security Associationは塩基置換の間、セットアップされます。 以下の小区分は、塩基置換メッセージ(R1、I2、R2)とUPDATEメッセージの両方を使用することでESP SAセットアップ手順を定義します。
5.2.1. Setup During Base Exchange
5.2.1. 塩基置換の間のセットアップ
5.2.1.1. Modifications in R1
5.2.1.1. R1での変更
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].
超能力_TRANSFORMはよく使われる順の送付者によってサポートされた超能力モードを含んでいます。 すべての実装がHMAC-SHA-1-96[RFC2404]と共にAES-CBC[RFC3602]をサポートしなければなりません。
Jokela, et al. Experimental [Page 14] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[14ページ]RFC5202
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(クールな[R1_カウンタ]パズル、ディフィー_ヘルマン、クールな_変換、超能力_変換、ホスト_ID、[_要求を反映してください]クールな_署名_2)[_要求を反映してください)
5.2.1.2. Modifications in I2
5.2.1.2. I2での変更
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.
超能力_INFOはESP SAキーが引かれるところからのKEYMATインデックスと同様にこの協会のための送付者のSPIを含んでいます。 古い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].
超能力_TRANSFORMはR1の送付者によって選択された超能力モードを含んでいます。 すべての実装が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パケットのための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(クール(超能力_インフォメーション、[R1_カウンタ]ソリューション、ディフィー_ヘルマン、クールな_変換(超能力_変換)はホスト_ID、[_応答をまねてください]HMACを暗号化しました、クールな_署名[_応答をまねる]))です。
5.2.1.3. Modifications in R2
5.2.1.3. R2での変更
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は超能力_INFOパラメタを含んでいます。(それは、この協会のためのR2の送付者のSPI値を持っています)。 また、超能力_INFOには、ESP SAキーがどこに引かれるかを指定するKEYMATインデックス価値があります。
Jokela, et al. Experimental [Page 15] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[15ページ]RFC5202
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(クール(超能力_インフォメーション、HMAC_2、クールな_署名))です。
5.3. HIP ESP Rekeying
5.3. クールな超能力Rekeying
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).
'概念的に、以下のメッセージ系列は、私と'R'がセクション3.3.2で定義したホスト名を使用することでプロセスを表すことができます。 簡単さにおいて、HMACとHIP_SIGNATUREは表現されません、そして、ディフィー_ヘルマンキーは任意です。 ACK_IがあるUPDATEはUPDATEと共にSEQ_Rで背負われる必要はありません。 それは別々にACKedであるかもしれません(その場合、系列は4つのパケットを含んでいるでしょう)。
I' R'
'I'R'
UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN])
<-----------------------------------
UPDATE(ACK_R)
----------------------------------->
(超能力_インフォメーション、SEQ_I[ディフィー_ヘルマン])をアップデートしてください。----------------------------------->アップデート(超能力_インフォメーション、SEQ_R、ACK_I[ディフィー_ヘルマン])<。----------------------------------- アップデート(ACK_R)----------------------------------->。
Below, the first two packets in this figure are explained.
以下で、この図の最初の2つのパケットが説明されます。
5.3.1. Initializing Rekeying
5.3.1. 初期値設定Rekeying
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が超能力と共に使用されるとき、UPDATEパケットは、「再-合わせ」ることを開始するのに使用されます。 UPDATEパケットは、超能力_INFOを運ばなければならなくて、ディフィー_ヘルマンパラメタを運ぶかもしれません。
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値を必要とするかもしれないので、コンテンツを暗号化できません。
Jokela, et al. Experimental [Page 16] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[16ページ]RFC5202
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(クール(超能力_インフォメーション、SEQ、[ディフィー_ヘルマン]HMAC、クールな_署名))です。
5.3.2. Responding to the Rekeying Initialization
5.3.2. Rekeying初期設定に応じます。
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 rekeying初期化を承諾するのに使用されます。 承認UPDATEパケットは、超能力_INFOを運ばなければならなくて、ディフィー_ヘルマンパラメタを運ぶかもしれません。
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(クール(超能力_インフォメーション、SEQ、ACK、[ディフィー_ヘルマン]HMAC、クールな_署名))です。
5.4. ICMP Messages
5.4. ICMPメッセージ
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]で主に説明されます。 このセクションで、私たちは超能力セキュリティ協会に関連する動作について説明します。
5.4.1. Unknown SPI
5.4.1. 未知のSPI
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番号を持っている超能力パケットを受けるなら、タイプ「パラメタ問題」があるICMPパケットで応じるかもしれません(応答を制限するレートにかけます)、指針が超能力ヘッダーのSPI分野の始まりまで指していて。
Jokela, et al. Experimental [Page 17] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[17ページ]RFC5202
6. Packet Processing
6. パケット処理
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]に基づき主に定義されます。 超能力輸送形式が使用されているとき、このセクションはパケット取り扱いのための変化と新しい要件について説明します。 すべてのHIPパケット(現在のプロトコル253)が超能力処理を迂回させなければならないことに注意してください。
6.1. Processing Outgoing Application Data
6.1. 送信するアプリケーションデータを処理します。
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]で指定されます。 超能力輸送形式が使用されていて、与えられた<ソースへの活発なHIPセッションがあるとき、目的地>HITは対にして、発信データグラムは、超能力セキュリティ協会を使用することで保護されます。 典型的な実装では、これは送られるBEET-モード超能力パケットをもたらすでしょう。 セクション3.2で上でBEET-モード[超能力-BEET]を導入しました。 以下の追加ステップは出発している超能力保護されたデータグラムのために概念的な処理規則を定義します。
1. Detect the proper ESP SA using the HITs in the packet header or
other information associated with the packet
1. パケットに関連しているパケットのヘッダーか他の情報でHITsを使用して、適切な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. 出発している超能力保護されたパケットがIPヘッダーに中古のIPアドレスファミリーに頼る適切なIPヘッダー形式、および適切なIPアドレスを持っているのを確実にしてください、例えば、超能力処理で残っているHITsを取り替えることによって。 例えば、超能力処理の前にまた、適切なIPアドレスのこのプレースメントがスタックである他のポイントで実行されるかもしれないことに注意してください。
6.2. Processing Incoming Application Data
6.2. 入って来るアプリケーションデータを処理します。
Incoming HIP user data packets arrive as ESP protected packets. In the usual case, the receiving host has a corresponding ESP security association, identified by the SPI and destination IP address in the packet. However, if the host has crashed or otherwise lost its HIP state, it may not have such an SA.
超能力がパケットを保護したので、入って来るHIPユーザデータ・パケットは到着します。 普通の場合では、受信ホストはパケットにSPIによって特定された対応する超能力セキュリティ協会と送付先IPアドレスを持っています。 しかしながら、ホストがHIP状態を墜落するか、またはそうでなければ、失ったなら、それはそのようなSAを持っていないかもしれません。
The basic incoming data handling is specified in the HIP base specification. Additional steps are required when ESP is used for protecting the data traffic. The following steps define the conceptual processing rules for incoming ESP protected datagrams targeted to an ESP security association created with HIP.
基本的な受信データ取り扱いはHIP基礎仕様で指定されます。 超能力がデータ通信量を保護するのに使用されるとき、追加ステップが必要です。 以下のステップはHIPと共に創設された超能力セキュリティ協会に狙う入って来る超能力保護されたデータグラムのために概念的な処理規則を定義します。
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
1. SPIを使用して、適切なESP SAを検出してください。 結果として起こるSAが非HIP ESP SAであるなら、標準のIPsec規則に従って、パケットを処理してください。 SPIと同一視されたSAsが全くなければ、ホストはいます。
Jokela, et al. Experimental [Page 18] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[18ページ]RFC5202
send an ICMP packet as defined in Section 5.4. How to handle
lost state is an implementation issue.
セクション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に関連しているHITsに取り替えます。 例えば、超能力処理の後にまた、IPアドレスからHITへの変換このステップがスタックである他のポイントで実行されるかもしれないことに注意してください。 また、入って来るパケットにIPv4アドレスがあるなら、アドレスをHITsに取り替える前に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. 通常、変成しているパケットはまるでパケットが交通機関パケットであるかのように超能力で処理されていた状態で次です。 パケットは超能力によっていつものように下げられるかもしれません。 典型的な実装では、うまくいっている超能力復号化と検証の結果はソースと目的地としての関連HITsがあるデータグラムです。
4. The datagram is delivered to the upper layer. Demultiplexing the
datagram to the right upper layer socket is performed as usual,
except that the HITs are used in place of IP addresses during the
demultiplexing.
4. データグラムは上側の層に提供されます。 逆多重化、右の上側の層のソケットへのデータグラムはいつものように実行されます、HITsが逆多重化の間のIPアドレスに代わって使用されるのを除いて。
6.3. HMAC and SIGNATURE Calculation and Verification
6.3. HMAC、署名計算、および検証
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].
HMACと署名計算を使用することで本書では説明された新しいHIPパラメタ_超能力INFOと_(超能力TRANSFORM)を、保護しなければなりません。 典型的な実装では、それらは[RFC5201]で説明されるようにR1、I2、R2、UPDATEパケットHMAC、およびSIGNATURE計算に含まれています。
6.4. Processing Incoming ESP SA Initialization (R1)
6.4. 入って来る超能力SA初期設定を処理します。(R1)
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メッセージで初期化されます。 受信ホスト(創始者)は提示された値から超能力変換の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.
超能力変換を選択して、他のR1処理を実行した後に、システムは、入って来る超能力セキュリティ協会を準備して、創設します。 また、外向的なトラフィックのためにセキュリティ協会を準備するかもしれませんが、正しいSPI値がまだないので、それはそれを動かすことができません。
Jokela, et al. Experimental [Page 19] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[19ページ]RFC5202
6.5. Processing Incoming Initialization Reply (I2)
6.5. 入って来る初期設定回答を処理します。(I2)
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が処理(例えば、HIT比較のため[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 超能力_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 超能力_INFO NEW SPI分野は、Responderからの外国行きの、そして、Initiatorへの本国行きのSecurity Associationに使用されるSPIを入手するために分析されます。 この初期のESP SA設立において、古いSPI値はゼロでなければなりません。 KEYMAT Index分野はESP SAキーが引かれるところからのKEYMATにインデックス値を含まなければなりません。
o The system prepares and creates both incoming and outgoing ESP
security associations.
o システムは、両方の送受信の超能力セキュリティ協会を準備して、創設します。
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 初期化応答メッセージのうまくいっている処理のときに、可能な古いSecurity Associations(HIP協会の以前の肉体化から残されるように)を下げます、そして、新しい方をインストールします、そして、成立パケット(R2)を送ります。 可能な進行中の「再-合わせ」る試みは下げられます。
6.6. Processing Incoming ESP SA Setup Finalization (R2)
6.6. 入って来る超能力SAセットアップ決定を処理します。(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を成立させることができる前に、超能力_INFO NEW SPI分野は、決定メッセージR2の送付者にとっての、本国行きの超能力Security Associationに使用されるSPIを入手するために分析されます。 システムは、送付パケットのために同輩に慣れている出発している超能力セキュリティ協会を創設するか、または動かすのにこのSPIを使用します。
6.7. Dropping HIP Associations
6.7. クールな協会を下げます。
When the system drops a HIP association, as described in the HIP base specification, the associated ESP SAs MUST also be dropped.
また、システムがHIP基礎仕様で説明されるようにHIP協会を下げるとき、関連超能力SAsを下げなければなりません。
6.8. Initiating ESP SA Rekeying
6.8. 超能力SA Rekeyingを開始します。
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.
超能力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
システムはいつでも、SA rekeying手順に着手するかもしれません。 入って来る超能力系列カウンタが開始しようとしているなら、それはrekeyを開始しなければなりません。
Jokela, et al. Experimental [Page 20] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[20ページ]RFC5202
overflow. The system MUST NOT replace its keying material until the rekeying packet exchange successfully completes.
あふれてください。 システムは、交換が首尾よく完成する「再-合わせ」るパケットまで材料を合わせるのを取り替えてはいけません。
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世代における使用に、主要な新しいディフィー-ヘルマンを含むかもしれません。 新しいキーを描く前に、新しい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]で定義されたUPDATEメカニズムを使用します。 各同輩がセキュリティ連想対の半分をアップデートしなければならないので(新しいSPI作成を含んでいて)、「再-合わせ」るプロセスは、それぞれの側がともにUPDATEを送って、受けるのを必要とします。 そして、パラメタを同輩に送って、関連UPDATEメッセージのACKと対応する同輩のパラメタの両方を受け取ったとき、システムはESP SAをrekeyするでしょう。 多分、ACKと必要なHIPパラメタは異なったUPDATEメッセージに届きます。 システムが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. システムは、既存のKEYMATを使用するか、または新しいKEYMATを生成し続けているかどうか決めます。 後者の場合では、システムは新しいディフィー-ヘルマン公開鍵を生成しなければなりません。
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. システムはUPDATEパケットを作成します。(それは、超能力_INFOパラメタを含みます)。 さらに、ホストは任意のディフィー_ヘルマンパラメタを入れるかもしれません。 UPDATEがディフィー_ヘルマンパラメタを含んでいるなら、超能力_INFOパラメタのKEYMAT Indexはゼロであるに違いありません、そして、ディフィー-ヘルマングループIDは初期の握手に使用されるそれから変わりがないに違いありません。 UPDATEがディフィー_ヘルマンを含まないなら、超能力_INFO KEYMAT Indexは次の現在のKEYMATから得られるべきバイトのインデックス以上であるに違いありません。
3. The system sends the UPDATE packet. For reliability, the
underlying UPDATE retransmission mechanism MUST be used.
3. システムはUPDATEパケットを送ります。 信頼性のために、基本的なUPDATE retransmissionメカニズムを使用しなければなりません。
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を削除してはいけません。まだ、許容しています。 手順SHOULDを「再-合わせ」て、念のため、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
5. プロトコル誤りが発生して、同輩システムがUPDATEを承認しますが、それ自体をするといけないというわけではないので、_INFO、システムが送る超能力を送ってください。
Jokela, et al. Experimental [Page 21] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[21ページ]RFC5202
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.
傑出している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更新要求がある間、ホストは新しいUPDATEsを生成してはいけません、更新処理を再開していない場合。
6.9. Processing Incoming UPDATE Packets
6.9. 入って来るアップデートパケットを処理します。
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]):
システムがUPDATEパケットを受けるとき、以下の条件が成立するなら([RFC5201]のセクション6.12におけるUPDATE処理に指定されたジェネリック状態に加えて)、それを処理しなければなりません:
1. A corresponding HIP association must exist. This is usually
ensured by the underlying UPDATE mechanism.
1. 対応するHIP協会は存在しなければなりません。 通常、これは基本的なUPDATEメカニズムによって確実にされます。
2. The state of the HIP association is ESTABLISHED or R2-SENT.
2. HIP協会の状態は、ESTABLISHEDかR2-SENTです。
If the above conditions hold, the following steps define the conceptual processing rules for handling the received UPDATE packet:
上記の状態が成立するなら、以下のステップは容認されたUPDATEパケットを扱うための概念的な処理規則を定義します:
1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the
received KEYMAT Index MUST be zero and the Group ID must match
the Group ID in use on the association. If this test fails, the
packet SHOULD be dropped and the system SHOULD log an error
message.
1. 容認されたUPDATEがディフィー_ヘルマンパラメタを含んでいるなら、容認されたKEYMAT Indexはゼロであるに違いありません、そして、Group IDは協会で使用中のGroup IDに合わなければなりません。 このテストやり損ない、パケットSHOULDが下げられてシステムであるなら、SHOULDはエラーメッセージを登録します。
2. If there is no outstanding rekeying request, the packet
processing continues as specified in Section 6.9.1.
2. どんな傑出している「再-合わせ」る要求もなければ、パケット処理はセクション6.9.1で指定されるように続きます。
3. If there is an outstanding rekeying request, the UPDATE MUST be
acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN)
parameters must be saved, and the packet processing continues as
specified in Section 6.10.
3. 傑出している「再-合わせ」る要求があれば、UPDATE MUSTが承認されて、容認された超能力_INFO(そして、ことによるとディフィー_ヘルマン)パラメタを保存しなければなりません、そして、パケット処理はセクション6.10で指定されるように続きます。
6.9.1. Processing UPDATE Packet: No Outstanding Rekeying Request
6.9.1. 処理アップデートパケット: 傑出しているRekeying要求がありません。
The following steps define the conceptual processing rules for handling a received UPDATE packet with the ESP_INFO parameter:
以下のステップは超能力_INFOパラメタで容認されたUPDATEパケットを扱うための概念的な処理規則を定義します:
1. The system consults its policy to see if it needs to generate a
new Diffie-Hellman key, and generates a new key (with same Group
ID) if needed. The system records any newly generated or
1. システムは、新しいディフィー-ヘルマンキーを生成する必要があるなら見るために方針に相談して、必要であるなら、新しいキー(同じGroup IDがある)を生成します。 またはいずれも新たに生成したシステム記録。
Jokela, et al. Experimental [Page 22] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[22ページ]RFC5202
received Diffie-Hellman keys for use in KEYMAT generation upon
finalizing the ESP SA update.
ESP SAアップデートを成立させるときのKEYMAT世代における使用のための容認されたディフィー-ヘルマンキー。
2. If the system generated a new Diffie-Hellman key in the previous
step, or if it received a DIFFIE_HELLMAN parameter, it sets the
ESP_INFO KEYMAT Index to zero. Otherwise, the ESP_INFO KEYMAT
Index MUST be greater than or equal to the index of the next byte
to be drawn from the current KEYMAT. In this case, it is
RECOMMENDED that the host use the KEYMAT Index requested by the
peer in the received ESP_INFO.
2. システムが前のステップで主要な新しいディフィー-ヘルマンを生成したか、またはディフィー_ヘルマンパラメタを受け取ったなら、それは_超能力INFO KEYMAT Indexをゼロに設定します。 さもなければ、超能力_INFO KEYMAT Indexは次の現在のKEYMATから得られるべきバイトのインデックス以上であるに違いありません。 この場合、ホストが容認された超能力_INFOで同輩によって要求されたKEYMAT Indexを使用するのは、RECOMMENDEDです。
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. システムはUPDATEパケットを作成します。(それは、超能力_INFOパラメタと任意のディフィー_ヘルマンパラメタを含みます)。 また、このUPDATEはACKパラメタがある同輩のUPDATEを通常承認するでしょう、別々のUPDATE ACKを送るかもしれませんが。
4. The system sends the UPDATE packet and stores any received
ESP_INFO and DIFFIE_HELLMAN parameters. At this point, it only
needs to receive an acknowledgment for the newly sent UPDATE to
finish ESP SA update. In the usual case, the acknowledgment is
handled by the underlying UPDATE mechanism.
4. システムは、UPDATEパケットを送って、どんな容認された超能力_INFOとディフィー_ヘルマンパラメタも保存します。 ここに、それは、新たに送られたUPDATEのためにESP SAがアップデートする終わりに承認を受ける必要があるだけです。 普通の場合では、承認は基本的なUPDATEメカニズムによって扱われます。
6.10. Finalizing Rekeying
6.10. Rekeyingを成立させます。
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確認応答パケットを受けて、首尾よく同輩の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.
1. 受信されたUPDATEメッセージが新しいディフィー-ヘルマンキーを含んでいるなら、システムには、ESP SAアップデートを開始するので主要な新しいディフィー-ヘルマンがいるか、またはともに、システムは新しいKEYMATを生成します。 1個の新しいディフィー-ヘルマンキーしかなければ、古い既存のキーはもう片方のキーとして使用されます。
2. If the system generated a new KEYMAT in the previous step, it
sets the KEYMAT Index to zero, independent of whether the
received UPDATE included a Diffie-Hellman key or not. If the
system did not generate a new KEYMAT, it uses the greater KEYMAT
Index of the two (sent and received) ESP_INFO parameters.
2. システムが前のステップで新しいKEYMATを生成したなら、ゼロにKEYMAT Indexを設定します、容認されたUPDATEがディフィー-ヘルマンキーを含んでいたかどうかの如何にかかわらず。 システムが新しいKEYMATを生成しなかったなら、それは2つ(送って、受け取る)の超能力_INFOパラメタの、よりすばらしいKEYMAT Indexを使用します。
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 Indexから始めて、新しい送受信の超能力SAsのためのキーを描いて、新しい送受信の超能力SAsを準備します。 出発しているSAのためのSPIは超能力_INFOパラメタの新しいSPI対価領収です。 超能力_INFOを同輩に送ったとき、入って来るSAのためのSPIを生成しました。 「再-合わせ」るプロセスの間にKEYMATから検索されたキーの注文はセクション7で説明されたそれと同様です。
Jokela, et al. Experimental [Page 23] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[23ページ]RFC5202
Note, that only IPsec ESP keys are retrieved during the rekeying
process, not the HIP keys.
IPsec超能力キーだけがHIPキーではなく、「再-合わせ」るプロセスの間検索されるというメモ。
4. The system starts to send to the new outgoing SA and prepares to
start receiving data on the new incoming SA. Once the system
receives data on the new incoming SA, it may safely delete the
old SAs.
4. システムは、新しい出発しているSAに発信し始めて、データを新しい入って来るSAを受け取り始めるのを準備します。 システムがいったん新しい入って来るSAに関するデータを受け取ると、それは安全に古いSAsを削除するかもしれません。
6.11. Processing NOTIFY Packets
6.11. 処理して、パケットに通知してください。
The processing of NOTIFY packets is described in the HIP base specification.
NOTIFYパケットの処理はHIP基礎仕様で説明されます。
7. Keying Material
7. 材料を合わせます。
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協会キーが描かれた後に、超能力キーは以下のオーダーに描かれます:
SA-gl ESP encryption key for HOST_g's outgoing traffic
HOST_gの外向的なトラフィックに、主要なSA-gl超能力暗号化
SA-gl ESP authentication key for HOST_g's outgoing traffic
HOST_gの外向的なトラフィックに、主要なSA-gl超能力認証
SA-lg ESP encryption key for HOST_l's outgoing traffic
HOST_lの外向的なトラフィックに、主要なSA-lg超能力暗号化
SA-lg ESP authentication key for HOST_l's outgoing traffic
HOST_lの外向的なトラフィックに、主要なSA-lg超能力認証
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.
R2が交換するHIP I1->の間、KEYMATから4個のHIPキーしか得ません。 UPDATEを使用するその後の「再-キー」がKEYMATから4個の超能力キーしか得ないでしょう。 セクション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
AES128ビット
SHA-1 160 bits
SHA-1 160ビット
NULL 0 bits
NULL0ビット
Jokela, et al. Experimental [Page 24] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[24ページ]RFC5202
8. Security Considerations
8. セキュリティ問題
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ホストの間の超能力[RFC4303]の用法を導入します。 超能力仕様で超能力のためのSecurity Considerationsについて議論します。
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つのノードの間には、超能力Security Associationを確立する異なった方法があります。 これができて、例えば、使用はIKE[RFC4306]です。 このドキュメントはHost Identityプロトコルが超能力Security Associationsを証明するのにどう使用されるかを指定します。
The following issues are new or have changed from the standard ESP usage:
以下の問題は、新しいか、または標準の超能力用法から変化しました:
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.
ディフィー-ヘルマン手順を用いることでHost Identityプロトコル[RFC5201]を使用するのは初期の合わせることの材料に生成されます。 このドキュメントは、既存の超能力SAsを変更するために基礎仕様に基づき定義されたUPDATEパケットの使用法を広げています。 ホストはrekeyするかもしれなくて、すなわち、力はディフィーヘルマン手順を用いる新しい合わせることの材料の世代です。 塩基置換の間、ホストの間のESP SAの初期のセットアップをします、そして、塩基置換で提供されたメソッドを使用することで交換処理を保護します。 接続パラメタにおける変化は古いESP SAが取り外されて、UPDATE交換処理がいったん完成されると新しいものが発生していることを基本的に意味します。 交換処理は、HIP協会キーを使用することで保護されます。 HMACとパケットの署名の両方が使用されています。
9. IANA Considerations
9. IANA問題
This document defines additional parameters and NOTIFY error types for the Host Identity Protocol [RFC5201].
このドキュメントはHost Identityプロトコル[RFC5201]のために追加パラメタとNOTIFY誤りタイプを定義します。
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]で指定されたParameter Type名前空間に加えられます。
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 Message Type名前空間に加えられます。
Jokela, et al. Experimental [Page 25] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[25ページ]RFC5202
10. Acknowledgments
10. 承認
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、およびミカKomuを含んでいます。 また、作者は、彼の目が暗号アルゴリズムの用法にある状態でドキュメントを再検討して頂いて、チャーリー・カウフマンに感謝したがっています。
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.
このドキュメントの歴史のため、考えの大部分はベース「ホストアイデンティティプロトコル」仕様から引き継がれます。 したがって、また、このドキュメントに、その仕様のAcknowledgments部の人々のリストも有効です。 多くの人々が有益なフィードバック、および私たちの謝罪を名前がなくなるだれにも与えました。
11. References
11. 参照
11.1. Normative references
11.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
そして、[RFC2404] マドソン、C.、およびR.グレン、「超能力の中のHMAC-SHA-1-96の使用、ああ、」、RFC2404、11月1998日
[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と共にアルゴリズムとその使用を解きます」、RFC3602、2003年9月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、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.ヘンダーソン、「ホストアイデンティティプロトコル」、RFC5201、4月2008日
11.2. Informative references
11.2. 有益な参照
[ESP-BEET] Nikander, P. and J. Melen, "A Bound End-to-End Tunnel
(BEET) mode for ESP", Work in Progress, November 2007.
[超能力-BEET] NikanderとP.とJ.メレン、「超能力のためのBound Endから終わりへのTunnel(BEET)モード」、Progress、2007年11月のWork。
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[RFC3260] グロースマンと、D.と、「Diffservのための新しい用語と明確化」、RFC3260、4月2002日
Jokela, et al. Experimental [Page 26] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[26ページ]RFC5202
[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、「Generalized MultiProtocol Label Switching(GMPLS)リソース予約プロトコルのためのIANA課題のドキュメンテーション--Automatically Switched Optical Network(ASON)のためにEngineering(RSVP-TE)用法とExtensionsを取引してください」、RFC3474、2003年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4423] マスコウィッツ、R.、およびP.Nikander(「ホストのアイデンティティのプロトコルの(クール)のアーキテクチャ」、RFC4423)は2006がそうするかもしれません。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming
with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] ヘンダーソン、T.、エド、「ホストのアイデンティティがある終わりホストの移動性とマルチホーミングは議定書を作る」、RFC5206、4月2008日
Jokela, et al. Experimental [Page 27] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[27ページ]RFC5202
Appendix A. A Note on Implementation Options
付録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ヘッダーを書き直すことです。 そのような実装IPsecがまるでそれが処理IPv6交通機関パケットであるかのように使用されています、IPv6ヘッダーがソースと目的地アドレス・フィールドのIPアドレスの代わりにHITsを含んでいて。 出発しているパケットでは、IPsec処理の後にHITsを実際のIPアドレスに取り替えます、HITsとSPIに基づいて。 入って来るパケットでは、IPsec処理の前にIPアドレスをHITsに取り替えます、入って来るパケットのSPIに基づいて。 そのような実装では、すべてのIPsec方針がHITsに基づいています、そして、上側の層はIPアドレスの場所のHITsと共にパケットを見るだけです。 その結果、SPI空間が別々に保たれる限り、HIPのサポートは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).
この仕様を履行する別の方法は提案されたBEETモード(超能力のためのBound Endから終わりへのモード、[超能力-BEET])を使用することです。 BEETモードはIPsecトンネルと交通機関の両方からいくつかの特徴を提供します。 HIPは「外側」のアドレスとして「内側」のアドレスとIPアドレスとしてのHITsを使用します、IPアドレスがトンネルモードで使用されるように。 ホストの間のパケットにトンネルを堀ることの代わりに、終わりホストで内側の、そして、外側のアドレスの間の変換をします、そして、初期のHIP交渉の後に内側のアドレスをワイヤに決して送りません。 BEETは限られたトンネルモード意味論(固定論理的な内側のアドレス(HITs)と変わりやすい外側のIPアドレス)にIPsec交通機関構文(内側のヘッダーがない)を提供します。
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つの実装レベル利益があります。 アドレスの書き直しを実装するBEET-方法はSADの1つの場所ですべての設定情報を保ちます。 他方では、アドレスであるときに、書き直しは別々に実装されます、そして、実装は確実にそれをSADの情報にしなければなりません、そして、別々のアドレス書き直しDBは同期で保たれます。 その結果、この仕様を履行するBEETモードベースの方法は別々の実装の上のRECOMMENDEDです。
Jokela, et al. Experimental [Page 28] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[28ページ]RFC5202
Authors' Addresses
作者のアドレス
Petri Jokela Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
ペトリ・Jokelaエリクソン研究NomadicLab JORVASフィン-02420フィンランド
Phone: +358 9 299 1 EMail: petri.jokela@nomadiclab.com
以下に電話をしてください。 +358 9 299 1 メール: 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好みクリークBlvd、スイート200メカニクスバーグ(PA)米国の独立している師団
EMail: rgm@icsalabs.com
メール: rgm@icsalabs.com
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
ペッカ・Nikanderエリクソン研究NomadicLab JORVASフィン-02420フィンランド
Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com
以下に電話をしてください。 +358 9 299 1 メール: pekka.nikander@nomadiclab.com
Jokela, et al. Experimental [Page 29] RFC 5202 Using the ESP Transport Format with HIP April 2008
Jokela、他 クールな2008年4月がある超能力輸送形式を使用する実験的な[29ページ]RFC5202
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Jokela, et al. Experimental [Page 30]
Jokela、他 実験的[30ページ]
一覧
スポンサーリンク
