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
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.
この文書では、それらをホスト識別プロトコルで開始暗号化接続を介して搬送することを可能にするシグナリングメッセージをホスト識別プロトコル（HIP）用の2つのトランスポートモードを指定します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6261.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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トラバーサル[RFC5770]のために予約さUDPポートを使用して、またはUDPの上に、この目的のために予約プロトコル番号を使用して、プレーンIPを介して交換することができます。 2つのホストがHIP基本交換を行うときは、データトラフィックのためのそれらの間の暗号化接続をセットアップしますが、HIPシグナリングメッセージのために、プレーン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.
この文書では、暗号化された接続は、HIPシグナリングメッセージのためにも使用することができる方法を定義します。 2つの異なるモードが定義されています。HIP TCP上のカプセル化セキュリティペイロード（ESP）とHIP上。 ESPの上にHIPメッセージを送信することの利点は、（HIPヘッダを含む）すべてのシグナリングトラフィックが暗号化されるということです。 HIPメッセージが（順番にESPの上に輸送される）TCP経由で送信された場合は、必要な場所、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.
このセクションでは、異なるHIPシグナリングメッセージ・トランスポート・モードのサポートが示されている方法と異なるモードの使用をネゴシエートする方法を定義します。
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シグナリングメッセージ転送モードネゴシエーションは、HIP NATトラバーサルモードネゴシエーションと同様である：最初のレスポンダは、R1パケット内HIP_TRANSPORT_MODEパラメータ（図1参照）でサポートされるモードを示しています。モードは、より好ましい形態（単数または複数）が第1の優先順にリストされています。イニシエータがサポートする、および使用する意思がある場合、応答者によって提案されたモードのいずれかは、それがI2パケットに選択されたモードを含むHIP_TRANSPORT_MODEパラメータを追加することにより、モードのいずれかを選択します。イニシエータモードのいずれかを選択し、塩基交換が成功した場合、最終的に、ホストは、HIPアソシエーションの期間または別のモードがネゴシエートされるまで、それらの間で送信される次のHIPシグナリングメッセージのために選択されたモードを使用しなければなりません。
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パラメータを含める必要がありますが、提案のいずれかのモードを使用することはありません。ローカルポリシーに応じて、Responderは塩基交換を中止することができるいずれか、またはそこにはHIP_TRANSPORT_MODEパラメータはI2でなかったか、パラメータが空だった場合、暗号化された接続を使用せずにHIPシグナリングを続けます。イニシエータはレスポンダがサポートしていない（したがって、R1に含まれていない）モードを選択した場合、レスポンダは、塩基交換を中止しなければなりません。塩基交換が原因HIP_TRANSPORT_PARAMETER（の可能性の欠如）に中断された場合、レスポンダはイニシエータに（3.3節を参照）NO_VALID_HIP_TRANSPORT_MODE通知を送るべきです。
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:
以下のHIP転送モードIDが定義されています。
ID name Value
RESERVED 0
DEFAULT 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）が、その後のHIPシグナリングメッセージのために使用されるべきであることを示しています。 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、及びUPDATEパケットの署名によって覆われています。
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ホストは、塩基交換後しばらくして、異なるトランスポートモードに変更（またはトランスポートモードを使用して起動）したい場合には、モード（s）は、それが使用することを好むを含むHIP_TRANSPORT_MODEパラメータでのHIP UPDATEパケットを送信します。 UPDATEを受信したホストは、基本交換の間の交渉のように選択されたモードを含む更新パケットで応答する必要があります。受信ホストがサポートしていませ、または使用して喜んではありません、リストされているモードのいずれかのない場合は、それはそれは、以前のアップデートに含まれていなかった場合でも、HIP_TRANSPORT_MODEパラメータのみが現在使用されるトランスポートモードが含まれているUPDATEパケット（に応じますパケット）とは、そのモードを使用し続けます。
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パラメータなしの確認応答更新パケットで応答であろう。そのような場合には、塩基交換時のモードネゴシエーションのようにローカルポリシーに応じて、新しいトランスポートモードを要求されたホストはHIPの関連付けを閉じます。協会が閉じている場合は、関連付けを閉じホストが関連を閉じる前に、他のホストにパケットをNOTIFY NO_VALID_HIP_TRANSPORT_MODEを送るべきです。
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シグナリング・トランスポート・モードのネゴシエーション中に、HIP_TRANSPORT_MODEパラメータは、受信ホストが使用して喜んでどのモードが含まれていない、またはHIP_TRANSPORT_MODEパラメータは、受信ホストはそれを見ることが予想HIPパケットに存在しない場合、受信側ホストMAY通知パラメータ[RFC5201]エラータイプNO_VALID_HIP_TRANSPORT_MODE（値100）とNOTIFYパケットを送り返します。エラー通知のための通知データフィールドは、拒否されたパケットのHIPヘッダを含むべきです。
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接続を介してHIPパケットを送信するための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モードでは、すべてのシグナリングトラフィックのためのシンプルな保護を提供し、すべてのシグナリングトラフィックが暗号化されなければならない場合のデフォルトモードのための一般的な代替として使用することができます。 HIPメッセージは、彼らがためにHIP証明書[RFC6253]またはDATAメッセージ[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).
HIP NATトラバーサル[RFC5770]を使用する場合、ESPおよびHIPパケットは、UDPがカプセル化送られます。異なるNATトラバーサルモードの使用、および特定のUDPカプセル化では、HIPパケット（本文書で指定されるように）トランスポートモードとは無関係です。しかしながら、HIPパケットがESP接続を介して送信されるとき、HIPパケットの追加のUDPカプセル化（すなわち、ESP接続内で）必要とされないとESPパケットが既にUDPカプセル化されているので、NATトラバーサルのために必要であれば、使用してはいけません。 [RFC5770]で定義されるようにUDPカプセル化が使用され、本文書で定義されるようにESP-TCPトランスポートモードが使用される場合、例えば、HIPパケットは、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.
新しい鍵素材を変更したり、生成につながるHIPメッセージ、すなわち、塩基交換および再キーイングUPDATEメッセージは、変更される鍵素材を使用して作成された暗号化接続を介して、また使用して暗号化された接続を介して送ってはいけません新しく作成された鍵材料。
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.
HIPメッセージが暗号化された接続を使用して送信されたときに、上のパスネットワーク要素（例えば、ファイアウォールやHIP-意識のNAT）が正常に暗号化されていないパラメータのHIPヘッダと内容を見ること、のいずれかの部分を見ることができないことに留意すべきですメッセージ彼らは、暗号化鍵材料へのアクセス権を持っていない限り。元HIPデザインは、HIP-意識の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モードがベース交換に選択されている場合は、両方のホストは、着信HIPシグナリングメッセージをリッスンし、暗号化された接続上で、発信メッセージを送らなければなりません。 ESPを介して送信されるHIPメッセージのESPヘッダの次ヘッダ値は、HIP（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で定義されるように計算される）より大きいHITを有するホスト（すなわち、ホストのHITに）暗号化された接続上で着信TCP接続をリッスンするために開始しなければなりませんポート上では、トランスポートモードパラメータのポート]フィールドで使用されます。他のホストは、そのポートへのTCP接続を作成する必要がありますし、ホストは、接続の送信元ポートとしてトランスポートモードパラメータで送信されたポートを使用するかもしれません。 TCP接続が確立されると、両方のホストは、着信HIPシグナリングメッセージをリッスンし、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接続を作成できない場合は、モードネゴシエーションを開始したホストは、UPDATEメッセージで交渉を再開しなければなりませんし、ESP-TCPモードを提案すべきではありません。ローカルポリシーは、ESP-TCP以外のモードの使用を許可していない場合は、HIP協会は閉じる必要があります。 UPDATEまたはCLOSEメッセージは、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を介して送信されるHIPメッセージを再送してはなりません。代わりに、ホストは、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.
暗号化された接続が何らかの理由で失敗した場合、それはもはやHIPシグナリングに使用することはできないとホストは暗号化接続の外に送信されたHIPメッセージを使用して接続を再確立する必要があります。したがって、暗号化された接続の着信HIPメッセージをリッスンしながら、ホストは、依然として塩基交換のために使用したのと同じ転送方法（例えば、UDPまたはプレーンIP）を使用して、着信HIPメッセージを受け入れなければなりません。暗号化された接続の外に送信されたHIPメッセージに応答する場合、応答は、使用した元のメッセージと同じ転送方式を使用して送信されなければなりません。暗号化が以前に使用された場合、ホストは暗号化された接続の暗号化接続を再確立するために使用されている唯一のHIPメッセージを外部に送信すべきです。特に、ポリシー（例えば、暗号化された転送モードを使用して、データメッセージ）を送信することのみ暗号化されたメッセージは、それらが暗号化された接続を使用して送信されなければならないことを要求します。それが失敗した暗号化された接続からの回復妨げるので、ポリシーは、暗号化された接続を再確立するために使用され、暗号化されていないUPDATEメッセージを送信妨げてはならないことに注意してください。
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.
3.2節で説明したようにHIP_TRANSPORT_MODEパラメータと交渉を進めるが含まれなければならない暗号化された接続を再確立するために使用UPDATEメッセージ。
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転送モードが使用される場合、HIPシグナリングは、以前のように（新たな）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モードでは、最初のモビリティUPDATEメッセージは、古いSAを使用して送信する必要があり、最初のUPDATEに対する応答を含め、以下のメッセージが、新しいSAを使用して送ってください。 UPDATEメッセージの再送信は、元のメッセージと同じSAを使用します。 ESP-TCPモードを使用する場合は、HIPシグナリングTCP接続は、他のTCP接続のような新しいSAのペアに移動されます。しかし、モビリティUPDATEメッセージは、TCP接続を介して送信されますが、ESPモードのようなプレーンなESPを使用して、その結果、ホストは、ESP-TCPモードを使用する場合でも、プレーンESPの上にUPDATEメッセージを受信するために準備しなければなりませんされるべきではありません。
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.
いくつかのケースでは、ホストは、それが壊れる前に暗号化された接続を使用してモビリティUPDATEメッセージを送信することができないかもしれません。暗号化された接続が失敗したとホストは暗号化されていないUPDATEメッセージを使用して、新しいアドレスとおそらくランデブー[RFC5204]やHIPリレー[RFC5770]サーバを再交渉する必要があるかのようにこれは、似たような状況になります。また、これらのUPDATEメッセージは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接続を介してHIPメッセージを交換することにより、すべての（塩基交換後しかし除く鍵材料（再）交渉およびモビリティUPDATEメッセージの一部）HIPシグナリングデータは暗号化されますが、NULL暗号化が使用されていない場合のみ。したがって、その暗号化を確認する必要がありますシグナリングメッセージをHIPための機密性を必要とするホストは、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この拡張はセキュリティ機能の折衝を可能にしながら、モードネゴシエーションが署名（R1 / I2またはUPDATE）を使用して起こるので、ダウングレード攻撃の危険性はないパケットにのみ、両方のホストの後に確実に塩基交換において同定されています。攻撃者は、に記載されているモードを変更しようとした場合
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).
署名と塩基交換（または更新）を壊す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.
レビューやコメントのゴンサロ・カマリロ、クリスチャンSlavov、トム・ヘンダーソン、Miikaこむ、ジャンメレン、およびトビアスHeerさんに感謝します。
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（セクション3.1で定義される）HIP_TRANSPORT_MODEパラメータのための新しいHIPパラメータタイプ値（7680）を割り当てることによって、「ホスト識別プロトコル（HIP）パラメータ」レジストリ[RFC5201]を維持し更新します。
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パラメータは、IANAが作成され、現在は「ホスト識別プロトコル（HIP）パラメータ」レジストリの下に新しいサブレジストリの名称「HIPトランスポートモード」を維持しているために異なるモード用の16ビット符号なし整数フィールドを、持っています。トランスポートモードレジストリの初期値は、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で新しいHIP通知メッセージタイプ[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]モスコウィッツ、R.、Nikander、P.、Jokela、P.、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、RFC 5201、2008年4月。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202] Jokela、P.、モスコウィッツ、R.、およびP. Nikander、RFC 5202、2008年4月 "ホスト識別プロトコル（HIP）とカプセル化セキュリティペイロード（ESP）トランスポートフォーマットを使用します"。
[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]ケント、S.、 "IPカプセル化セキュリティペイロード（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.エッゲルト、 "ホストアイデンティティプロトコル（HIP）ランデブー拡張"、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.、ヘンダーソン、T.、フォークト、C.、およびJ. Arkko、 "ホストアイデンティティプロトコルとエンドホストモビリティとマルチホーミング"、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]こむ、M.、ヘンダーソン、T.、Tschofenig、H.、メレン、J.、およびA. Keranen、 "基本的なホストアイデンティティプロトコル（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]キャマリロ、G.とJ.メレン、「ホストアイデンティティプロトコル（HIP）上位層プロトコルシグナリング（しゃっくり）の即時運送及び搬送」、RFC 6078、2011年1月。
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011.
[RFC6253] Heerさん、T.とS. Varjonen、 "ホストアイデンティティプロトコル証明書"、RFC 6253、2011年5月。
Appendix A. Mobility and Multihoming Examples
付録A.モビリティとマルチホーミング例
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つの異なるシナリオにおけるアドレス変更中に実行シグナリングを示します。必ずしもすべてのHIPパラメータやパラメータのすべてのコンテンツは、実施例に示されていることに留意されたいです。このセクションおよび実施例は、規範的ではありません。規範的な行動のために、前のセクションを参照してください。
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.
ホストBは、ちょうど単一のアドレス（b1）を有している例では、ホストAは、2つの異なるアドレス（A1およびA2）を使用します。最初の例では、「ブレイクの前にしてください」（図2）、ホストAは、新しいアドレスを使用するために開始しますが、それでもシグナリングのために（よるマルチホーミングへの）古いアドレスを使用することができます。第2の例では、（図3）、「メイク前ブレーク」、ホストAは、第2のアドレス（例えば、モビリティに起因する）を取得する前に、最初のアドレスを失い、そしてモビリティHIPシグナリングは暗号化された接続せずに行われます。
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）データyは、SA XとESP内にカプセル化送ら。 ESP-カプセル化が使用されていない場合、データは、プレーンIPやUDP経由で送信されます
o UPDATE(x,y,z): HIP UPDATE message [RFC5201] with parameters x,y,z
O UPDATE（X、Y、Z）：パラメータxとHIP UPDATEメッセージ[RFC5201]、Y、Z
o LOCATOR(x): HIP LOCATOR parameter [RFC5206] with locator x
Oロケータ（X）：ロケータXとHIPロケータパラメータ[RFC5206]
o ESP_INFO(x,y): HIP ESP_INFO parameter [RFC5202] with "old SPI" value x and "new SPI" value y
"古いSPI" 値xと "新しいSPI" 値YとのHIP ESP_INFOパラメータ[RFC5202]：O ESP_INFO（x、y）は
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)
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
KeranenエリクソンHirsalantie 11 02420 Jorvasフィンランド
EMail: ari.keranen@ericsson.com
メールアドレス：ari.keranen@ericsson.com