[要約] RFC 6261は、Host Identity Protocol (HIP)のための暗号化されたシグナリングトランスポートモードに関する技術仕様を定義しています。この文書の目的は、HIP通信のセキュリティを強化するために、シグナリングメッセージを暗号化する方法を提供することです。利用場面としては、インターネット上でのデバイス間通信の認証と暗号化を強化する場合に適用されます。関連するRFCには、HIPの基本プロトコルを定義するRFC 7401や、HIPのアーキテクチャを説明するRFC 4423などがあります。これらの文書と合わせて、RFC 6261はインターネットのセキュリティとプライバシーを向上させるための技術的枠組みを提供します。
Internet Engineering Task Force (IETF) A. Keranen
Request for Comments: 6261 Ericsson
Category: Experimental May 2011
ISSN: 2070-1721
Encrypted Signaling Transport Modes for the Host Identity Protocol
ホストIDプロトコルの暗号化されたシグナリング輸送モード
Abstract
概要
This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow them to be conveyed over encrypted connections initiated with the Host Identity Protocol.
このドキュメントでは、ホストIDプロトコル（HIP）シグナリングメッセージの2つのトランスポートモードを指定し、ホストIDプロトコルで開始された暗号化された接続を介して伝達できるようにします。
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/rfc6261.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6261で取得できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Transport Mode Negotiation . . . . . . . . . . . . . . . . . . 3
3.1. Mode Negotiation in the HIP Base Exchange . . . . . . . . 3
3.2. Mode Negotiation after the HIP Base Exchange . . . . . . . 5
3.3. Error Notifications . . . . . . . . . . . . . . . . . . . 5
4. HIP Messages on Encrypted Connections . . . . . . . . . . . . 5
4.1. ESP Mode . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. ESP-TCP Mode . . . . . . . . . . . . . . . . . . . . . . . 6
5. Recovering from Failed Encrypted Connections . . . . . . . . . 7
6. Host Mobility and Multihoming . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informational References . . . . . . . . . . . . . . . . . 10
Appendix A. Mobility and Multihoming Examples . . . . . . . . . . 11
Host Identity Protocol (HIP) [RFC5201] signaling messages can be exchanged over plain IP using the protocol number reserved for this purpose, or over UDP using the UDP port reserved for HIP NAT traversal [RFC5770]. When two hosts perform a HIP base exchange, they set up an encrypted connection between them for data traffic, but continue to use plain IP or UDP for HIP signaling messages.
ホストアイデンティティプロトコル（HIP）[RFC5201]シグナリングメッセージは、この目的のために予約されたプロトコル番号を使用して、またはHIP NAT Traversal [RFC5770]用に予約されたUDPポートを使用してUDPポートを使用してUDPを使用して交換できます。2人のホストが股関節ベース交換を実行すると、データトラフィックのためにそれらの間に暗号化された接続を設定しますが、股関節シグナリングメッセージにはプレーンIPまたはUDPを使用し続けます。
This document defines how the encrypted connection can be used also for HIP signaling messages. Two different modes are defined: HIP over Encapsulating Security Payload (ESP) and HIP over TCP. The benefit of sending HIP messages over ESP is that all signaling traffic (including HIP headers) will be encrypted. If HIP messages are sent over TCP (which in turn is transported over ESP), TCP can handle also message fragmentation where needed.
このドキュメントでは、暗号化された接続を股関節信号メッセージにも使用する方法を定義しています。2つの異なるモードが定義されています。セキュリティペイロード（ESP）のカプセル化上の股関節とTCP上の股関節。ESPを介して股関節メッセージを送信する利点は、すべての信号トラフィック（股関節ヘッダーを含む）が暗号化されることです。股関節メッセージがTCPを介して送信された場合（ESPを介して転送されます）、TCPは必要に応じてメッセージの断片化も処理できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This section defines how support for different HIP signaling message transport modes is indicated and how the use of different modes is negotiated.
このセクションでは、さまざまな股関節信号メッセージ輸送モードのサポートが示されている方法と、さまざまなモードの使用がどのようにネゴシエートされるかを定義します。
A HIP host implementing this specification SHOULD indicate the modes it supports, and is willing to use, in the base exchange. The HIP signaling message transport mode negotiation is similar to HIP NAT traversal mode negotiation: first the Responder lists the supported modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) in the R1 packet. The modes are listed in priority order, the more preferred mode(s) first. If the Initiator supports, and is willing to use, any of the modes proposed by the Responder, it selects one of the modes by adding a HIP_TRANSPORT_MODE parameter containing the selected mode to the I2 packet. Finally, if the Initiator selected one of the modes and the base exchange succeeds, hosts MUST use the selected mode for the following HIP signaling messages sent between them for the duration of the HIP association or until another mode is negotiated.
この仕様を実装する股関節ホストは、ベース交換でサポートするモードを示し、使用する意思があることを示している必要があります。HIPシグナル伝達メッセージトランスポートモードのネゴシエーションは、HIP NATトラバーサルモードのネゴシエーションに似ています。最初に、Responderは、R1パケットのhip_transport_modeパラメーター（図1を参照）のサポートされたモードをリストします。モードは優先順序でリストされ、より優先モードが最初にリストされます。イニシエーターがレスポンダーによって提案されているモードのいずれかをサポートし、使用することをいとわない場合、選択したモードをI2パケットに含むhip_transport_modeパラメーターを追加することにより、モードの1つを選択します。最後に、イニシエーターがモードの1つを選択し、ベース交換が成功した場合、ホストは、股関節関連の期間中または別のモードがネゴシエートされるまで、それらの間に送信される次の股関節シグナリングメッセージに対して選択されたモードを使用する必要があります。
If the Initiator cannot, or will not, use any of the modes proposed by the Responder, the Initiator SHOULD include an empty HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it supports this extension but will not use any of the proposed modes. Depending on local policy, the Responder MAY either abort the base exchange or continue HIP signaling without using an encrypted connection, if there was no HIP_TRANSPORT_MODE parameter in I2 or the parameter was empty. If the Initiator selects a mode that the Responder does not support (and hence was not included in R1), the Responder MUST abort the base exchange. If the base exchange is aborted due to (possibly lack of) HIP_TRANSPORT_PARAMETER, the Responder SHOULD send a NO_VALID_HIP_TRANSPORT_MODE notification (see Section 3.3) to the Initiator.
イニシエーターがレスポンダーによって提案されているモードのいずれかを使用できないか、そうでない場合、イニシエーターはi2パケットに空のhip_transport_modeパラメーターを含める必要があります。ローカルポリシーに応じて、レスポンダーは、I2にhip_transport_modeパラメーターがない場合、またはパラメーターが空であった場合、暗号化された接続を使用せずにベース交換を中止するか、暗号化された接続を使用せずに股関節信号を継続する場合があります。イニシエーターがレスポンダーがサポートしていない（したがってR1に含まれていない）モードを選択した場合、レスポンダーはベース交換を中止する必要があります。HIP_TRANSPORT_PARAMETERにより（おそらく不足している可能性のある）ベース交換が中止された場合、ResponderはNO_VALID_HIP_TRANSPORT_MODE通知（セクション3.3を参照）をイニシエーターに送信する必要があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 7680 Port transport layer port number (or zero if not used) Length length in octets, excluding Type, Length, and Padding Mode ID defines the proposed or selected transport mode(s)
タイプ7680ポートトランスポートレイヤーポート番号（または使用していない場合はゼロ）オクテットの長さの長さ、タイプ、長さ、およびパディングモードIDを除く提案または選択された輸送モードを定義します
The following HIP Transport Mode IDs are defined:
次の股関節輸送モードIDが定義されています。
ID name Value RESERVED 0 DEFAULT 1 ESP 2 ESP-TCP 3
ID名値予約済み0デフォルト1 ESP 2 ESP-TCP 3
Figure 1: Format of the HIP_TRANSPORT_MODE Parameter
図1：hip_transport_modeパラメーターの形式
The mode DEFAULT indicates that the same transport mode (e.g., plain IP or UDP) that was used for the base exchange should be used for subsequent HIP signaling messages. In the ESP mode, the messages are sent as such on the encrypted ESP connection; in the ESP-TCP mode, TCP is used within the ESP tunnel. If a mode that uses a transport layer connection within the ESP tunnel (e.g., ESP-TCP) is offered, the Port field MUST contain the local port number the host will use for the connection. If none of the modes utilize a transport layer protocol, the Port field SHOULD be set to zero when the parameter is sent and ignored when received. The Port and Mode ID fields are encoded as unsigned integers using network byte order.
モードのデフォルトは、基本交換に使用された同じトランスポートモード（プレーンIPまたはUDPなど）が、後続の股関節シグナリングメッセージに使用する必要があることを示しています。ESPモードでは、メッセージは暗号化されたESP接続でそのように送信されます。ESP-TCPモードでは、TCPがESPトンネル内で使用されます。ESPトンネル内の輸送層接続を使用するモード（ESP-TCPなど）が提供される場合、ポートフィールドにはホストが接続に使用するローカルポート番号を含める必要があります。モードがトランスポートレイヤープロトコルを使用していない場合、パラメーターが送信されて受信されたときに無視されると、ポートフィールドをゼロに設定する必要があります。ポートおよびモードIDフィールドは、ネットワークバイトの順序を使用して、署名のない整数としてエンコードされます。
The HIP_TRANSPORT_MODE parameter resides on the signed part of the HIP packets, and hence it is covered by the signatures of the R1, I2, and UPDATE packets.
hip_transport_modeパラメーターは、hipパケットの署名された部分に存在するため、R1、i2、および更新パケットの署名で覆われています。
If a HIP host wants to change to a different transport mode (or start using a transport mode) some time after the base exchange, it sends a HIP UPDATE packet with a HIP_TRANSPORT_MODE parameter containing the mode(s) it would prefer to use. The host receiving the UPDATE SHOULD respond with an UPDATE packet containing the mode that is selected as in the negotiation during the base exchange. If the receiving host does not support, or is not willing to use, any of the listed modes, it SHOULD respond with an UPDATE packet where the HIP_TRANSPORT_MODE parameter contains only the currently used transport mode (even if that was not included in the previous UPDATE packet) and continue using that mode.
股関節ホストがベースエクスチェンジ後にある時間の時間を変更する（またはトランスポートモードを使用して）別のトランスポートモードに変更したい場合、使用することを好むモードを含むHIP_TRANSPORT_MODEパラメーターを備えたHIPアップデートパケットを送信します。更新を受信するホストは、基本交換中のネゴシエーションのように選択されたモードを含む更新パケットで応答する必要があります。受信ホストがリストされているモードのいずれかをサポートしていない、または使用する意思のない場合、HIP_TRANSPORT_MODEパラメーターに現在使用されているトランスポートモードのみが含まれる更新パケットで応答する必要があります（前の更新に含まれていない場合でもパケット）そしてそのモードを使用し続けます。
Since the HIP_TRANSPORT_MODE parameter's type is not critical (as defined in Section 5.2.1 of [RFC5201]), a host not supporting this extension would simply reply with an acknowledgement UPDATE packet without a HIP_TRANSPORT_MODE parameter. In such a case, depending on local policy as in mode negotiation during the base exchange, the host that requested the new transport mode MAY close the HIP association. If the association is closed, the host closing the association SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet to the other host before closing the association.
hip_transport_modeパラメーターのタイプは重要ではないため（[rfc5201]のセクション5.2.1で定義されているように）、この拡張機能をサポートしていないホストは、hip_transport_modeパラメーターなしで確認更新パケットで単純に返信します。そのような場合、基本交換中のモードネゴシエーションのようなローカルポリシーに応じて、新しい輸送モードを要求したホストは、股関節関連を閉じることができます。協会が閉鎖されている場合、協会を閉鎖するホストは、Associationを閉じる前にNO_VALID_HIP_TRANSPORT_MODE NOTIFY PACKETを他のホストに通知する必要があります。
During a HIP signaling transport mode negotiation, if a HIP_TRANSPORT_MODE parameter does not contain any mode that the receiving host is willing to use, or a HIP_TRANSPORT_MODE parameter does not exist in a HIP packet where the receiving host expected to see it, the receiving host MAY send back a NOTIFY packet with a NOTIFICATION parameter [RFC5201] error type NO_VALID_HIP_TRANSPORT_MODE (value 100). The Notification Data field for the error notifications SHOULD contain the HIP header of the rejected packet.
股関節シグナリング輸送モードのネゴシエーション中、hip_transport_modeパラメーターに受信ホストが使用する意思のあるモードが含まれていない場合、またはhip_transport_modeパラメーターが受信ホストがそれを見ると予想される股関節パケットに存在しない場合、受信ホストは受信ホストが通知パラメーター[RFC5201]エラータイプno_valid_hip_transport_mode（value 100）を使用して通知パケットを送信します。エラー通知の通知データフィールドには、拒否されたパケットの股関節ヘッダーが含まれている必要があります。
This specification defines two different transport modes for sending HIP packets over encrypted ESP connections. These modes require that the ESP transport format [RFC5202] is negotiated to be used between the hosts. If the ESP transport format is not used, these modes MUST NOT be offered in the HIP_TRANSPORT_MODE parameter. If a HIP_TRANSPORT_MODE parameter containing an ESP transport mode is received but the ESP transport format is not used, a host MUST NOT select such a mode but act as specified in Section 3.1 (if performing a base exchange) or Section 3.2 (if performing an UPDATE) when no valid mode is offered.
この仕様では、暗号化されたESP接続で股関節パケットを送信するための2つの異なるトランスポートモードを定義します。これらのモードでは、ESP輸送形式[RFC5202]がホスト間で使用されるように交渉される必要があります。ESP輸送形式が使用されていない場合、これらのモードはhip_transport_modeパラメーターで提供されてはなりません。ESPトランスポートモードを含むhip_transport_modeパラメーターが受信されたがESP輸送形式が使用されない場合、ホストはそのようなモードを選択してはいけませんが、セクション3.1（ベースエクスチェンジの実行の場合）またはセクション3.2で指定されているように行動する必要はありません（更新を実行する場合））有効なモードが提供されていない場合。
The ESP mode provides simple protection for all the signaling traffic and can be used as a generic replacement for the DEFAULT mode in cases where all signaling traffic should be encrypted. If the HIP messages may become so large that they would need to be fragmented, e.g., because of HIP certificates [RFC6253] or DATA messages [RFC6078], it is RECOMMENDED to use the ESP-TCP mode that can handle message fragmentation at the TCP level instead of relying on IP-level fragmentation.
ESPモードは、すべての信号トラフィックに簡単な保護を提供し、すべてのシグナルトラフィックを暗号化する必要がある場合に、デフォルトモードの一般的な置換として使用できます。股関節メッセージが非常に大きくなる可能性があるため、ヒップ証明書[RFC6253]またはデータメッセージ[RFC6078]のために、断片化する必要がある場合は、TCPでメッセージフラグメンテーションを処理できるESP-TCPモードを使用することをお勧めします。IPレベルの断片化に依存する代わりにレベル。
When HIP NAT traversal [RFC5770] is used, the ESP and HIP packets are sent UDP encapsulated. The use of different NAT traversal modes, and in particular UDP encapsulation, is independent of the transport mode (as specified in this document) of HIP packets. However, when HIP packets are sent over an ESP connection, no additional UDP encapsulation (i.e., within the ESP connection) for the HIP packets is needed and MUST NOT be used since the ESP packets are already UDP encapsulated, if needed for NAT traversal. For example, if UDP encapsulation is used as defined in [RFC5770], and the ESP-TCP transport mode is used as defined in this document, the HIP packets are sent over IP, UDP, ESP, and TCP (in that order).
股関節NATトラバーサル[RFC5770]を使用すると、ESPと股関節のパケットがUDPカプセル化されて送信されます。さまざまなNATトラバーサルモード、特にUDPカプセル化の使用は、股関節パケットの輸送モード（このドキュメントで指定）とは無関係です。ただし、ESP接続に股関節パケットが送信されると、股関節パケットの追加のUDPカプセル化（つまり、ESP接続内）は必要ありません。NATトラバーサルに必要な場合、ESPパケットはすでにUDPカプセル化されているため、使用してはなりません。たとえば、UDPカプセル化が[RFC5770]で定義されているように使用され、ESP-TCP輸送モードがこのドキュメントで定義されている場合、股関節パケットはIP、UDP、ESP、およびTCPで送信されます（その順序で）。
HIP messages that result in changing or generating new keying material, i.e., the base exchange and re-keying UPDATE messages, MUST NOT be sent over the encrypted connection that is created using the keying material that is being changed, nor over an encrypted connection using the newly created keying material.
新しいキーイング材料の変更または生成、つまり基本交換および更新メッセージの再キーイングを作成する股関節メッセージは、変更されているキーイング素材を使用して作成された暗号化された接続や、暗号化された接続を使用して、暗号化された接続を使用して送信してはなりません。新しく作成されたキーイング素材。
It should be noted that when HIP messages are sent using an encrypted connection, on-path network elements (e.g., firewalls and HIP-aware NATs) that would normally see the HIP headers and contents of the unencrypted parameters, cannot see any part of the messages unless they have access to the encryption keying material. The original HIP design made an explicit decision to expose some of this information to HIP-aware NATs. If an encrypted transport mode is used, only the base exchange or update without encryption is visible to such NATs.
暗号化された接続を使用して股関節メッセージが送信されると、通常の股関節ヘッダーと暗号化されたパラメーターの内容が表示される、パスオンパスネットワーク要素（ファイアウォールやヒップアウェアNATなど）が送信される場合、暗号化キーイング材料にアクセスできない限り、メッセージ。元の股関節デザインは、この情報の一部を股関節を認識するNATに公開するという明確な決定を下しました。暗号化された輸送モードを使用する場合、暗号化なしのベース交換または更新のみがそのようなNATに表示されます。
If the ESP mode is selected in the base exchange, both hosts MUST listen for incoming HIP signaling messages and send outgoing messages on the encrypted connection. The ESP header's next header value for HIP messages sent over ESP MUST be set to HIP (139).
ESPモードがベースエクスチェンジで選択されている場合、両方のホストは着信の股関節信号メッセージを聞き、暗号化された接続で発信メッセージを送信する必要があります。ESPを介して送信される股関節メッセージのESPヘッダーの次のヘッダー値は、股関節に設定する必要があります（139）。
If the ESP-TCP mode is selected, the host with the larger HIT (calculated as defined in Section 6.5 of [RFC5201]) MUST start to listen for an incoming TCP connection on the encrypted connection (i.e., to the HIT of the host) on the port it used in the Port field of the transport mode parameter. The other host MUST create a TCP connection to that port and the host MAY use the port it sent in the transport mode parameter as the source port for the connection. Once the TCP connection is established, both hosts MUST listen for incoming HIP signaling messages and send the outgoing messages using the TCP connection. The ESP next header value for messages sent using the ESP-TCP mode TCP connections MUST be set to TCP (6).
ESP-TCPモードが選択されている場合、より大きなヒットのホスト（[RFC5201]のセクション6.5で定義されていると計算）は、暗号化された接続（つまり、ホストのヒット）の着信TCP接続を聞き始める必要があります。ポートでは、トランスポートモードパラメーターのポートフィールドで使用しました。他のホストはそのポートへのTCP接続を作成する必要があり、ホストは、接続のソースポートとしてトランスポートモードパラメーターで送信されたポートを使用することができます。TCP接続が確立されると、両方のホストは着信の股関節信号メッセージを聞き、TCP接続を使用して発信メッセージを送信する必要があります。ESP-TCPモードTCP接続を使用して送信されるメッセージのESP次のヘッダー値は、TCP（6）に設定する必要があります。
If the hosts are unable to create the TCP connection, the host that initiated the mode negotiation MUST restart the negotiation with the UPDATE message and SHOULD NOT propose the ESP-TCP mode. If local policy does not allow use of any mode other than ESP-TCP, the HIP association SHOULD be closed. The UPDATE or CLOSE message MUST be sent using the same transport mode that was used for negotiating the use of the ESP-TCP mode.
ホストがTCP接続を作成できない場合、モードネゴシエーションを開始したホストは、更新メッセージでネゴシエーションを再起動する必要があり、ESP-TCPモードを提案すべきではありません。ローカルポリシーでESP-TCP以外のモードの使用が許可されていない場合、股関節関連は閉じる必要があります。ESP-TCPモードの使用を交渉するために使用されたのと同じトランスポートモードを使用して、更新または閉じるメッセージを送信する必要があります。
Since TCP provides reliable transport, the HIP messages sent over TCP MUST NOT be retransmitted. Instead, a host SHOULD wait to detect that the TCP connection has failed to retransmit the packet successfully in a timely manner (such detection is platform- and policy-specific) before concluding that there is no response.
TCPは信頼できる輸送を提供するため、TCPを介して送信される股関節メッセージを再送信してはなりません。代わりに、ホストは、TCP接続がタイムリーにパケットを正常に再送信できなかったことを検出するのを待つ必要があります（このような検出は、プラットフォームおよびポリシー固有です）。
If the encrypted connection fails for some reason, it can no longer be used for HIP signaling and the hosts SHOULD re-establish the connection using HIP messages that are sent outside of the encrypted connection. Hence, while listening for incoming HIP messages on the encrypted connection, hosts MUST still accept incoming HIP messages using the same transport method (e.g., UDP or plain IP) that was used for the base exchange. When responding to a HIP message sent outside of the encrypted connection, the response MUST be sent using the same transport method as the original message used. If encryption was previously used, hosts SHOULD send outside of the encrypted connection only HIP messages that are used to re-establish the encrypted connection. In particular, when the policy requires that only encrypted messages (e.g., DATA messages using an encrypted transport mode) be sent, they MUST be sent using an encrypted connection. Note that a policy MUST NOT prevent sending unencrypted UPDATE messages used for re-establishing the encrypted connection, since that would prevent recovering from failed encrypted connections.
暗号化された接続が何らかの理由で失敗した場合、股関節シグナリングに使用できなくなり、ホストは暗号化された接続の外側で送信される股関節メッセージを使用して接続を再確立する必要があります。したがって、暗号化された接続で着信の股関節メッセージを聞いている間、ホストはベース交換に使用された同じ輸送方法（UDPまたはプレーンIPなど）を使用して、着信股関節メッセージを受け入れる必要があります。暗号化された接続の外部で送信される股関節メッセージに応答する場合、使用した元のメッセージと同じ輸送方法を使用して応答を送信する必要があります。暗号化が以前に使用されていた場合、ホストは暗号化された接続の外側で、暗号化された接続を再確立するために使用されるヒップメッセージのみを送信する必要があります。特に、ポリシーでは、暗号化されたメッセージのみ（例えば、暗号化されたトランスポートモードを使用したデータメッセージ）を送信する必要がある場合、暗号化された接続を使用して送信する必要があります。ポリシーは、暗号化された接続を再確立するために使用される暗号化されていない更新メッセージの送信を妨げてはならないことに注意してください。これにより、暗号化された接続が失敗したことから回復することができないためです。
The UPDATE messages used for re-establishing the encrypted connection MUST contain a HIP_TRANSPORT_MODE parameter and the negotiation proceeds as described in Section 3.2.
暗号化された接続を再確立するために使用される更新メッセージには、hip_transport_modeパラメーターが含まれている必要があり、セクション3.2で説明されているように交渉が進行します。
If a host obtains a new address, a new Security Association (SA) pair may be created for (or an existing SA pair may be moved to) the new address, as described in [RFC5206]. If the ESP or ESP-TCP transport mode is used, HIP signaling continues using the (new) SA pair and the same transport mode as before.
ホストが新しいアドレスを取得した場合、[RFC5206]に記載されているように、新しいアドレスの新しいセキュリティ協会（SA）ペアが新しいアドレスに作成される場合があります（または既存のSAペアを移動できます）。ESPまたはESP-TCPトランスポートモードを使用している場合、（新しい）SAペアと以前と同じ輸送モードを使用して、股関節シグナル伝達が継続します。
With the ESP mode, the first mobility UPDATE message SHOULD be sent using the old SA, and the following messages, including the response to the first UPDATE, SHOULD be sent using the new SAs. Retransmissions of the UPDATE messages use the same SA as the original message. If the ESP-TCP mode is used, the HIP signaling TCP connection is moved to the new SA pair like any other TCP connection. However, the mobility UPDATE messages SHOULD NOT be sent over the TCP connection, but using plain ESP as in the ESP mode, and consequently hosts MUST be prepared to receive UPDATE messages over plain ESP even if the ESP-TCP mode is used.
ESPモードでは、最初のモビリティ更新メッセージを古いSAを使用して送信する必要があり、最初の更新への応答を含む次のメッセージを新しいSASを使用して送信する必要があります。更新メッセージの再送信は、元のメッセージと同じSAを使用します。ESP-TCPモードを使用すると、HIPシグナル伝達TCP接続は、他のTCP接続と同様に新しいSAペアに移動します。ただし、モビリティ更新メッセージはTCP接続を介して送信されるべきではありませんが、ESPモードのようにプレーンESPを使用するため、ESP-TCPモードが使用されていてもプレーンESPを介して更新メッセージを受信するためにホストを準備する必要があります。
In some cases, the host may not be able to send the mobility UPDATE messages using the encrypted connection before it breaks. This results in a similar situation as if the encrypted connection had failed and the hosts need to renegotiate the new addresses using unencrypted UPDATE messages and possibly rendezvous [RFC5204] or HIP relay [RFC5770] servers. Also, these UPDATE messages MUST contain the HIP_TRANSPORT_MODE parameter and perform the transport mode negotiation.
場合によっては、ホストが破損する前に暗号化された接続を使用してモビリティ更新メッセージを送信できない場合があります。これにより、暗号化された接続が失敗し、ホストが暗号化されていない更新メッセージを使用して新しいアドレスを再交渉し、おそらくランデブー[RFC5204]またはヒップリレー[RFC5770]サーバーを使用して、同様の状況になります。また、これらの更新メッセージには、hip_transport_modeパラメーターを含み、トランスポートモードのネゴシエーションを実行する必要があります。
Examples of the signaling flows with mobility and multihoming are shown in Appendix A.
機動性とマルチホミングを伴うシグナル伝達フローの例を付録Aに示します。
By exchanging the HIP messages over an ESP connection, all HIP signaling data (after the base exchange but excluding keying material (re)negotiation and some of the mobility UPDATE messages) will be encrypted, but only if NULL encryption is not used. Thus, a host requiring confidentiality for the HIP signaling messages must check that encryption is negotiated for use on the ESP connection. Moreover, the level of protection provided by the ESP transport modes depends on the selected ESP transform; see [RFC5202] and [RFC4303] for security considerations of the different ESP transforms.
ESP接続で股関節メッセージを交換することにより、すべての股関節シグナリングデータ（基本交換後、キーイングマテリアル（RE）交渉とモビリティ更新メッセージの一部を除外）が暗号化されますが、ヌル暗号化が使用されない場合にのみ暗号化されます。したがって、股関節信号メッセージの機密性を必要とするホストは、暗号化がESP接続で使用するために交渉されていることを確認する必要があります。さらに、ESP輸送モードによって提供される保護レベルは、選択したESP変換に依存します。さまざまなESP変換のセキュリティに関する考慮事項については、[RFC5202]および[RFC4303]を参照してください。
While this extension to HIP allows for negotiation of security features, there is no risk of downgrade attacks since the mode negotiation happens using signed (R1/I2 or UPDATE) packets and only after both hosts have been securely identified in the base exchange. If an attacker would attempt to change the modes listed in the HIP_TRANSPORT_MODE parameter, that would break the signatures and the base exchange (or update) would not complete. Furthermore, since both "secure" modes (ESP and ESP-TCP) defined in this document are equally secure, the only possible downgrade attack would be to make both hosts accept the DEFAULT mode. If the local policy (of either host) requires using a secure mode, the base exchange or update would again simply fail (as described in Section 3.1).
この股関節への拡張により、セキュリティ機能の交渉が可能になりますが、モードネゴシエーションは署名された（R1/I2または更新）パケットを使用して行われ、両方のホストが基本交換で安全に特定された後にのみ、ダウングレード攻撃のリスクはありません。攻撃者がhip_transport_modeパラメーターにリストされているモードを変更しようとすると、署名が破損し、基本交換（または更新）が完了しません。さらに、このドキュメントで定義されている「セキュア」モード（ESPとESP-TCP）の両方が等しく安全であるため、両方のホストにデフォルトモードを受け入れることができる唯一の格下げ攻撃です。（いずれかのホストの）ローカルポリシーが安全なモードを使用する必要がある場合、ベース交換または更新は再び単純に失敗します（セクション3.1で説明されています）。
Thanks to Gonzalo Camarillo, Kristian Slavov, Tom Henderson, Miika Komu, Jan Melen, and Tobias Heer for reviews and comments.
ゴンザロ・カマリロ、クリスチャン・スラボフ、トム・ヘンダーソン、ミイカ・コム、ヤン・メレン、トビアス・ヒーアのレビューとコメントに感謝します。
This section is to be interpreted according to [RFC5226].
このセクションは、[RFC5226]に従って解釈されます。
This document updates the IANA maintained "Host Identity Protocol (HIP) Parameters" registry [RFC5201] by assigning a new HIP Parameter Type value (7680) for the HIP_TRANSPORT_MODE parameter (defined in Section 3.1).
このドキュメントでは、IANAがHIP_TRANSPORT_MODEパラメーターに新しいHIPパラメータータイプ値（7680）を割り当てることにより、「ホストIDアイデンティティプロトコル（HIP）パラメーター」レジストリ[RFC5201]を維持しました（セクション3.1で定義）。
The HIP_TRANSPORT_MODE parameter has 16-bit unsigned integer fields for different modes, for which IANA has created and now maintains a new sub-registry entitled "HIP Transport Modes" under the "Host Identity Protocol (HIP) Parameters" registry. Initial values for the transport mode registry are given in Section 3.1; future assignments are to be made through IETF Review or IESG Approval [RFC5226]. Assignments consist of a transport mode identifier name and its associated value.
HIP_TRANSPORT_MODEパラメーターには、さまざまなモードに16ビットの署名されていない整数フィールドがあり、IANAは「ホストIDプロトコル（HIP）パラメーター」の下で「HIP Transport Modes」というタイトルの新しいサブレジストリを維持しています。輸送モードレジストリの初期値は、セクション3.1に記載されています。将来の割り当ては、IETFレビューまたはIESG承認[RFC5226]を通じて行われます。割り当ては、輸送モード識別子名とそれに関連する値で構成されています。
This document also defines a new HIP NOTIFICATION message type [RFC5201] NO_VALID_HIP_TRANSPORT_MODE (100) in Section 3.3.
このドキュメントは、セクション3.3の新しい股関節通知メッセージタイプ[RFC5201] no_valid_hip_transport_mode（100）も定義しています。
[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月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204] Laganier、J。およびL. Eggert、「ホストアイデンティティプロトコル（HIP）Rendezvous Extension」、RFC 5204、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月。
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators", RFC 5770, April 2010.
[RFC5770] Komu、M.、Henderson、T.、Tschofenig、H.、Melen、J。、およびA. Keranen、 "基本ホストIdentity Identity Protocol（Hip）ネットワークアドレス翻訳者の横断の拡張"、RFC 5770、2010年4月。
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, January 2011.
[RFC6078] Camarillo、G。およびJ. Melen、「ホストアイデンティティプロトコル（HIP）即時運送および上層プロトコルシグナル伝達（Hiccups）の輸送」、RFC 6078、2011年1月。
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011.
[RFC6253] Heer、T。およびS. Varjonen、「ホストIDプロトコル証明書」、RFC 6253、2011年5月。
When changing interfaces due to mobility or multihoming, the hosts use HIP messages to notify the other host about the new address and to check that the host with the new address is still reachable. The following examples show the signaling performed during the address change in two different scenarios. Note that not all HIP parameters nor all the content of the parameters is shown in the examples. This section and the examples are not normative; for normative behavior, see previous sections.
モビリティまたはマルチホミングのためにインターフェイスを変更する場合、ホストはHIPメッセージを使用して、新しいアドレスについて他のホストに通知し、新しいアドレスを持つホストがまだ到達可能であることを確認します。次の例は、2つの異なるシナリオでアドレスの変更中に実行されたシグナル伝達を示しています。すべての股関節パラメーターやパラメーターのすべてのコンテンツが例に示されているわけではないことに注意してください。このセクションと例は規範的ではありません。規範的な動作については、以前のセクションを参照してください。
In the examples, host A uses two different addresses (a1 and a2) while host B has just a single address (b1). In the first example, "Make before Break" (Figure 2), host A starts to use the new address but can still use the old address (due to multihoming) for signaling. In the second example, "Break before Make" (Figure 3), host A loses the first address before obtaining the second address (e.g., due to mobility), and the mobility HIP signaling is done without the encrypted connection.
例では、ホストAは2つの異なるアドレス（A1とA2）を使用し、ホストBには単一のアドレス（B1）しかありません。最初の例である「Before Break」（図2）では、新しいアドレスの使用を開始しますが、シグナリングには古いアドレス（マルチホームのため）を使用できます。2番目の例「Break Before Make」（図3）では、2番目のアドレス（モビリティなど）を取得する前に最初のアドレスをホストし、移動股関節のシグナリングは暗号化された接続なしで行われます。
The following notations are used in the examples:
例では、次の表記法が使用されています。
o ESPx(y): data y sent encapsulated in ESP with SA x; if ESP-encapsulation is not used, the data is sent over plain IP or UDP
o espx（y）：sa xを使用してESPでカプセル化されたデータyが送信されました。ESPエンカプセル化が使用されない場合、データはプレーンIPまたはUDPを介して送信されます
o UPDATE(x,y,z): HIP UPDATE message [RFC5201] with parameters x,y,z
o 更新（x、y、z）：パラメーターx、y、zを備えたヒップ更新メッセージ[rfc5201]
o LOCATOR(x): HIP LOCATOR parameter [RFC5206] with locator x
o ロケーター（x）：ロケーターxを備えたヒップロケーターパラメーター[RFC5206]
o ESP_INFO(x,y): HIP ESP_INFO parameter [RFC5202] with "old SPI" value x and "new SPI" value y
o esp_info（x、y）： "old spi" value xおよび "new spi" value yを持つHIP ESP_INFOパラメーター[RFC5202]
o ACK, ECHO_REQ, and ECHO_RSP: HIP ACK, ECHO_REQUEST, and ECHO_RESPONSE parameters [RFC5201]
o ACK、ECHO_REQ、およびECHO_RSP：HIP ACK、ECHO_REQUEST、およびECHO_RESPONSEパラメーター[RFC5201]
A B
ESP1(...)
a1 <----------------------------------------------> b1
ESP1(UPDATE(LOCATOR(a2), ESP_INFO(0,SPI2a)))
a1 -----------------------------------------------> b1
(A and B create SAs a2 <-> b1 (ESP2) retransmissions of the first UPDATE happen over ESP1)
（AとBはSAS A2 <-> B1（ESP2）最初の更新の再送信を作成しますESP1で発生します）
ESP2(UPDATE(ACK, ESP_INFO(0,SPI2b), ECHO_REQ)))
a2 <----------------------------------------------- b1
ESP2(UPDATE(ACK, ECHO_RSP))
a2 -----------------------------------------------> b1
ESP2(...)
a2 <----------------------------------------------> b1
Figure 2: Make Before Break
図2：休憩前に作成します
A B
ESP1(...)
a1 <----------------------------------------------> b1
(A moves from a1 to a2)
UPDATE(LOCATOR(a2), ESP_INFO(SPI1a, SPI1a))
a2 -----------------------------------------------> b1
UPDATE(ACK, ECHO_REQ, ESP_INFO(SPI1b,SPI1b))
a2 <----------------------------------------------- b1
UPDATE(ACK, ECHO_RSP)
a2 -----------------------------------------------> b1
(A and B move ESP1 SAs to a2 <-> b1)
ESP1(...)
a2 <----------------------------------------------> b1
Figure 3: Break Before Make
図3：メイクの前に壊れます
When the ESP-TCP mode is used, the signaling flows are similar since TCP is not used for the mobility UPDATE messages as described in Section 6.
ESP-TCPモードを使用する場合、セクション6で説明されているように、TCPはモビリティ更新メッセージには使用されないため、シグナリングフローは類似しています。
Author's Address
著者の連絡先
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
EMail: ari.keranen@ericsson.com