[要約] RFC 6078は、HIP基本交換を事前に行わず、認証済みの任意の上位層プロトコルメッセージを信頼性をもって運ぶHIP_DATAパケットを定義します。パケットの生成・受信手順に加え、SEQ_DATA、ACK_DATA、PAYLOAD_MIC、TRANSACTION_IDの各パラメーターを定めています。HIP_DATA自体はDoS攻撃への保護と機密性を提供しないため、利用は適切な保護ポリシーがある環境に限り、継続的または機密性が必要な通信には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)
RFC 6078 - ホスト識別プロトコル（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.
この文書では、DATAと呼ばれる新しいHost Identity Protocol（HIP）パケットタイプを定義します。HIP DATAパケットは、さまざまなオーバーレイネットワーク上で、認証済みの任意のプロトコルメッセージを信頼性をもって伝達するために使用します。
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.
この文書は、インターネットコミュニティ向けの実験的プロトコルを定義します。この文書はInternet Engineering Task Force（IETF）の成果であり、IETFコミュニティの合意を表しています。公開レビューを経て、Internet Engineering Steering Group（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.
この文書の現在の状態、公開された正誤票、およびフィードバックの送付方法については、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 and the persons identified as the document authors. All rights reserved.
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文書に関するIETF Trustの法的条項（http://trustee.ietf.org/license-info）が適用されます。これらの文書には、本書に関する権利と制限が記載されているため、注意して確認してください。本書から抽出したコードコンポーネントには、Trustの法的条項のセクション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）を確立し、そのSAを介して任意のプロトコルメッセージを交換できます。このセキュリティアソシエーションの確立には、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 DATAパケットを定義します。HIP_DATAパケットは、順序保証なし、重複なし、信頼性あり、認証済みのメッセージ単位の配送サービスという意味を持ちます。このパケットを使う場合のトレードオフ（オーバーヘッドは小さい一方、サービス拒否（DoS）攻撃への保護も弱いこと）と、使用に適した状況についても説明します。HIP_DATAパケットはEncapsulating Security Payload（ESP）トランスポートの代替を意図していません。ピア間で数個を超えるパケットを交換するために使用すべきではありません (SHOULD NOT)。継続的な通信、または機密性保護を要する通信では、ホストはESPセキュリティアソシエーションを設定するためにHIP基本交換を実行しなければなりません (MUST)。このサービスを利用する可能性のある上位層プロトコル向けAPIも、この文書の対象範囲外です。
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はMessage Authentication Code（MAC）と同じですが、秘密鍵を使わない点が異なります。MICはIntegrity Check Value（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ヘッダーにはNext Headerフィールドがあり、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]は、Next Header値が10進数59、すなわちIPv6-NoNxt [PROTOCOL-NUMBERS]（IPv6の「次のヘッダーなし」を表す値）の場合の処理だけを定義しています。この文書では、HIPヘッダーの後に別の拡張ヘッダーやデータが続くことを示す、10進数59以外のNext Header値の処理を説明します。
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.
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アドレスとともに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]は、データパケットを運ぶエンドツーエンドのホスト間IPsec ESPセキュリティアソシエーションをHIPで作成する方法を定義しています。ただし、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]は、UPDATEメッセージを使用してHIP 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 DATAパケットは、HIP基本交換を実行せずにリモートホストへプロトコルメッセージを伝達するために使用できます。セクション5で説明するとおり、HIP DATAパケットは信頼性のある方法で送信されます。HIP_DATAパケットのペイロードはHIPヘッダーの後に配置し、セクション4.3で定義するPAYLOAD_MICパラメーターで保護します。以下にHIP_DATAパケットを定義します（表記法については[RFC5201]のセクション2.2を参照してください）。
Header: Packet Type = 32 SRC HIT = Sender's HIT DST HIT = Receiver's HIT
Header: Packet Type = 32 SRC HIT = Sender's HIT DST HIT = Receiver's 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) 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で定義されています。このパラメーターは送信側のHost Identifierであり、HIP_DATAパケットの署名の計算と、受信した署名の検証に使用します。HOST_IDパラメーターは、帯域外の仕組みで受信側にすでに配布されている可能性があるため、省略できます (MAY)。対応するノードがHOST_IDを保持しているという確かな情報がホストにない場合は、パケットにHOST_IDを必ず含めなければなりません (MUST)。受信側がSIGNATUREを検証できない場合、パケットを破棄しなければなりません (MUST)。また、[RFC5201]のセクション5.2.16に記載されたAUTHENTICATION_FAILEDを示す適切なNOTIFYパケットを送信側へ送るべきです (SHOULD)。
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 DATAの後に続くペイロードの衝突耐性ハッシュが含まれます。PAYLOAD_MICはHIP DATAパケットの署名対象部分に含まれ、パケットとその後に続くペイロードの完全性を保護します。
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.
将来、任意の (MAY) 上位層ペイロードがHIPヘッダーの後に続くことがあります (MAY)。ヘッダー内のNext Headerフィールドは、HIPヘッダーの後に追加データがあるかどうかを示します。
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拡張ヘッダーの後に置き、そのMICだけをPAYLOAD_MICパラメーターとしてHIP拡張ヘッダー内に置く方式を採用しました。こうすることで、MICを利用した公開鍵署名によってデータの完全性を保護できます。PAYLOAD_MICパラメーターで保護するペイロードは、上位層プロトコル番号、ペイロードデータの8オクテット、およびデータに対して計算したハッシュ値（MIC）によって、該当する上位層プロトコルに対応付けられます。HIP_DATAパケットには、異なるNext Headerタイプごとに1つ以上のPAYLOAD_MICパラメーターを含めることができます (MAY)。MICの生成に使うハッシュアルゴリズムは、Host Identity Tagの生成に使うものと同じです [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メッセージで送る上位層プロトコルメッセージは、異なるトランザクションと対応付ける必要がある場合があります。そのため、DATAメッセージにはTRANSACTION_IDパラメーターを含めることもできます (MAY)。識別子の値は、ネットワークバイトオーダーの可変長ビット列であり、トランザクションごとに一意です。要求への応答では同じ識別子を使い、受信側が要求と応答を対応付けられるようにします。
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.
このパラメーターはcritical bitが設定されています。受信側がこのパラメーターをサポートしていない場合、パケットを破棄しなければなりません (MUST)。また、[RFC5201]のセクション5.2.16に記載されたUNSUPPORTED_CRITICAL_PARAMETER_TYPEを示す適切なNOTIFYパケットを送信側へ送るべきです (SHOULD)。
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.
このパラメーターはcritical bitが設定されています。受信側がこのパラメーターをサポートしていない場合、パケットを破棄しなければなりません (MUST)。また、[RFC5201]のセクション5.2.16に記載されたUNSUPPORTED_CRITICAL_PARAMETER_TYPEを示す適切なNOTIFYパケットを送信側へ送るべきです (SHOULD)。
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.
このパラメーターはcritical bitが設定されています。受信側がこのパラメーターをサポートしていない場合、パケットを破棄しなければなりません (MUST)。また、[RFC5201]のセクション5.2.16に記載されたUNSUPPORTED_CRITICAL_PARAMETER_TYPEを示す適切なNOTIFYパケットを送信側へ送るべきです (SHOULD)。
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パラメーターを生成するとき、それらのNext HeaderフィールドとPayload Dataフィールドが同一になる可能性は理論上あります。そのため、PAYLOAD_MICパラメーターは、対応するペイロードデータに結び付けられるよう、パケット内の拡張ヘッダーの出現順に並べなければなりません (MUST)。受信側ホストがそれでもペイロードを特定できない場合、パケットを破棄しなければなりません (MUST)。また、[RFC5201]のセクション5.2.16に記載されたINVALID_SYNTAXを示すNOTIFYパケットを送信側へ送るべきです (SHOULD)。
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
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パラメーターの少なくとも一方を含めなければなりません (MUST)。両方とも含まれていない場合、そのパケットは無効として破棄しなければなりません (MUST)。
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パラメーターを含めなければなりません (MUST)。含まれていない場合、そのパケットを破棄しなければなりません (MUST)。SEQ_DATAパラメーターがあることは、受信側がHIP_DATAパケットにACKを返さなければならないことを示します (MUST)。SEQ_DATAパラメーターを含まないHIP_DATAパケットは、以前のHIP_DATAパケットへのACKだけを表すため、ACKを返してはなりません (MUST NOT)。
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シーケンス番号を確認応答しなければなりません (MUST)。また、複数の番号をACK_DATAパラメーターにすべて追加することで、複数のSEQ_DATAシーケンス番号を確認応答してもかまいません (MAY)。
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パラメーターの両方を含めてもかまいません (MAY)。この場合、送信するHIP_DATAパケットにACKを便乗させています。一般に、SEQ_DATAを含むHIP_DATAパケットの処理が完了した時点でACKを返すべきです (SHOULD)。ホストは、TCPの遅延ACKと同様に、ACK_DATAパラメーターを便乗させる機会を得るため、ACKを含むHIP DATAパケットの送信を短時間保留してもかまいません (MAY)。
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シーケンス番号を再利用しないよう、番号を選ばなければなりません (MUST)。実際には、HIP_DATAパケットに使う再送タイマーの値を踏まえると、特定の宛先に同じ番号を再利用する前に、パケットが存続しうる最長の時間だけ待つことになります。ただし、ノードが最大パケット寿命を知る必要はありません。パケット送信ごとに値を増やす単純な32ビットの循環カウンターを維持すれば、この要件を満たせると想定しています。ノード全体で1つのカウンターを維持するか、各<source, destination> 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パラメーターのNext Headerフィールドが示すPAYLOAD全体に対して計算するハッシュです。保護対象にするNext Headerタイプが複数ある場合、それぞれに個別のPAYLOAD_MICパラメーターを作成すべきです (SHOULD)。受信側は、セクション5.3.1の説明に従って、これらすべてのMICを検証しなければなりません (MUST)。MICの計算には、[RFC5201]のセクション3.2で定義されているとおり、ホストのHIT生成に使ったものと同じハッシュアルゴリズムを使用しなければなりません (MUST)。
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パラメーターを作成します。署名は、[RFC5201]のセクション5.2.11で定義されているとおり、HIP_SIGNATUREより後のパラメーターを除いたHIPエンベロープ全体に対して計算します。受信側はこの署名を検証しなければなりません (MUST)。パケット内のHIを使っても、別の手段で取得したHIを使ってもかまいません (MAY)。
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パケットを送信し、DATAタイマーを開始します。タイマーの既定値は3秒です。複数のHIP DATAパケットが未処理の場合、それぞれにタイマーが設定されます。
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. DATAタイマーが満了すると、HIP_DATAパケットを再送します。HIP DATAパケットはDATA_RETRY_MAX回まで再送できます。その後の再送では、DATAタイマーを指数関数的に延長しなければなりません (MUST)。DATA_RETRY_MAX回再送してもピアからACKを受信しない場合、HIP_DATAパケットの配送は失敗とみなし、アプリケーションにエラーを通知します。HIP_DATAパケットの受信を確認するACKをピアから受信すると、DATAタイマーを取り消します。DATA_RETRY_MAXの既定値は5回の再試行を推奨します (SHOULD) が、ローカルポリシーで変更してもかまいません (MAY)。
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攻撃の一部かもしれないと疑う場合、パケットにSEQ_DATAおよびPAYLOAD_MICパラメーターが含まれていれば、R1パケットで応答してもかまいません (MAY)。これは、HIP_DATAパケットの送信元からのペイロードパケットを受け入れる前にHIP基本交換を完了しなければならないことを示すためです (MUST)。
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基本交換は、InitiatorとResponderの間で状態を確立するためのものです。最初のパケットI1が交換を開始し、最後の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パケットでHIP DATAに応答する場合、[RFC5201]のセクション5.3.2に記載された形式に従って新しいR1を作成するか、事前計算済みのR1を選択します。HIP_DATAパケットにR1で応答した場合、受信したデータパケットを破棄すべきです (SHOULD)。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パラメーターが含まれていない場合、セクション5.3.1の説明に従ってHIP_DATAパケットを処理し、応答します。
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.
3. HIP_DATAパケットにSEQ_DATAパラメーターとACK_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パケット内のSIGNATUREを検証しなければなりません (MUST)。検証に失敗した場合、パケットを破棄し、エラーメッセージを記録すべきです (SHOULD)。
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パケットにも再度ACKを返さなければなりません (MUST)。一方、リプレイ攻撃への対策として、再送への応答をレート制限することも検討すべきです (SHOULD)。
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.
システムは、Next Headerフィールドが示すPAYLOADに対してMICを計算し、PAYLOAD_MICを検証しなければなりません (MUST)。MICの計算には、[RFC5201]のセクション3.2で定義されているとおり、送信側のHITの生成に使ったものと同じハッシュアルゴリズムを使用します。パケットに複数のPAYLOAD_MICパラメーターが含まれている場合は、上述のとおりそれぞれを検証します。検証に1つでも失敗した場合、パケットを破棄し、エラーメッセージを記録すべきです (SHOULD)。
If a new SEQ parameter is being processed, the parameters in the HIP DATA packet are then processed.
新しいSEQパラメーターを処理する場合は、続いてHIP DATAパケット内のパラメーターを処理します。
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 DATAパケットに含めるか、SEQ_DATAパラメーターを含むHIP_DATAパケットに便乗させることができます。ACK_DATAパラメーターは、ピアの複数のHIP_DATAパケットを確認応答してもかまいません (MAY)。
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パケット内のSIGNATUREを検証しなければなりません (MUST)。検証に失敗した場合、パケットを破棄し、エラーメッセージを記録すべきです (SHOULD)。
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パラメーターがなければパケットを破棄しなければなりません (MUST)。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.
対応するDATAタイマーを停止し、確認応答済みの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（往復時間）が増える場合があります。一方、この4メッセージ交換は、基本交換によるDoS保護を維持するうえで不可欠です。この文書で定義するHIP_DATAパケットを使うと、2台のホスト間の通信開始時のオーバーヘッドを減らせます。ただし、HIP_DATAパケット自体はDoS攻撃を防御しません。したがって、ポリシーによってDoS攻撃から保護される環境に限ってHIP_DATAパケットを使用しなければなりません (MUST)。たとえば、HIPベースのオーバーレイでは、参加できるノードを制御するポリシーを設けることがあります。ただし、誰がオーバーレイへの参加を許可されるかを認可する仕組みは、この仕様の対象範囲外です。オーバーレイ内のノードは、参加を認可された他のノードからのHIP_DATAパケットを受け入れることがあります。一方、同じノードでも、オーバーレイに属さない不特定のノードからのHIP_DATAパケットは受け入れません。さらに、HIP_DATAパケット自体はペイロードの機密性を保護しません。したがって、適切な水準の機密性を提供しない環境ではHIP_DATAパケットを使用してはなりません (MUST NOT)。たとえば、HIPベースのオーバーレイでは、オーバーレイノード間の接続が暗号化されていない限り、HIP_DATAパケットを送信してはなりません (MUST NOT)。
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パケットをアプリケーションが生成すべきではありません (SHOULD NOT)。実装はパケット送信前にリンクのMTUを確認すべきです (SHOULD)。パケットサイズがMTUを超え、その結果ICMPエラーメッセージが発生した場合は、上位層プロトコルに通知すべきです (SHOULD)。フラグメンテーションが問題にならない環境もあります。たとえば、一部のHIPベースのオーバーレイでは、ノードがTCP接続上でHIP_DATAパケットを交換できます。TCP接続はトランスポート層でフラグメンテーションを提供するため、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は、ホストを安全に認証するよう設計されています。また、さまざまなサービス拒否攻撃や中間者（MitM）攻撃にホストがさらされる危険を抑えようとします。一方、ホスト間でHIP基本交換を実行せずに送れるHIP_DATAパケットには、HIPが通常提供するDoS攻撃への保護や機密性保護がないというトレードオフがあります。そのため、ホストはHIP_DATAパケットの送受信が適切な状況かどうかを常に検討する必要があります。通信が数回を超えるラウンドトリップに及ぶ場合、またはデータの機密性が高い場合、ホストはピアと基本交換を実行すべきです (SHOULD)。
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.
受信側ホストがPAYLOAD_MICパラメーターを扱う際、末尾の8オクテットを使って上位層プロトコルを特定しても、MICが正しい保証にはなりません。そのため、攻撃者はNext Headerと末尾の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.
Pekka Nikanderは、本書の初期の執筆者の1人です。また、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., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[PROTOCOL-NUMBERS] IANA, "Protocol Numbers", <http://www.iana.org>.
[PROTOCOL-NUMBERS] IANA, "Protocol Numbers", <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., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[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., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
EMail: Gonzalo.Camarillo@ericsson.com
Jan Melen Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jan Melen Ericsson Hirsalantie 11 Jorvas 02420 Finland
EMail: Jan.Melen@ericsson.com