Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 6078 J. Melen
Category: Experimental Ericsson
ISSN: 2070-1721 January 2011
Host Identity Protocol (HIP) Immediate Carriage and Conveyance
of Upper-Layer Protocol Signaling (HICCUPS)
Abstract
抽象
This document defines a new Host Identity Protocol (HIP) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks.
この文書では、DATAと呼ばれる新しいホスト識別プロトコル（HIP）パケットタイプを定義します。 HIPデータパケットを確実に様々なオーバレイネットワーク上で認証された任意のプロトコルメッセージを伝えるために使用されます。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6078.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6078で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Message Formats . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. HIP Fixed Header . . . . . . . . . . . . . . . . . . . 4
3.1.2. HIP Parameter Format . . . . . . . . . . . . . . . . . 5
3.2. HIP Base Exchange, Updates, and State Removal . . . . . . 5
4. Definition of the HIP_DATA Packet . . . . . . . . . . . . . . 6
4.1. Definition of the SEQ_DATA Parameter . . . . . . . . . . . 8
4.2. Definition of the ACK_DATA Parameter . . . . . . . . . . . 8
4.3. Definition of the PAYLOAD_MIC Parameter . . . . . . . . . 9
4.4. Definition of the TRANSACTION_ID Parameter . . . . . . . . 10
5. Generation and Reception of HIP_DATA Packets . . . . . . . . . 10
5.1. Handling of SEQ_DATA and ACK_DATA . . . . . . . . . . . . 10
5.2. Generation of a HIP_DATA Packet . . . . . . . . . . . . . 11
5.3. Reception of a HIP_DATA Packet . . . . . . . . . . . . . . 12
5.3.1. Handling of SEQ_DATA in a Received HIP_DATA Packet . . 13
5.3.2. Handling of ACK_DATA in a Received HIP_DATA Packet . . 14
6. Use of the HIP_DATA Packet . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative references . . . . . . . . . . . . . . . . . . 16
Two hosts can use HIP [RFC5201] to establish a security association (SA) between them in order to exchange arbitrary protocol messages over that security association. The establishment of such a security association involves a four-way handshake referred to as the HIP base exchange. When handling communications between the hosts, HIP supports mobility, multihoming, security, and NAT traversal. Some applications require these features for their communications but cannot accept the overhead involved in establishing a security association (i.e., the HIP base exchange) before those communications can start.
二つのホストがそのセキュリティアソシエーション上の任意のプロトコルメッセージを交換するために、それらの間にセキュリティ・アソシエーション（SA）を確立するために、HIP [RFC5201]を使用することができます。そのようなセキュリティ・アソシエーションの確立は、HIP基本交換と呼ばれる4ウェイハンドシェイクを含みます。ホスト間の通信を処理すると、HIPは、モビリティ、マルチホーミング、セキュリティ、およびNATトラバーサルをサポートしています。一部のアプリケーションは、その通信のためにこれらの機能を必要とするが、それらの通信が開始する前に（すなわち、HIPベース交換）セキュリティアソシエーションの確立に伴うオーバーヘッドを受け入れることはできません。
In this document, we define the HIP DATA packet, which can be used to convey (in a authenticated and reliable way) protocol messages to a remote host without running the HIP base exchange. The HIP_DATA packet has the following semantics: unordered, duplicate free, reliable, and authenticated message-based delivery service. We also discuss the trade-offs involved in using this packet (i.e., less overhead but also less denial-of-service (DoS) protection) and the situations where it is appropriate to use this packet. The HIP_DATA packet is not intended to be a replacement for the Encapsulating Security Payload (ESP) transport; instead, it SHOULD NOT be used to exchange more than a few packets between peers. If a continuous communication is required or communication that requires confidentiality protection then hosts MUST run the HIP base exchange to set up an ESP security association. Additionally, APIs to higher-level protocols that might use this service are outside of the scope of this document.
この文書では、HIP基本交換を実行せずにリモートホストに（認証され、信頼性の高い方法で）プロトコルメッセージを伝えるために使用することができるHIPデータパケットを定義します。順不同、無料、信頼性、および認証されたメッセージベースの配信サービスを複製：HIP_DATAパケットは、以下の意味を持っています。我々はまた、（すなわち、少ないオーバーヘッドも少ないのサービス拒否（DoS）の保護）と、このパケットを使用することが適切である状況このパケットの使用に関連するトレードオフを議論します。 HIP_DATAパケットをカプセル化セキュリティペイロード（ESP）の輸送のための代替となるものではありません。その代わり、ピア間のいくつかのパケットよりも多くを交換するために使用しないでください。連続通信が必要か、機密性保護を必要と通信されている場合、ホストは、ESPセキュリティアソシエーションを設定するにはHIP基本交換を実行する必要があります。また、このサービスを使用する場合があります高レベルプロトコルへのAPIは、この文書の範囲外です。
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]. In addition, this document uses the terms defined in [RFC5201].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC2119]に記載されているように解釈されます。また、このドキュメントは[RFC5201]で定義された用語を使用します。
Message Integrity Code (MIC) is a collision-resistant hash sum calculated over the message that is being integrity protected. The MIC does not use secret keys, and thus it needs additional means to ensure that it has not been tampered with during transmission. Essentially, the MIC is same as the Message Authentication Code (MAC) with the distinction that the MIC does not use secret keys. The MIC is also often referred as the Integrity Check Value (ICV), fingerprint, or unkeyed MAC.
メッセージ完全性コード（MIC）は、完全性が保護されたメッセージにわたって計算衝突困難ハッシュ値です。 MICは、秘密鍵を使用していないので、それが送信中に改ざんされていないことを確認するために追加の手段を必要とします。基本的に、MICは、MICは、秘密鍵を使用していないことを区別してメッセージ認証コード（MAC）と同じです。 MICは、また、多くの場合、整合性チェック値（ICV）、指紋、またはキーなしMACと呼ばれています。
The HIP specification [RFC5201] defines a number of messages and parameters. The parameters are encoded as TLVs, as shown in Section 3.1.2. Furthermore, the HIP header carries a Next Header field, allowing other arbitrary packets to be carried within HIP packets.
HIP仕様[RFC5201]はメッセージとパラメータの数を定義します。セクション3.1.2に示すように、パラメータは、のTLVとして符号化されます。また、HIPのヘッダは、他の任意のパケットはHIPパケット内で搬送されることを可能にする、次のヘッダーフィールドを運びます。
The HIP packet format consists of a fixed header followed by a variable number of parameters. The parameter format is described in Section 3.1.2.
HIPパケットフォーマットは、パラメータの可変数続く固定ヘッダから成ります。パラメータ形式は、3.1.2項で説明されています。
The fixed header is defined in Section 5.1 of [RFC5201] and copied below.
固定ヘッダは、[RFC5201]のセクション5.1で定義され、以下にコピーされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Length |0| Packet Type | VER. | RES.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Controls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ HIP Parameters /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The HIP header is logically an IPv6 extension header. The HIP specification [RFC5201] defines handling only for Next Header value decimal 59, IPv6-NoNxt [PROTOCOL-NUMBERS], the IPv6 'no next header' value. This document describes processing for Next Header values other than decimal 59, which indicates that there are either more extension headers and/or data following the HIP header.
HIPヘッダは、論理的にIPv6拡張ヘッダです。 HIP仕様[RFC5201]は次ヘッダ値の小数59のみ取り扱い定義のIPv6-NoNxt [PROTOCOL-NUMBERS]、IPv6の 'いいえ次のヘッダー' 値。この文書では、HIPヘッダー以下のより拡張ヘッダおよび/またはデータのいずれかが存在することを示す59進以外の次ヘッダ値のための処理について説明します。
The HIP parameter format is defined in Section 5.2.1 of [RFC5201], and copied below.
HIPパラメータフォーマットは、[RFC5201]のセクション5.2.1で定義され、以下にコピーされます。
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 |C| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Contents /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type code for the parameter. 16 bits long, C-bit being part of the Type code. C Critical. One if this parameter is critical, and MUST be recognized by the recipient; zero otherwise. The C bit is considered to be a part of the Type field. Consequently, critical parameters are always odd and non-critical ones have an even value. Length Length of the Contents, in octets. Contents Parameter specific, defined by Type. Padding Padding, 0-7 octets, added if needed.
パラメータのタイプのコードを入力します。 16ビット長、Cビットは、タイプ・コードの一部です。 Cクリティカル。一つは、このパラメータは重要であり、そして受信者によって認識されなければならない場合。そうでない場合はゼロ。 Cビットは、タイプフィールドの一部であると考えられます。そのため、重要なパラメータは常に奇数であり、非重要なものは、偶数値を持っています。オクテット内容の長さの長さ、。内容は、タイプによって定義され、特定のパラメータ。必要に応じてパディングパディング、0-7オクテットは、追加しました。
The HIP base exchange is a four-message authentication and key exchange protocol that creates shared, mutually authenticated keying material at the communicating parties. These keying materials, together with associated public keys and IP addresses, form a HIP security association (SA). The details of the protocol are defined in the HIP base exchange specification [RFC5201].
HIP基本交換は、通信相手で共有、相互認証鍵材料を作成四メッセージ認証及び鍵交換プロトコルです。一緒に関連する公開鍵とIPアドレスを持つこれらのキーイング材料は、HIPのセキュリティアソシエーション（SA）を形成します。プロトコルの詳細は、HIP基本交換仕様[RFC5201]で定義されています。
In addition to creating the HIP SA, the base exchange messages may carry additional parameters that are used to create additional state. For example, the HIP ESP specification [RFC5202] defines how HIP can be used to create end-to-end, host-to-host IPsec ESP security associations, used to carry data packets. However, it is important to understand that the HIP base exchange is by no means bound to IPsec; using IPsec ESP to carry data traffic forms just a baseline and ensures interoperability between initial HIP implementations.
HIPのSAを作成することに加えて、塩基交換メッセージは、追加の状態を作成するために使用される追加のパラメータを搬送することができます。例えば、HIP ESP仕様[RFC5202]はHIPは、データパケットを運ぶために使用されるエンドツーエンド、ホスト間のIPsec ESPセキュリティアソシエーションを作成するために使用することができる方法を定義します。しかし、HIP基本交換はIPsecのにバインドされるものではないことを理解することが重要です。ただ、ベースラインデータトラフィックのフォームを運ぶためにIPsecのESPを使用して、最初のHIP実装間の相互運用性を保証します。
Once there is a HIP SA between two HIP-enabled hosts, they can exchange further HIP control messages. Typically, UPDATE messages are used. For example, the HIP mobility and multihoming specification [RFC5206] defines how to use UPDATE messages to change the set of IP addresses associated with a HIP SA.
2 HIP対応のホスト間のHIP SAがあるならば、彼らはさらにHIP制御メッセージを交換することができます。一般的に、UPDATEメッセージが使用されています。例えば、HIPモビリティ及びマルチホーミング仕様[RFC5206]はHIP SAに関連付けられたIPアドレスのセットを変更するUPDATEメッセージを使用する方法を定義します。
In addition to the base exchange and updates, the HIP base protocol specification also defines how one can remove a HIP SA once it is no longer needed.
塩基交換及び更新に加えて、HIP基本プロトコル仕様では、それが不要になったら一つはHIP SAを削除することができない方法を定義します。
The HIP DATA packet can be used to convey protocol messages to a remote host without running the HIP base exchange. HIP DATA packets are transmitted reliably, as discussed in Section 5. The payload of a HIP_DATA packet is placed after the HIP header and protected by a PAYLOAD_MIC parameter, which is defined in Section 4.3. The following is the definition of the HIP_DATA packet (see the definition of notation in [RFC5201], Section 2.2):
HIPデータパケットはHIP基本交換を実行せずにリモートホストにプロトコルメッセージを伝えるために使用することができます。 HIP_DATAパケットのペイロードは、セクション4.3で定義されPAYLOAD_MICパラメータでHIPヘッダの後に置かれ、保護されているセクション5で説明したようにHIPデータパケットは、確実に伝達されます。 HIP_DATAパケットの定義は、以下の（[RFC5201]、セクション2.2で表記の定義を参照）。
Header: Packet Type = 32 SRC HIT = Sender's HIT DST HIT = Receiver's HIT
ヘッダー：パケットタイプ= 32 SRCのHIT =送信者のHIT DSTのHIT = ReceiverのHIT
IP ( HIP ( [HOST_ID, ] SEQ_DATA, PAYLOAD_MIC, [ PAYLOAD_MIC, ..., ] HIP_SIGNATURE) PAYLOAD )
IP（HIP（[HOST_ID、] SEQ_DATA、PAYLOAD_MIC、[PAYLOAD_MIC、...、] HIP_SIGNATURE）ペイロード）
IP ( HIP ( [HOST_ID, ] SEQ_DATA, ACK_DATA, PAYLOAD_MIC, [ PAYLOAD_MIC, ..., ] HIP_SIGNATURE) PAYLOAD )
IP（HIP（[HOST_ID、] SEQ_DATA、ACK_DATA、PAYLOAD_MIC、[PAYLOAD_MIC、...、] HIP_SIGNATURE）ペイロード）
IP ( HIP ( [HOST_ID, ] ACK_DATA, HIP_SIGNATURE))
IP（HIP（[HOST_ID、】ACK_DATA、HIP_SIGNATURE））
The SEQ_DATA and ACK_DATA parameters are defined in Sections 4.1 and 4.2, respectively. They are used to provide a reliable delivery of HIP_DATA packets, as discussed in Section 5.
SEQ_DATAとACK_DATAパラメータはそれぞれ、セクション4.1および4.2で定義されています。セクション5で説明したように、それらは、HIP_DATAパケットの信頼できる配信を提供するために使用されます。
The HOST_ID parameter is defined in Section 5.2.8 of [RFC5201]. This parameter is the sender's Host Identifier that is used to compute the HIP_DATA packet's signature and to verify it against the received signature. The HOST_ID parameter is optional as it MAY have been delivered using out-of-band mechanism to the receiver. If the host doesn't have reliable information that the corresponding node has its HOST_ID, it MUST always include the HOST_ID in the packet. If the receiver is unable to verify the SIGNATURE, then the packet MUST be dropped and the appropriate NOTIFY packet SHOULD be sent to the sender indicating AUTHENTICATION_FAILED as described in [RFC5201], Section 5.2.16.
HOST_IDパラメータは、[RFC5201]のセクション5.2.8で定義されています。このパラメータは、HIP_DATAパケットの署名を計算するために使用され、受信した署名に対してそれを検証するために、送信者のホスト識別子です。それは、受信機へのアウトオブバンドメカニズムを用いて送達されていてもよいようにHOST_IDパラメータはオプションです。ホストは、対応するノードがHOST_IDを持っていることを信頼できる情報を持っていない場合、それは常にパケットにHOST_IDを含まなければなりません。受信機は、署名を検証できない場合、パケットは廃棄されなければならなくて、[RFC5201]に記載されているように適切なNOTIFYパケットは、セクション5.2.16、AUTHENTICATION_FAILEDを示す送信者に送信されるべきです。
The PAYLOAD_MIC parameter is defined in Section 4.3. This parameter contains the MIC of the payload carried by the HIP_DATA packet. The PAYLOAD_MIC contains the collision-resistant hash of the payload following the HIP DATA. The PAYLOAD_MIC is included in the signed part of the HIP DATA packet and gives integrity protection for the packet as well as the payload carried after it.
PAYLOAD_MICパラメータは、4.3節で定義されています。このパラメータは、HIP_DATAパケットによって運ばれるペイロードのMICが含まれています。 PAYLOAD_MICはHIPのデータに続くペイロードの衝突耐性ハッシュが含まれています。 PAYLOAD_MICはHIPデータパケットの署名部分に含まれ、パケットだけでなく、それの後に行わペイロードの完全性保護を与えています。
The HIP_SIGNATURE parameter is defined in Section 5.2.11 of [RFC5201]. It contains a signature over the contents of the HIP_DATA packet. The calculation and verification of the signature is defined in Section 6.4.2. of [RFC5201].
HIP_SIGNATUREパラメータは、[RFC5201]のセクション5.2.11に定義されています。それはHIP_DATAパケットの内容を超える署名が含まれています。署名の計算及び検証はセクション6.4.2で定義されています。 [RFC5201]の。
Section 5.3 of [RFC5201] states the following:
[RFC5201]の5.3節には、次のように述べています：
In the future, an OPTIONAL upper-layer payload MAY follow the HIP header. The Next Header field in the header indicates if there is additional data following the HIP header.
将来的には、OPTIONAL上層ペイロードはHIPヘッダに従うことができます。 HIPヘッダ以下の追加データがある場合、ヘッダーのNext Headerフィールドを示します。
We have chosen to place the payload after the HIP extension header and only to place a MIC of the payload into the HIP extension header in a PAYLOAD_MIC parameter because that way the data integrity is protected by a public key signature with the help of the MIC. The payload that is protected by the PAYLOAD_MIC parameter has been linked to the appropriate upper-layer protocol by storing the upper-layer protocol number, 8 octets of payload data, and by calculating a hash sum (MIC) over the data. The HIP_DATA packet MAY contain one or more PAYLOAD_MIC parameters, each bound to a different Next Header type. The hash algorithm used to generate the MIC is the same as the algorithm used to generate the Host Identity Tag [RFC5201].
私たちは、HIP拡張ヘッダの後にペイロードを配置することを選択しただけPAYLOAD_MICパラメータでHIP拡張ヘッダにペイロードのMICを配置するため、データの整合性は、MICの助けを借りて、公開鍵署名によって保護されている方法。 PAYLOAD_MICパラメータによって保護されたペイロードを上位層プロトコル番号、ペイロードデータの8つのオクテットを記憶することにより、データ上のハッシュ和（MIC）を計算することにより、適切な上位層プロトコルに関連しています。 HIP_DATAパケットは、一つ以上のPAYLOAD_MICパラメータ、異なる次ヘッダタイプにバインドされた各を含むかもしれません。 MICを生成するために使用されるハッシュアルゴリズムは、ホストアイデンティティタグ[RFC5201]を生成するために使用されるアルゴリズムと同じです。
Upper-layer protocol messages, such as overlay network control traffic, sent in HIP DATA messages may need to be matched to different transactions. For this purpose, a DATA message MAY also contain a TRANSACTION_ID parameter. The identifier value is a variable length bit string in network byte order that is unique for each transaction. A response to a request uses the same identifier value, thereby allowing the receiver to match requests to responses.
このようなHIPデータメッセージで送信されたオーバーレイネットワーク制御トラフィックなどの上位層プロトコル・メッセージは、異なるトランザクションに一致させる必要があるかもしれません。このためには、DATAメッセージもTRANSACTION_IDパラメータを含むかもしれません。識別子の値は、各トランザクションに固有のネットワークバイト順に可変長ビット列です。要求に対する応答は、それによって受信機が応答への要求と一致することができ、同じ識別子の値を使用します。
The following is the definition of the SEQ_DATA parameter:
次はSEQ_DATAパラメータの定義は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4481 Length 4 Sequence number 32-bit unsigned integer in network byte order that MUST NOT be reused before it has been acknowledged by the receiver.
それは、受信機によって肯定応答される前に再利用してはいけませんネットワークバイト順にタイプ4481の長4シーケンス番号32ビットの符号なし整数。
This parameter has the critical bit set. If it is not supported by the receiver, the packet MUST be dropped and the appropriate NOTIFY packet SHOULD be sent to the sender indicating UNSUPPORTED_CRITICAL_PARAMETER_TYPE as described in [RFC5201], Section 5.2.16.
このパラメータは、重要なビットがセットされています。それは、受信機でサポートされていない場合、パケットは廃棄されなければならなくて、[RFC5201]に記載されているように適切なNOTIFYパケットは、セクション5.2.16、UNSUPPORTED_CRITICAL_PARAMETER_TYPEを示す送信者に送信されるべきです。
The following is the definition of the ACK_DATA parameter:
次はACK_DATAパラメータの定義は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acked Sequence number /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4545 Length variable (multiple of 4) Acked Sequence number A sequence of 32-bit unsigned integers in network byte order corresponding to the sequence numbers being acknowledged.
タイプ4545の長さ変数（4の倍数）ACKさシーケンス番号肯定応答されたシーケンス番号に対応するネットワークバイト順に32ビット符号なし整数の配列。
This parameter has the critical bit set. If it is not supported by the receiver, the packet MUST be dropped and the appropriate NOTIFY packet SHOULD be sent to the sender indicating UNSUPPORTED_CRITICAL_PARAMETER_TYPE as described in [RFC5201], Section 5.2.16.
このパラメータは、重要なビットがセットされています。それは、受信機でサポートされていない場合、パケットは廃棄されなければならなくて、[RFC5201]に記載されているように適切なNOTIFYパケットは、セクション5.2.16、UNSUPPORTED_CRITICAL_PARAMETER_TYPEを示す送信者に送信されるべきです。
The following is the definition of the PAYLOAD_MIC parameter:
次はPAYLOAD_MICパラメータの定義は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ MIC Value /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4577 Length Length in octets, excluding Type, Length, and Padding. Next Header Identifies the data that is protected by this MIC. The values for this field are defined by IANA "Protocol Numbers" [PROTOCOL-NUMBERS]. Payload Data Last 8 octets of the payload data over which the MIC is calculated. This field is used to uniquely bind the PAYLOAD_MIC parameter to the Next Header, in case there are multiple copies of the same type. MIC Value MIC computed over the data to which the Next Header and Payload Data point. The size of the MIC is the natural size of the computation output depending on the function used.
タイプ、長さ、およびパディングを除くオクテットでタイプ4577の長さの長さ。次ヘッダは、このMICによって保護されたデータを識別します。このフィールドの値はIANA "プロトコル番号" [PROTOCOL-NUMBERS]によって定義されます。ペイロード・データ最終MICが計算されるペイロードデータの8つのオクテット。このフィールドは、一意に次のヘッダーにPAYLOAD_MICパラメータを結合するために使用され、場合に、同じタイプの複数のコピーが存在します。 MIC値はMICの次ヘッダとペイロードデータポイントデータにわたって計算します。 MICのサイズは、使用する機能に応じて演算出力の自然なサイズです。
This parameter has the critical bit set. If it is not supported by the receiver, the packet MUST be dropped and the appropriate NOTIFY packet SHOULD be sent to the sender indicating UNSUPPORTED_CRITICAL_PARAMETER_TYPE as described in [RFC5201], Section 5.2.16.
このパラメータは、重要なビットがセットされています。それは、受信機でサポートされていない場合、パケットは廃棄されなければならなくて、[RFC5201]に記載されているように適切なNOTIFYパケットは、セクション5.2.16、UNSUPPORTED_CRITICAL_PARAMETER_TYPEを示す送信者に送信されるべきです。
There is a theoretical possibility that when generating multiple PAYLOAD_MIC parameters that will be carried in a single packet, they would have identical Next Header and Payload Data fields; thus, it is required that PAYLOAD_MIC parameters MUST follow the natural order of extension headers in the packet so that it's possible to bind PAYLOAD_MICs to correct payload data. In case the receiving host is still unable to identify the payloads, it MUST drop the packet and
単一のパケットで運ばれる複数のPAYLOAD_MICパラメータを生成する際に、それらが同一で次ヘッダとペイロードデータフィールドを有することが理論的に可能性があります。したがって、ペイロードデータを修正するためにPAYLOAD_MICsをバインドすることができますようにPAYLOAD_MICパラメータは、パケット内の拡張ヘッダの自然な順序に従わなければならないことが必要です。場合に、受信ホストは、それがパケットを削除する必要があり、依然としてペイロードを識別することができず、
SHOULD send a NOTIFY packet to the sender indicating INVALID_SYNTAX as described in [RFC5201], Section 5.2.16.
[RFC5201]に記載されているように、INVALID_SYNTAXを示す送信者にセクション5.2.16をNOTIFYパケットを送信すべきです。
The following is the definition of the TRANSACTION_ID parameter:
次はTRANSACTION_IDパラメータの定義は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4580 Length Length of the Identifier, in octets Identifier The identifier value Padding 0-7 octets of padding if needed
必要に応じて、オクテットタイプ4580の識別子の長さの長さは、識別子値のパディングをパディング0-7オクテットを識別子
Figure 1
図1
HIP_DATA packets are transmitted reliably. Reliable delivery is achieved through the use of retransmissions and of the SEQ_DATA and ACK_DATA parameters.
HIP_DATAパケットが確実に伝達されています。信頼性の高い配信は、再送信を使用してとSEQ_DATAとACK_DATAパラメータで達成されます。
A HIP_DATA packet MUST contain at least one of a SEQ_DATA or an ACK_DATA parameter; if both parameters are missing, then packet MUST be dropped as invalid.
HIP_DATAパケットはSEQ_DATA又はACK_DATAパラメータの少なくとも一つを含まなければなりません。両方のパラメータが欠落している場合、そのパケットは無効として廃棄されなければなりません。
A HIP_DATA packet containing a SEQ_DATA parameter MUST contain one or more PAYLOAD_MIC parameters; otherwise, the packet MUST be dropped. The presence of a SEQ_DATA parameter indicates that the receiver MUST ACK the HIP_DATA packet. A HIP_DATA packet that does not contain a SEQ_DATA parameter is simply an ACK of a previous HIP_DATA packet, and it MUST NOT be ACKed.
SEQ_DATAパラメータを含むHIP_DATAパケットは、一つ以上のPAYLOAD_MICパラメータを含まなければなりません。そうでない場合、パケットは廃棄されなければなりません。 SEQ_DATAパラメータの存在は、受信機がHIP_DATAパケットをACKしなければならないことを示しています。 SEQ_DATAパラメータが含まれていないHIP_DATAパケットは、単に以前のHIP_DATAパケットのACKであり、ACKされてはなりません。
A HIP_DATA packet containing an ACK_DATA parameter echoes the SEQ_DATA sequence numbers of the HIP_DATA packets being acknowledged. The ACK_DATA parameter MUST acknowledge at least one SEQ_DATA sequence number and MAY acknowledge multiple SEQ_DATA sequence numbers by adding all of them to the ACK_DATA parameter.
ACK_DATAパラメータを含むHIP_DATAパケットが確認応答さHIP_DATAパケットのSEQ_DATAシーケンス番号をエコーします。 ACK_DATAパラメータは、少なくとも1つのSEQ_DATAシーケンス番号を確認する必要がありますし、ACK_DATAパラメータにそれらのすべてを追加することにより、複数のSEQ_DATAシーケンス番号を確認してもよいです。
A HIP_DATA packet MAY contain both a SEQ_DATA and an ACK_DATA parameter. In this case, the ACK is being piggybacked on an outgoing HIP_DATA packet. In general, HIP_DATA packets carrying SEQ_DATA SHOULD be ACKed upon completion of the processing of the HIP_DATA packet. A host MAY choose to hold the HIP DATA packet carrying an ACK for a short period of time to allow for the possibility of piggybacking the ACK_DATA parameter, in a manner similar to TCP delayed acknowledgments.
HIP_DATAパケットはSEQ_DATAとACK_DATAパラメータの両方を含んでいてもよいです。この場合、ACKは、発信HIP_DATAパケットに背負わされています。一般的に、SEQ_DATAを運ぶHIP_DATAパケットがHIP_DATAパケットの処理の完了時にACKされるべきです。ホストが確認応答を遅らせるTCPと同様に、ACK_DATAパラメータをピギーバックの可能性を可能にするために時間の短い期間のためのACKを運ぶHIPデータパケットを保持するために選ぶかもしれません。
When a host has upper-layer protocol data to send, it either runs the HIP base exchange and sends the data over a SA, or sends the data directly using a HIP_DATA packet. Section 6 discusses when it is appropriate to use each method. This section discusses the case when the host chooses to use a HIP_DATA packet to send the upper-layer protocol data.
ホストは、送信するためにそれを上位層プロトコルデータを有するいずれかのHIP基本交換を実行し、SAを介してデータを送信する、または直接HIP_DATAパケットを用いてデータを送信するとき。各メソッドを使用することが適切である場合部6は論じています。このセクションでは、ホストは、上位層プロトコルのデータを送信するHIP_DATAパケットを使用することを選択した場合について説明します。
1. The host creates a HIP_DATA packet that contains a SEQ_DATA parameter. The host is free to choose any value for the SEQ_DATA sequence number in the first HIP_DATA packet it sends to a destination. After that first packet, the host MUST choose the value of the SEQ_DATA sequence number in subsequent HIP_DATA packets to the same destination so that no SEQ_DATA sequence number is reused before the receiver has closed the processing window for the previous packet using the same SEQ_DATA sequence number. Practically, giving the values of the retransmission timers used with HIP_DATA packets, this means that hosts must wait the maximum likely lifetime of the packet before reusing a given SEQ_DATA sequence number towards a given destination. However, it is not required for the node to know the maximum packet lifetime. Rather, it is assumed that the requirement can be met by maintaining the value as a simple, 32-bit, "wrap-around" counter, incremented each time a packet is sent. It is an implementation choice whether to maintain a single counter for the node or multiple counters (one for each <source, destination> HIT pair).
1.ホストはSEQ_DATAパラメータが含まれているHIP_DATAパケットを作成します。ホストは、宛先に送信する最初のHIP_DATAパケットでSEQ_DATAシーケンス番号の任意の値を自由に選択することができます。何SEQ_DATAシーケンス番号が再使用されないように、受信機は、同じSEQ_DATAシーケンス番号を使用して、以前のパケットに対する処理ウィンドウを閉じた前にその最初のパケット後、ホストは、同じ宛先への後続HIP_DATAパケット内SEQ_DATAシーケンス番号の値を選択する必要があります。実際に、HIP_DATAパケットで使用される再送信タイマーの値を与え、これは、ホストが特定の宛先に向けて与えられたSEQ_DATAシーケンス番号を再利用する前にパケットの最大可能性の高い寿命を待たなければならないことを意味します。しかし、最大のパケット生存期間を知るために、ノードは必要ありません。むしろ、それは要件は、単純な、32ビット、「ラップアラウンド」カウンタとして値を維持することによって満たすことができると仮定され、パケットが送信されるたびにインクリメント。ノードまたは複数のカウンタ（各<ソース、宛先> HITペアに対して1つ）のために単一のカウンタを維持するかどうかの実装上の選択です。
2. The host creates the PAYLOAD_MIC parameter. The MIC is a hash calculated over the whole PAYLOAD that the Next Header field of the PAYLOAD_MIC parameter indicates. If there are multiple Next Header types that the host wants to protect, it SHOULD create separate PAYLOAD_MIC parameters for each of these. The receiver MUST validate all these MICs as described in Section 5.3.1. For calculating the MIC, the host MUST use the same hash algorithm as the one that has been used for generating the host's HIT as defined in Section 3.2. of [RFC5201].
2.ホストがPAYLOAD_MICパラメータを作成します。 MICはPAYLOAD_MICパラメータの次ヘッダフィールドが示す全体PAYLOADにわたって計算されたハッシュです。ホストが保護したい複数の次ヘッダタイプがある場合、それは、これらのそれぞれに別々のPAYLOAD_MICパラメータを作成する必要があります。 5.3.1項で説明したように、受信機は、これらすべてのMICを検証する必要があります。 MICを計算するために、ホストは、3.2節で定義されているホストのHITを生成するために使用されているものと同じハッシュアルゴリズムを使用しなければなりません。 [RFC5201]の。
3. The host creates the HIP_SIGNATURE parameter. The signature is calculated over the whole HIP envelope, excluding any parameters after the HIP_SIGNATURE, as defined in Section 5.2.11. of [RFC5201]. The receiver MUST validate this signature. It MAY use either the HI in the packet or the HI acquired by some other means.
3.ホストはHIP_SIGNATUREパラメータを作成します。セクション5.2.11で定義されるように署名は、HIP_SIGNATURE後の任意のパラメータを除く、全HIPエンベロープにわたって計算されます。 [RFC5201]の。受信機は、この署名を検証しなければなりません。これは、パケット内のHIまたはいくつかの他の手段によって取得HIいずれかを使用することができます。
4. The host sends the created HIP_DATA packet and starts a DATA timer. The default value for the timer is 3 seconds. If multiple HIP DATA packets are outstanding, multiple timers are in effect.
4.ホストが作成したHIP_DATAパケットを送信し、データタイマを開始します。タイマーのデフォルト値は3秒です。複数のHIPデータパケットが傑出している場合は、複数のタイマが有効になります。
5. If the DATA timer expires, the HIP_DATA packet is resent. The HIP DATA packet can be resent DATA_RETRY_MAX times. The DATA timer MUST be exponentially backed off for subsequent retransmissions. If no acknowledgment is received from the peer after DATA_RETRY_MAX times, the delivery of the HIP_DATA packet is considered unsuccessful and the application is notified about the error. The DATA timer is canceled upon receiving an ACK from the peer that acknowledges receipt of the HIP_DATA packet. The default value for DATA_RETRY_MAX SHOULD be 5 retries, but it MAY be changed through local policy.
5.データタイマが満了した場合は、HIP_DATAパケットが再送されます。 HIPデータパケットはDATA_RETRY_MAX時間を再送することができます。データタイマは、指数関数的に、その後の再送信のためにオフにバックアップする必要があります。確認応答がDATA_RETRY_MAX時間後にピアから受信されない場合、HIP_DATAパケットの配信が失敗したとみなされ、アプリケーションがエラーを通知されます。データタイマはHIP_DATAパケットの受信を確認するピアからのACKを受信すると解除されます。 DATA_RETRY_MAXのデフォルト値は5回のリトライする必要がありますが、それはローカルポリシーによって変更することがあります。
A host receiving a HIP_DATA packet makes a decision whether or not to process the packet. If the host, following its local policy, suspects that this packet could be part of a DoS attack. The host MAY respond with an R1 packet to the HIP_DATA packet, if the packet contained SEQ_DATA and PAYLOAD_MIC parameters, in order to indicate that HIP base exchange MUST be completed before accepting payload packets from the originator of the HIP_DATA packet.
HIP_DATAパケットを受信したホストは、パケットを処理するかどうかを決定します。ホスト場合は、そのローカルポリシー以下、このパケットは、DoS攻撃の一部とすることができることを疑います。ホストは、HIP基本交換を示すためにHIP_DATAパケットの発信元からのペイロード・パケットを受け入れる前に完了しなければならない、パケットがSEQ_DATAとPAYLOAD_MICパラメータが含まれている場合、HIP_DATAパケットにR1パケットで応答することができます。
From RFC 5201 (Section 4.1):
RFC 5201（セクション4.1）から：
The HIP base exchange serves to manage the establishment of state between an Initiator and a Responder. The first packet, I1, initiates the exchange, and the last three packets, R1, I2, and R2, constitute an authenticated Diffie-Hellman [DIF76] key exchange for session key generation.
HIP基本交換は、イニシエータとレスポンダとの間の状態の確立を管理するのに役立ちます。最初のパケット、I1は、交換を開始し、最後の3つのパケット、R1、I2、及びR2は、認証されたディフィー・ヘルマンセッション鍵生成用【DIF76]キー交換を構成します。
If the host chooses to respond to the HIP DATA with an R1 packet, it creates a new R1 or selects a precomputed R1 according to the format described in [RFC5201], Section 5.3.2. The host SHOULD drop the received data packet if it responded with an R1 packet to the HIP_DATA packet. The sender of HIP_DATA packet is responsible for retransmission of the upper-layer protocol data after successful completion of the HIP base exchange.
ホストは、R1パケットでHIPデータに応答することを選択した場合、それは新しいR1を作成するか、[RFC5201]に記載のフォーマット、第5.3.2節に従って事前計算R1を選択します。それはHIP_DATAパケットにR1パケットで応答した場合、ホストは、受信したデータパケットを廃棄すべきです。 HIP_DATAパケットの送信者がHIP基本交換が正常に完了した後、上位層プロトコルデータの再送信を担当します。
If the host, following its local policy, decides to process the incoming HIP_DATA packet, it processes the packet according to the following rules:
ホストは、そのローカルポリシー以下、入ってくるHIP_DATAパケットを処理することを決定した場合、それは次の規則に従ってパケットを処理します。
1. If the HIP_DATA packet contains a SEQ_DATA parameter and no ACK_DATA parameter, the HIP_DATA packet is processed and replied to as described in Section 5.3.1.
1. HIP_DATAパケットがSEQ_DATAパラメータなしACK_DATAパラメータが含まれている場合は、HIP_DATAパケットが処理され、5.3.1項で説明したように答えています。
2. If the HIP_DATA packet contains an ACK_DATA parameter and no SEQ_DATA parameter, the HIP_DATA packet is processed as described in Section 5.3.2.
2. HIP_DATAパケットがACK_DATAパラメータなしSEQ_DATAパラメータが含まれている場合は、セクション5.3.2で説明したように、HIP_DATAパケットが処理されます。
3. If the HIP_DATA packet contains both a SEQ_DATA parameter and an ACK_DATA parameter, the HIP_DATA packet is processed first as described in Section 5.3.2, and then the rest of the HIP_DATA packet is processed and replied to as described in Section 5.3.1.
HIP_DATAパケットがSEQ_DATAパラメータとACK_DATAパラメータの両方を含む場合3、第5.3.2節に記載したようにHIP_DATAパケットが最初に処理され、その後HIP_DATAパケットの残りの部分が処理され、セクション5.3.1に記載したように返信。
The following steps define the conceptual processing rules for handling a SEQ_DATA parameter in a received HIP_DATA packet.
次のステップは、受信したHIP_DATAパケットにSEQ_DATAパラメータを処理するための概念的な処理規則を定義します。
The system MUST verify the SIGNATURE in the HIP_DATA packet. If the verification fails, the packet SHOULD be dropped and an error message logged.
システムはHIP_DATAパケット内の署名を検証しなければなりません。検証が失敗した場合、パケットは廃棄されるべきであるとのエラーメッセージが記録されます。
If the value in the received SEQ_DATA and the MIC value in the received PAYLOAD_MIC correspond to a HIP_DATA packet that has recently been processed, the packet is treated as a retransmission. It is recommended that a host cache HIP_DATA packets with ACKs to avoid the cost of generating a new ACK packet to respond to a retransmitted HIP_DATA packet. The host MUST acknowledge, again, such (apparent) HIP_DATA packet retransmissions but SHOULD also consider rate-limiting such retransmission responses to guard against replay attacks.
受信SEQ_DATAと受信PAYLOAD_MICにおけるMIC値の値は、最近処理されたHIP_DATAパケットに対応する場合、パケットは再送として処理されます。 ACKを持つホストキャッシュHIP_DATAパケットが再送HIP_DATAパケットに対応するため、新たなACKパケットを生成するコストを避けるためにすることをお勧めします。ホストは、再び、そのような（見かけの）HIP_DATAパケットの再送信を認める必要がありますが、また、リプレイ攻撃から保護するためにレート制限などの再送応答を検討すべきです。
The system MUST verify the PAYLOAD_MIC by calculating the MIC over the PAYLOAD that the Next Header field indicates. For calculating the MIC, the host will use the same hash algorithm that has been used to generate the sender's HIT as defined in Section 3.2. of [RFC5201]. If the packet carried multiple PAYLOAD_MIC parameters, each of them are verified as described above. If one or more of the verifications fail, the packet SHOULD be dropped and an error message logged.
システムは、次ヘッダフィールドが示すPAYLOAD超えるMICを計算することによってPAYLOAD_MICを確認しなければなりません。 MICを計算するために、ホストは、3.2節で定義されている送信者のHITを生成するために使用されてきた同じハッシュアルゴリズムを使用します。 [RFC5201]の。パケットが複数PAYLOAD_MICパラメータを行う場合、上述のように、それらのそれぞれが検証されます。検証の一つ以上に障害が発生した場合、パケットは廃棄されるべきであるとのエラーメッセージが記録されます。
If a new SEQ parameter is being processed, the parameters in the HIP DATA packet are then processed.
新しい配列のパラメータが処理されている場合は、HIPデータパケット内のパラメータが処理されています。
A HIP_DATA packet with an ACK_DATA parameter is prepared and sent to the peer. This ACK_DATA parameter may be included in a separate HIP DATA packet or piggybacked in a HIP_DATA packet with a SEQ_DATA parameter. The ACK_DATA parameter MAY acknowledge more than one of the peer's HIP_DATA packets.
ACK_DATAパラメータとHIP_DATAパケットを調製し、ピアに送信されます。このACK_DATAパラメータは別個HIPデータパケットに含まれる又はSEQ_DATAパラメータとHIP_DATAパケットにピギーバックすることができます。 ACK_DATAパラメータは、ピアのHIP_DATAパケットを複数確認してもよいです。
The following steps define the conceptual processing rules for handling an ACK_DATA parameter in a received HIP_DATA packet.
次のステップは、受信したHIP_DATAパケット内ACK_DATAパラメータを処理するための概念的な処理規則を定義します。
The system MUST verify the SIGNATURE in the HIP_DATA packet. If the verification fails, the packet SHOULD be dropped and an error message logged.
システムはHIP_DATAパケット内の署名を検証しなければなりません。検証が失敗した場合、パケットは廃棄されるべきであるとのエラーメッセージが記録されます。
The sequence numbers reported in the ACK_DATA must match with a previously sent HIP_DATA packet containing SEQ_DATA that has not already been acknowledged. If no match is found or if the ACK_DATA does not acknowledge a new HIP_DATA packet, the packet either MUST be dropped if no SEQ_DATA parameter is present or the processing steps in Section 5.3.1 are followed.
ACK_DATAで報告されたシーケンス番号が既に確認されていないSEQ_DATAを含む以前に送信されHIP_DATAパケットと一致している必要があります。一致するものが見つからない場合、またはACK_DATAが新しいHIP_DATAパケットを認識していない場合は何もSEQ_DATAパラメータが存在しないか、5.3.1項の処理ステップが続いている場合、パケットはどちらか廃棄されなければならない場合。
The corresponding DATA timer is stopped so that the now acknowledged HIP_DATA packet is no longer retransmitted. If multiple HIP_DATA packets are newly acknowledged, multiple timers are stopped.
今HIP_DATAパケットはもはや再送さを認めないように対応するデータタイマが停止しています。複数HIP_DATAパケットが新たに確認される場合は、複数のタイマが停止されています。
HIP currently requires that the four-message base exchange is executed at the first encounter of hosts that have not communicated before. This may add additional RTTs (Round-Trip Times) to protocols based on a single message exchange. However, the four-message exchange is essential to preserve the DoS protection nature of the base exchange. The use of the HIP_DATA packet defined in this document reduces the initial overhead in the communications between two hosts. However, the HIP_DATA packet itself does not provide any protection against DoS attacks. Therefore, the HIP_DATA packet MUST only be used in environments whose policies provide protection against DoS attacks. For example, a HIP-based overlay may have policies in place to control which nodes can join the overlay. However, authorization of who is allowed to join the overlay is beyond the scope of this specification. Any particular node in the overlay may want to accept HIP_DATA packets from other nodes in the overlay, given that those other nodes were authorized to join the overlay. However, the same node will not accept HIP_DATA packets from random nodes that are not part of the overlay. Additionally, the HIP_DATA packet itself does not provide confidentiality for its payload. Therefore, the HIP_DATA packet MUST NOT be used in environments that do not provide an appropriate level of confidentiality (e.g., a HIP-based overlay MUST NOT send HIP_DATA packets unless the connections between overlay nodes are encrypted).
HIPは、現在四メッセージベースの交換が以前通信されていないホストの最初の遭遇で実行されることを必要とします。これは、単一のメッセージ交換に基づくプロトコルに追加のRTT（ラウンドトリップ時間）を追加することができます。しかし、4 - メッセージ交換は、塩基交換のDoSの保護性を維持するために不可欠です。この文書で定義されたHIP_DATAパケットの使用は、2つのホスト間の通信における初期のオーバーヘッドを低減します。しかし、HIP_DATAパケット自体がDoS攻撃に対する任意の保護を提供しません。したがって、HIP_DATAパケットはそのポリシーのDoS攻撃に対する保護を提供する環境で使用しなければなりません。例えば、HIPベースのオーバーレイは、ノードがオーバーレイに参加できるかを制御するための場所でポリシーを有することができます。しかし、オーバーレイへの参加を許可された者の承認は、この仕様の範囲を超えています。オーバーレイ内の任意の特定のノードは、それらの他のノードがオーバレイに参加することを許可されたことを考えると、オーバーレイ内の他のノードからHIP_DATAパケットを受け入れることもできます。しかし、同じノードは、オーバーレイの一部ではない、ランダムなノードからHIP_DATAパケットを受け入れません。また、HIP_DATAパケット自体がそのペイロードの機密性を提供していません。したがって、HIP_DATAパケットが機密性の適切なレベルを提供していない環境で使用してはいけません（オーバレイノード間の接続が暗号化されない限り、例えば、HIPベースのオーバーレイはHIP_DATAパケットを送ってはいけません）。
The type of data to be sent is also relevant to whether the use of a HIP_DATA packet is appropriate. HIP itself does not support fragmentation but relies on underlying IP-layer fragmentation. This may lead to reliability problems in the case where a message cannot be easily split over multiple HIP messages. Therefore, applications in environments where fragmentation could be an issue SHOULD NOT generate large HIP_DATA packets that may lead to fragmentation. The implementation SHOULD check the MTU of the link before sending the packet, and if the packet size is larger than MTU, it SHOULD signal to the upper-layer protocol if the packet results in an ICMP error message. Note that there are environments where fragmentation is not an issue. For example, in some HIP-based overlays, nodes can exchange HIP_DATA packets on top of TCP connections that provide transport-level fragmentation and, thus, avoid IP-level fragmentation.
送信されるデータのタイプもHIP_DATAパケットの使用が適切であるかどうかに関連しています。 HIP自体が断片化をサポートしますが、基本的なIP層の断片化に依存していません。このメッセージは、簡単に複数HIPメッセージに分割することができない場合には信頼性の問題につながる可能性があります。そのため、断片化が問題になる可能性が環境でのアプリケーションは、断片化につながる可能性が大HIP_DATAパケットを生成するべきではありません。実装は、パケットを送信する前にリンクのMTUを確認する必要があり、パケットサイズがMTUより大きい場合、パケットは、ICMPエラーメッセージになる場合には、上位層プロトコルに合図すべきです。断片化は問題ではない環境があることに注意してください。例えば、いくつかのHIPベースのオーバーレイでは、ノードは、このように、トランスポートレベルの断片化を提供し、TCP接続の上HIP_DATAパケットを交換することができ、IPレベルの断片化を回避します。
HIP currently requires that all messages excluding I1s but including HIP_DATA packets are digitally signed. This adds to the packet size and the processing capacity needed to send packets. However, in applications where security is not paramount, it is possible to use very short keys, thereby reducing resource consumption.
HIPは、現在I1sを除くが、HIP_DATAパケットを含む、すべてのメッセージがデジタル署名されていることが必要です。これは、パケットサイズ、パケットを送信するために必要な処理能力に追加されます。しかし、セキュリティが重要でないアプリケーションでは、それによって、リソースの消費を減らす、非常に短いキーを使用することが可能です。
HIP is designed to provide secure authentication of hosts. HIP also attempts to limit the exposure of the host to various denial-of-service and man-in-the-middle (MitM) attacks. However, HIP_DATA packet, which can be sent without running the HIP base exchange between hosts has a trade-off that it does not provide the denial-of-service protection or confidentiality protection that HIP generally provides. Thus, the host should consider always situations where it is appropriate to send or receive HIP_DATA packet. If the communication consists more than few round trips of data or the data is highly sensitive in nature the host SHOULD run the base exchange with the peer host.
HIPは、ホストの安全な認証を提供するように設計されています。 HIPは、様々なサービス拒否とMITM（中間者）攻撃に対する宿主の曝露を制限しようとします。しかし、ホスト間HIP基本交換を実行せずに送信することができるHIP_DATAパケットは、トレードオフがHIPは、一般的に提供することは、サービス拒否保護や機密保護を提供しないことを持っています。したがって、ホストは、常にHIP_DATAパケットを送信または受信することが適切である状況を考慮すべきです。通信は、データのいくつかの往復以上またはデータを構成されている場合、ホストがピア・ホストとの塩基交換を実行する必要があります自然の中で非常に敏感です。
HIP_DATA packet is designed to protect hosts from second preimage attacks allowing receiving host to be able to detect, if the message was tampered during the transport. This property is also know as "weak collision-resistance". If a host tries to generate a second preimage, it would need to generate it such that the last 8 octets match with the original message.
HIP_DATAパケットは、メッセージが輸送中に改ざんされた場合、受信ホストは、検出することができるように第二のプリイメージ攻撃からホストを保護するように設計されています。このプロパティは、また、「弱い衝突抵抗」として知られています。ホストが第二プレイメージを生成しようとすると、それは、このような最後の8つのオクテットは、元のメッセージと一致することを生成する必要があります。
When handling the PAYLOAD_MIC parameter in the receiving host, using the last 8 octets to identify the upper-layer protocol doesn't give any guarantee that the MIC would be correct; thus, an attacker could send packets where the next header and last 8 octets match the values carried by the PAYLOAD_MIC parameter. Therefore, it is always mandatory to verify the MIC value by calculating the hash over the payload.
MICが正しいであろうと、任意の保証を与えない上位層プロトコルを識別するために、最後の8つのオクテットを使用して、受信ホストでPAYLOAD_MICパラメータを扱う場合、したがって、攻撃者は次のヘッダと最後の8つのオクテットPAYLOAD_MICパラメータによって運ばれる値と一致するパケットを送信することができます。したがって、ペイロード上のハッシュを計算することによって、MIC値を確認するために、常に必須です。
This document updates the IANA registry for HIP packet types by introducing a new packet type for the HIP_DATA (Section 4) packet. This document updates the IANA registry for HIP parameter types by introducing new parameter values for the SEQ_DATA (Section 4.1), ACK_DATA (Section 4.2), PAYLOAD_MIC (Section 4.3), and TRANSACTION_ID (Section 4.4) parameters.
この文書では、HIP_DATA（第4節）パケットのための新しいパケットタイプを導入することにより、HIPパケットタイプのためのIANAレジストリを更新します。この文書は、SEQ_DATA（セクション4.1）、ACK_DATA（セクション4.2）、PAYLOAD_MIC（セクション4.3）、およびTRANSACTION_ID（セクション4.4）のパラメータのための新しいパラメータ値を導入することにより、HIPパラメータタイプのIANAレジストリを更新します。
Pekka Nikander was one of the original authors of the document. Also, in the usual IETF fashion, a large number of people have contributed to the actual text or ideas. The list of these people include Miika Komu, Tobias Heer, Ari Keranen, Samu Varjonen, Thomas Henderson, and Jukka Ylitalo. Our apologies to anyone whose name is missing.
ペッカNikanderは、ドキュメントの原作者の一つでした。また、通常のIETFの方法で、多くの人々は、実際のテキストやアイデアに貢献してきました。これらの人々のリストはMiikaこむ、トビアスHeerさん、アリKeranen、Samu Varjonen、トーマス・ヘンダーソン、およびユッカYlitaloが含まれます。名前欠けている誰にも私たちの謝罪。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]モスコウィッツ、R.、Nikander、P.、Jokela、P.、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、RFC 5201、2008年4月。
[PROTOCOL-NUMBERS] IANA, "Protocol Numbers", <http://www.iana.org>.
[PROTOCOL-NUMBERS] IANA、 "プロトコル番号"、<http://www.iana.org>。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202] Jokela、P.、モスコウィッツ、R.、およびP. Nikander、RFC 5202、2008年4月 "ホスト識別プロトコル（HIP）とカプセル化セキュリティペイロード（ESP）トランスポートフォーマットを使用します"。
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] Nikander、P.、ヘンダーソン、T.、フォークト、C.、およびJ. Arkko、 "ホストアイデンティティプロトコルとエンドホストモビリティとマルチホーミング"、RFC 5206、2008年4月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Jan Melen Ericsson Hirsalantie 11 Jorvas 02420 Finland
ジャンメレンエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Jan.Melen@ericsson.com
メールアドレス：Jan.Melen@ericsson.com