[要約] 要約：RFC 6078は、Host Identity Protocol (HIP)を使用して上位層プロトコルのシグナリングを即座に運搬するための仕組みであるHICCUPSについて説明しています。目的：HICCUPSは、HIPを使用して上位層プロトコルのシグナリングを高速かつ信頼性のある方法で運搬することを目的としています。
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)
ホストIDプロトコル（HIP）即時キャリッジと上層層プロトコルシグナル伝達（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.
このドキュメントでは、データと呼ばれる新しいホストIDプロトコル（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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6078.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
2人のホストは、HIP [RFC5201]を使用して、セキュリティ協会をめぐる任意のプロトコルメッセージを交換するために、セキュリティ協会（SA）を確立することができます。このようなセキュリティ協会の設立には、股関節ベース交換と呼ばれる四方の握手が含まれます。ホスト間で通信を処理するとき、HIPはモビリティ、マルチホミング、セキュリティ、およびNATトラバーサルをサポートします。一部のアプリケーションは、通信にこれらの機能を必要としますが、それらの通信が開始される前にセキュリティ協会の確立（つまり、ヒップベース交換）の確立に関連するオーバーヘッドを受け入れることはできません。
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_DATAパケットには、次のセマンティクスがあります。また、このパケットの使用に伴うトレードオフ（つまり、オーバーヘッドが少なく、サービス拒否（DOS）保護も少ない）と、このパケットを使用するのが適切な状況についても説明します。HIP_DATAパケットは、セキュリティペイロード（ESP）輸送のカプセル化の代替品ではありません。代わりに、ピア間でいくつかのパケットを交換するために使用しないでください。継続的な通信が必要な場合、または機密保護を必要とする通信が必要な場合、ホストはESPセキュリティ協会を設定するためにヒップベース交換を実行する必要があります。さらに、このサービスを使用する可能性のある高レベルのプロトコルへの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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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）は、整合性保護されているメッセージで計算された衝突耐性ハッシュ合計です。マイクは秘密のキーを使用していないため、送信中に改ざんされていないことを確認するための追加手段が必要です。基本的に、マイクはメッセージ認証コード（MAC）と同じで、マイクはシークレットキーを使用しないという区別があります。マイクは、しばしば整合性チェック値（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としてエンコードされます。さらに、股関節ヘッダーには次のヘッダーフィールドがあり、他の任意のパケットを股関節パケット内で運ぶことができます。
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.
股関節パケット形式は、固定ヘッダーで構成され、その後に可変数のパラメーターが続きます。パラメーター形式は、セクション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 'No Next Header'値のみを定義します。このドキュメントでは、小数59以外の次のヘッダー値の処理について説明します。これは、股関節ヘッダーに続いてより多くの拡張ヘッダーおよび/またはデータがあることを示しています。
The HIP parameter format is defined in Section 5.2.1 of [RFC5201], and copied below.
股関節パラメーター形式は、[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ベース交換は、4メッセージ認証と主要な交換プロトコルであり、コミュニケーションパーティで共有された相互に認証されたキーイング資料を作成します。これらのキーイング資料は、関連する公開キーおよびIPアドレスとともに、股関節セキュリティ協会（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]は、データパケットを運ぶために使用されるエンドツーエンドのIPSEC ESPセキュリティアソシエーションを作成するためにHIPを使用する方法を定義します。ただし、股関節のベース交換は決してIPSecに縛られていないことを理解することが重要です。IPSEC ESPを使用してデータトラフィックフォームをベースラインに単なる運搬し、初期の股関節実装間の相互運用性を保証します。
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つの股関節対応ホストの間に股関節SAが発生すると、ヒップコントロールメッセージをさらに交換できます。通常、更新メッセージが使用されます。たとえば、HIPモビリティとマルチホーム仕様[RFC5206]は、更新メッセージを使用して、股関節SAに関連付けられたIPアドレスのセットを変更する方法を定義します。
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ベース交換を実行せずにプロトコルメッセージをリモートホストに伝えることができます。セクション5で説明したように、HIPデータパケットは確実に送信されます。HIP_DATAパケットのペイロードは、股関節ヘッダーの後に配置され、セクション4.3で定義されているPayload_Micパラメーターによって保護されます。以下は、HIP_DATAパケットの定義です（[RFC5201]、セクション2.2の表記の定義を参照）：
Header: Packet Type = 32 SRC HIT = Sender's HIT DST HIT = Receiver's HIT
ヘッダー：パケットタイプ= 32 SRCヒット=送信者のヒットDSTヒット=受信者のヒット
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）payload）
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）payload）
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を含める必要があります。受信機が署名を確認できない場合、パケットをドロップし、適切な通知パケットを送信者に送信する必要があります。
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パケットによって運ばれるペイロードのマイクが含まれています。Payload_micには、股関節データに続くペイロードの衝突耐性ハッシュが含まれています。Payload_micは、股関節データパケットの署名された部分に含まれており、パケットとその後のペイロードの整合性保護を提供します。
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.
将来的には、オプションの上層層ペイロードが股関節ヘッダーに従うことがあります。ヘッダーの次のヘッダーフィールドは、股関節ヘッダーに続いて追加のデータがあるかどうかを示します。
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].
股関節拡張ヘッダーの後にペイロードを配置し、ペイロード_MICパラメーターでペイロードのマイクを股関節拡張ヘッダーに配置することを選択しました。Payload_Micパラメーターによって保護されているペイロードは、上層層プロトコル数、8オクテットのペイロードデータを保存し、データ上のハッシュサム（MIC）を計算することにより、適切な上層層プロトコルにリンクされています。HIP_DATAパケットには、それぞれが異なる次のヘッダータイプにバインドされた1つ以上のPayload_micパラメーターが含まれている場合があります。マイクを生成するために使用されるハッシュアルゴリズムは、ホストIDタグ[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.
オーバーレイネットワーク制御トラフィックなどの上層層プロトコルメッセージは、股関節データメッセージで送信された場合、異なるトランザクションと一致する必要がある場合があります。この目的のために、データメッセージには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.
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.
このパラメーターには、クリティカルビットセットがあります。受信機によってサポートされていない場合は、パケットをドロップし、適切な通知パケットを送信者に送信する必要があります。
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.
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.
このパラメーターには、クリティカルビットセットがあります。受信機によってサポートされていない場合は、パケットをドロップし、適切な通知パケットを送信者に送信する必要があります。
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.
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.
このパラメーターには、クリティカルビットセットがあります。受信機によってサポートされていない場合は、パケットをドロップし、適切な通知パケットを送信者に送信する必要があります。
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 SHOULD send a NOTIFY packet to the sender indicating INVALID_SYNTAX as described in [RFC5201], Section 5.2.16.
単一のパケットで運ばれる複数のpayload_micパラメーターを生成する場合、次のヘッダーとペイロードデータフィールドが同じであるという理論的な可能性があります。したがって、payload_micパラメーターは、ペイロード_micsをバインドしてペイロードデータを修正できるように、パケット内の拡張ヘッダーの自然な順序に従う必要があります。受信ホストがまだペイロードを識別できない場合、パケットをドロップする必要があり、[RFC5201]、セクション5.2.16に記載されているように、Invalid_Syntaxを示す送信者に通知パケットを送信する必要があります。
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パケットには、少なくとも1つの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パケットには、1つ以上のpayload_micパラメーターを含める必要があります。それ以外の場合、パケットをドロップする必要があります。SEQ_DATAパラメーターの存在は、受信者がHIP_DATAパケットをACKしなければならないことを示しています。SEQ_DATAパラメーターを含まないHIP_DATAパケットは、単に以前のHIP_DATAパケットのACKであり、ACKEDではありません。
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パケットの処理の完了時にアクセスする必要があります。ホストは、TCP遅延確認と同様の方法で、ACK_DATAパラメーターをピギーバックする可能性を可能にするために、短期間ACKを運ぶ股関節データパケットを保持することを選択できます。
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.
ホストが上層層プロトコルデータを送信すると、股関節ベース交換を実行して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シーケンス番号の任意の値を無料で選択できます。その最初のパケットの後、ホストは同じ宛先に後続のhip_DataパケットのSEQ_DATAシーケンス番号の値を選択する必要があります。これにより、レシーバーが同じSQ_DATAシーケンス番号を使用して前のパケットの処理ウィンドウを閉じる前にSEQ_DATAシーケンス番号が再利用されないようにする必要があります。。実際には、HIP_DATAパケットで使用された再送信タイマーの値を与えると、これは、特定のSEQ_DATAシーケンス番号を特定の宛先に再利用する前に、ホストがパケットの最大寿命を待つ必要があることを意味します。ただし、ノードが最大パケット寿命を知る必要はありません。むしろ、パケットが送信されるたびに増加する単純な32ビットの「ラップアラウンド」カウンターとして価値を維持することにより、要件を満たすことができると想定されています。これは、ノードまたは複数のカウンターの単一のカウンターを維持するかどうか（各<ソース、宛先>ヒットペア）かどうかにかかわらず、実装の選択です。
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パラメーターを作成する必要があります。受信機は、セクション5.3.1で説明されているように、これらすべてのマイクを検証する必要があります。マイクを計算するには、ホストはセクション3.2で定義されているようにホストのヒットを生成するために使用されたものと同じハッシュアルゴリズムを使用する必要があります。[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の後の任意のパラメーターを除く、股関節エンベロープ全体にわたって計算されます。[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秒です。複数の股関節データパケットが傑出している場合、複数のタイマーが有効です。
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パケットがresします。HIPデータパケットは、data_retry_max Timesをresすることができます。データタイマーは、その後の再送信のために指数関数的にバックアウトする必要があります。data_retry_maxタイムの後にピアから謝辞が受け取られていない場合、hip_dataパケットの配信は失敗し、アプリケーションにエラーについて通知されます。データタイマーは、HIP_DATAパケットの受領を認めるピアからACKを受信するとキャンセルされます。data_retry_maxのデフォルト値は5 retriesである必要がありますが、ローカルポリシーによって変更される場合があります。
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_DATAパケットのオリジネーターからペイロードパケットを受け入れる前にhipベース交換を完了する必要があることを示すために、パケットに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.
ヒップベース交換は、イニシエーターとレスポンダーの間の国家の確立を管理するのに役立ちます。最初のパケットであるI1がExchangeを開始し、最後の3つのパケットであるR1、I2、およびR2は、セッションキー生成の認証されたDiffie-Hellman [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パケットで股関節データに応答することを選択した場合、[RFC5201]、セクション5.3.2で説明されている形式に従って、新しいR1を作成するか、事前計算された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パラメーターが含まれていない場合、hip_Dataパケットはセクション5.3.2で説明されているように処理されます。
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.
3. HIP_DATAパケットにSEQ_DATAパラメーターとACK_DATAパラメーターの両方が含まれている場合、HIP_DATAパケットはセクション5.3.2で説明されているように最初に処理され、次に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パケットに対応する場合、パケットは再送信として扱われます。ホストキャッシュHIP_DATAパケットをACKを使用して、新しいACKパケットを生成して再送信されたHIP_DATAパケットに応答するコストを回避することをお勧めします。ホストは、再び、そのような（明らかな）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を検証する必要があります。MICを計算するために、ホストはセクション3.2で定義されているように送信者のヒットを生成するために使用された同じハッシュアルゴリズムを使用します。[RFC5201]。パケットが複数のPayload_MICパラメーターを搭載した場合、それらのそれぞれが上記のように検証されます。1つまたは複数の検証が失敗した場合、パケットをドロップし、エラーメッセージを記録する必要があります。
If a new SEQ parameter is being processed, the parameters in the HIP DATA packet are then processed.
新しいSEQパラメーターが処理されている場合、股関節データパケットのパラメーターが処理されます。
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パラメーターは、SEQ_DATAパラメーターを搭載したHIP_DATAパケットで個別のHIPデータパケットに含めるか、ピギーバックされている場合があります。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では、現在、4メッセージの基本交換が、以前に通信したことのないホストの最初の出会いで実行されることを要求しています。これにより、単一のメッセージ交換に基づいてプロトコルに追加のRTT（往復時間）が追加される場合があります。ただし、基本交換のDOS保護の性質を維持するためには、4メッセージの交換が不可欠です。このドキュメントで定義されているHIP_DATAパケットの使用は、2つのホスト間の通信の初期オーバーヘッドを減らします。ただし、HIP_DATAパケット自体は、DOS攻撃に対する保護を提供しません。したがって、HIP_DATAパケットは、ポリシーがDOS攻撃に対する保護を提供する環境でのみ使用する必要があります。たとえば、股関節ベースのオーバーレイには、どのノードがオーバーレイに結合できるかを制御するためのポリシーがあります。ただし、オーバーレイへの参加を許可されている人の許可は、この仕様の範囲を超えています。オーバーレイ内の特定のノードは、他のノードがオーバーレイに参加することが許可されていることを考えると、オーバーレイ内の他のノードから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パケットの使用が適切かどうかにも関連しています。股関節自体は断片化をサポートしていませんが、基礎となるIP層の断片化に依存しています。これにより、複数の股関節メッセージでメッセージを簡単に分割できない場合の信頼性の問題につながる可能性があります。したがって、断片化が問題になる可能性のある環境でのアプリケーションは、フラグメンテーションにつながる可能性のある大きな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では、i1を除くすべてのメッセージが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_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パケットは、輸送中にメッセージが改ざんされた場合、受信ホストが検出できる2回目のプリイメージ攻撃からホストを保護するように設計されています。このプロパティは、「衝突抵抗が弱い」とも知られています。ホストが2回目のプリイメージを生成しようとする場合、最後の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.
受信ホストでPayload_MICパラメーターを処理するとき、最後の8オクテットを使用して上層層プロトコルを識別することは、マイクが正しいという保証は与えられません。したがって、攻撃者は、次のヘッダーと最後の8オクテットがpayload_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.
Pekka Nikanderは、この文書の元の著者の一人でした。また、通常のIETFファッションでは、多くの人々が実際のテキストやアイデアに貢献しています。これらの人々のリストには、Miika Komu、Tobias Heer、Ari Keranen、Samu Varjonen、Thomas Henderson、Jukka Ylitaloが含まれます。名前が足りない人に謝罪します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P。、およびT. Henderson、「Host Identity Protocol」、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.、Moskowitz、R。、およびP. Nikander、「ホストIDプロトコル（HIP）を使用したセキュリティペイロード（ESP）輸送形式を使用して」、RFC 5202、2008年4月。
[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.、Henderson、T.、Vogt、C。、およびJ. Arkko、「ホストIDプロトコルによるエンドホストモビリティとマルチホミング」、RFC 5206、2008年4月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Jan Melen Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jan Melen Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Jan.Melen@ericsson.com