[要約] RFC 6537は、Host Identity Protocol（HIP）の分散ハッシュテーブル（DHT）インターフェースに関する仕様です。このRFCの目的は、HIPベースのDHTを使用して、ネットワーク上のホストの識別と検索を効率的に行うことです。
Internet Research Task Force (IRTF) J. Ahrenholz
Request for Comments: 6537 The Boeing Company
Category: Experimental February 2012
ISSN: 2070-1721
Host Identity Protocol Distributed Hash Table Interface
ホストIDプロトコル分散ハッシュテーブルインターフェイス
Abstract
概要
This document specifies a common interface for using the Host Identity Protocol (HIP) with a Distributed Hash Table (DHT) service to provide a name-to-Host-Identity-Tag lookup service and a Host-Identity-Tag-to-address lookup service.
このドキュメントは、分散ハッシュテーブル（DHT）サービスを使用してホストIDプロトコル（HIP）を使用するための共通インターフェイスを指定して、名前から宿泊施設のタグのルックアップサービスとホストアイデンティティタグからアドレスの検索を提供しますサービス。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the HIP Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）の股関節研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。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/rfc6537.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6537で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. The OpenDHT Interface ...........................................3
3. HDRR - The HIP DHT Resource Record ..............................6
4. HIP Lookup Services .............................................8
4.1. HIP Name to HIT Lookup .....................................9
4.2. HIP Address Lookup ........................................12
5. Use Cases ......................................................15
6. Issues with DHT Support ........................................16
7. Security Considerations ........................................17
8. IANA Considerations ............................................18
9. Acknowledgments ................................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
The Host Identity Protocol (HIP) [RFC5201] may benefit from a lookup service based on Distributed Hash Tables (DHTs). The Host Identity namespace is flat, consisting of public keys, in contrast to the hierarchical Domain Name System (DNS). These keys are hashed and prefixed to form Host Identity Tags (HITs), which appear as large random numbers. As the current DNS system has been heavily optimized for address lookup, it may be worthwhile to experiment with other services such as those defined here. DHTs manage such data well by applying a hash function that distributes data across a number of servers. DHTs are also designed to be updated more frequently than a DNS-based approach. For an alternative method of using HITs to look up IP addresses using DNS, see [HIT2IP].
ホストIDプロトコル（HIP）[RFC5201]は、分散ハッシュテーブル（DHT）に基づくルックアップサービスの恩恵を受ける可能性があります。階層ドメイン名システム（DNS）とは対照的に、ホストID名スペースはパブリックキーで構成されるフラットです。これらのキーはハッシュされており、接頭辞が付けられており、ホストIDタグ（ヒット）を形成します。これは、大きな乱数として表示されます。現在のDNSシステムはアドレスルックアップのために大幅に最適化されているため、ここで定義されているような他のサービスを実験する価値があるかもしれません。DHTは、多くのサーバーにデータを分散するハッシュ関数を適用することにより、そのようなデータを適切に管理します。DHTは、DNSベースのアプローチよりも頻繁に更新されるように設計されています。ヒットを使用してDNSを使用してIPアドレスを検索する代替方法については、[HIT2IP]を参照してください。
One freely available implementation of a DHT is the Bamboo DHT, which is Java-based software that has been deployed on PlanetLab servers to form a free service named OpenDHT. OpenDHT was available via the Internet for any program to store and retrieve arbitrary data. OpenDHT used a well-defined Extensible Markup Language-Remote Procedure Calling (XML-RPC) interface, featuring put, get, and remove operations. OpenLookup, while not implemented as a DHT, is another deployment of open source software compatible with this OpenDHT interface. This document discusses a common way for HIP to use this OpenDHT interface, so that various HIP experimenters may employ lookup services in an interoperable fashion.
DHTの自由に利用可能な実装の1つは、bamboo DHTです。これは、PlanetLabサーバーに展開されてOpenDHTという名前の無料サービスを形成するJavaベースのソフトウェアです。Opendhtは、任意のデータを保存および取得するためのプログラムでインターネットを介して入手できました。Opendhtは、適切に定義された拡張可能なマークアップ言語削除プロシージャコール（XML-RPC）インターフェイスを使用して、操作を特徴、取得、削除しました。OpenLookupは、DHTとして実装されていませんが、このOpenDHTインターフェイスと互換性のあるオープンソースソフトウェアの別の展開です。このドキュメントでは、股関節がこのOpenDhtインターフェイスを使用する一般的な方法について説明しているため、さまざまな股関節実験者が操作可能な方法でルックアップサービスを採用する可能性があります。
This document is a product of the HIP research group (RG) of the IRTF. The HIP research group reached consensus that this interface specification should be published as an Experimental RFC, based on
このドキュメントは、IRTFの股関節研究グループ（RG）の製品です。股関節研究グループは、このインターフェイス仕様が実験RFCとして公開されるべきであるというコンセンサスに達しました。
document review by at least six RG members including the chairs, and based on implementation experience. This document is not an IETF product and is not a standard.
椅子を含む少なくとも6人のRGメンバーによるドキュメントレビュー、および実装エクスペリエンスに基づいて。このドキュメントはIETF製品ではなく、標準ではありません。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
OpenDHT [OPENDHT] was a public deployment of Bamboo DHT servers that ran on about 150 PlanetLab nodes, and was retired in July 2009. While the Bamboo project provided the actual software running on the servers, here we will refer only to OpenDHT, which uses a certain defined interface for the XML-RPC calls. Another service compatible with this interface is OpenLookup. One can run their own Bamboo nodes to set up a private ring of servers.
Opendht [opendht]は、約150のPlanetLabノードで実行された竹のDHTサーバーの公開展開であり、2009年7月に退職しました。XML-RPC呼び出しの特定の定義インターフェイス。このインターフェイスと互換性のある別のサービスは、OpenLookUpです。独自の竹ノードを実行して、サーバーのプライベートリングをセットアップできます。
OpenDHT was chosen because it was a well-known, publicly available DHT used within the research community. Its interface features a simple, standards-based protocol that can be easily implemented by HIP developers. This document does not aim to dictate that only the services and servers described here should be used, but is rather meant to act as a starting point to gain experience with these services, choosing tools that are readily available.
Opendhtは、研究コミュニティ内で使用されている有名で公開されているDHTであったために選ばれました。そのインターフェイスは、ヒップ開発者が簡単に実装できるシンプルな標準ベースのプロトコルを備えています。このドキュメントは、ここで説明するサービスとサーバーのみを使用する必要があることを指示することではなく、むしろこれらのサービスの経験を積むための出発点として機能し、すぐに利用できるツールを選択することを目的としています。
OpenDHT stores values and indexes those values by using (hash) keys. Keys are limited to 20 bytes in length, and values can be up to 1024 bytes. Values are stored for a certain number of seconds, up to a maximum of 604,800 seconds (one week.) For more information, see the OpenDHT website: <http://www.opendht.org/>.
opendhtは、（ハッシュ）キーを使用して値を保存し、それらの値をインデックス付けします。キーの長さは20バイトに制限されており、値は最大1024バイトです。値は、最大604,800秒（1週間）までの一定の秒数で保存されます。詳細については、OpenDHT Webサイト：<http://www.opendht.org/>を参照してください。
Three RPC operations are supported: put, get, and rm (remove). Put is called with key and value parameters, causing the value to be stored using the key as its hash index. Get is called with the key parameter, when you have a key and want to retrieve the value. Rm is called with a hash of the value to be removed along with a secret value, a hash of which was included in the put operation.
3つのRPC操作がサポートされています：Put、Get、およびRM（削除）。PUTはキーパラメーターと値パラメーターで呼び出され、キーをハッシュインデックスとして使用して値を保存します。キーがあり、値を取得したい場合、GETはキーパラメーターで呼び出されます。RMは、秘密の値とともに削除される値のハッシュで呼び出され、そのハッシュがPUT操作に含まれていました。
The definitions below are taken from the OpenDHT users guide at <http://opendht.org/users-guide.html>.
以下の定義は、<http://opendht.org/users-guide.html>のOpenDhtユーザーガイドから取得されています。
The put operation takes the following arguments:
プット操作は次の引数を取ります。
+----------------+--------------------------------------+
| field | type |
+----------------+--------------------------------------+
| application | string |
| | |
| client_library | string |
| | |
| key | byte array, 20 bytes max. |
| | |
| value | byte array, 1024 bytes max. |
| | |
| ttl_sec | four-byte integer, max. value 604800 |
| | |
| secret_hash | optional SHA-1 hash of secret value |
+----------------+--------------------------------------+
The server replies with an integer -- 0 for "success", 1 if it is "over capacity", and 2 indicating "try again". The return code 3 indicates "failure" and is used for a modified OpenDHT server that performs signature and HIT verification, see Section 3.
サーバーは、「成功」の場合は0、「容量上」の場合は1、「再試行」を示す場合は、整数で返信します。返されるコード3は「障害」を示し、署名を実行して確認する確認を実行する変更されたOpenDHTサーバーに使用されます。セクション3を参照してください。
The get operation takes the following arguments:
GET操作は次の引数を取ります。
+----------------+---------------------------------------------+
| field | type |
+----------------+---------------------------------------------+
| application | string |
| | |
| client_library | string |
| | |
| key | byte array, 20 bytes max. |
| | |
| maxvals | four-byte singed integer, max. value 2^31-1 |
| | |
| placemark | byte array, 100 bytes max. |
+----------------+---------------------------------------------+
The server replies with an array of values, and a placemark that can be used for fetching additional values.
サーバーは、値の配列と、追加の値を取得するために使用できるプレースマークで返信します。
The rm operation takes the following arguments:
RM操作は次の引数を取ります。
+----------------+----------------------------------------------+
| field | type |
+----------------+----------------------------------------------+
| application | string |
| | |
| client_library | string |
| | |
| key | byte array, 20 bytes max. |
| | |
| value_hash | SHA-1 hash of value to remove |
| | |
| ttl_sec | four-byte integer, max. value 604800 |
| | |
| secret | secret value (SHA-1 of this was used in put) |
+----------------+----------------------------------------------+
The server replies with an integer -- 0 for "success", 1 if it is "over capacity", and 2 indicating "try again".
サーバーは、「成功」の場合は0、「容量上」の場合は1、「再試行」を示す場合は、整数で返信します。
This is the basic XML-RPC interface provided by OpenDHT. Each "field" from the above tables are XML tags that enclose their corresponding values. The key is a byte array used to index the record for storage and retrieval from the DHT. The value is a byte array of the data being stored in the DHT. The application and client_library fields are metadata used only for logging purposes. The ttl_sec field specifies the number of seconds that the DHT should store the value. The secret_hash field allows values to be later removed from the DHT. The maxvals and placemark fields are for retrieving a maximum number of values and for iterating get results.
これは、OpenDhtが提供する基本的なXML-RPCインターフェイスです。上記のテーブルの各「フィールド」は、対応する値を囲むXMLタグです。キーは、DHTからストレージと検索のレコードをインデックス化するために使用されるバイト配列です。値は、DHTに保存されているデータのバイト配列です。アプリケーションとclient_libraryフィールドは、ロギング目的でのみ使用されるメタデータです。TTL_SECフィールドは、DHTが値を保存する秒数を指定します。Secret_Hashフィールドにより、値を後でDHTから削除できます。MaxvalsおよびPlacemarkフィールドは、最大数の値を取得し、結果を繰り返すための結果です。
The return code of 0 "success" indicates a successful put or remove operation. The return code of 1 "over capacity" means that a client is using too much storage space on the server. The return value of 2 "try again" indicates that the client should retry the put operation because a temporary problem prevented the server from accepting the put.
0 "success"の返品コードは、操作が成功または削除されたことを示します。1 "over容量"の返品コードは、クライアントがサーバー上にあまりにも多くのストレージスペースを使用していることを意味します。2の「再試行」の返品値は、一時的な問題によりサーバーがプットを受け入れることができないため、クライアントがプット操作を再試行する必要があることを示します。
In the sections that follow, specific uses for these DHT operations and their XML fields are suggested for use with HIP.
以下のセクションでは、これらのDHT操作とそのXMLフィールドに特定の使用が股関節で使用されることをお勧めします。
The two lookup services described in this document use a HIP DHT Resource Record (HDRR) defined in this section. This record is a wrapper around data contained in TLVs, similar to a HIP control packet. The data contained in each HDRR differs between the two services.
このドキュメントで説明されている2つのルックアップサービスは、このセクションで定義されている股関節DHTリソースレコード（HDRR）を使用しています。このレコードは、股関節制御パケットと同様に、TLVに含まれるデータに関するラッパーです。各HDRRに含まれるデータは、2つのサービス間で異なります。
The HDRR uses the same binary format as HIP packets (defined in [RFC5201].) This packet encoding is used as a convenience, even though this data is actually a resource record stored and retrieved by the DHT servers, not a packet sent on the wire by a HIP protocol daemon. Note that this HDRR format is different than the HIP RR used by the Domain Name System as defined in [RFC5205]. The reason it is different is that it is a different record from a functional point of view: in DNS, the query key is a Fully Qualified Domain Name (FQDN), and the return value is a HIT, while here, the query key is a HIT.
HDRRは、HIPパケットと同じバイナリ形式を使用します（[RFC5201]で定義されています。）ヒッププロトコルデーモンによるワイヤー。このHDRR形式は、[RFC5205]で定義されているドメイン名システムで使用される股関節RRとは異なることに注意してください。それが違う理由は、それが機能的な観点とは異なるレコードであるためです。DNSでは、クエリキーは完全に認定されたドメイン名（FQDN）であり、リターン値はヒットですが、ここではクエリキーはヒット。
HIP header values for the HDRR:
HDRRのヒップヘッダー値：
HIP Header: Packet Type = 20 DHT Resource Record SRC HIT = Sender's HIT DST HIT = NULL
ヒップヘッダー：パケットタイプ= 20 DHTリソースレコードsrc hit = sender's hit dst hit = null
HDRR used with HIT lookup: HIP ( [CERT] )
ヒットルックアップで使用されるHDRR：HIP（[cert]）
HDRR used with address lookup: HIP ( LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIGNATURE )
アドレスルックアップで使用されるHDRR：HIP（Locator、seq、host_id、[cert]、hip_signature）
The Initiator HIT (Sender's HIT, SRC HIT) MUST be set to the HIT that the host wishes to make available using the lookup service. With the HIT lookup service, this is the main piece of information returned by a get operation. For the address lookup service, this HIT MUST be the same one used to derive the HIT_KEY used as the DHT key. The Responder HIT (Receiver's HIT, DST HIT) MUST be NULL (all zeroes) since the data is intended for any host.
イニシエーターヒット（送信者のヒット、SRCヒット）は、ルックアップサービスを使用してホストが利用可能になりたいと考えているヒットに設定する必要があります。ヒットルックアップサービスにより、これはGET操作によって返される主な情報です。アドレスルックアップサービスの場合、このヒットは、DHTキーとして使用されるHIT_KEYを導出するために使用されるものと同じでなければなりません。レスポンダーのヒット（受信者のヒット、DSTヒット）は、データがホスト向けであるため、null（すべてゼロ）でなければなりません。
The only other TLV used with the HIT lookup service is an optional CERT parameter containing a certificate for validating the name that is used as the DHT key. The CERT parameter is defined in [RFC6253]. The DHT server SHOULD use the certificate to verify that the client is authorized to use the name used for the DHT key, using the hash of the name found in the certificate. The Common Name (CN) field from the Distinguished Name (DN) of the X.509.v3 certificate MUST be used. Which certificates are considered trusted is a local policy issue.
ヒットルックアップサービスで使用される他の唯一のTLVは、DHTキーとして使用される名前を検証するための証明書を含むオプションの証明書パラメーターです。CERTパラメーターは[RFC6253]で定義されています。DHTサーバーは、証明書を使用して、クライアントが証明書にある名前のハッシュを使用して、DHTキーに使用される名前を使用することを許可されていることを確認する必要があります。X.509.V3証明書の著名な名前（DN）からの一般名（CN）フィールドを使用する必要があります。信頼されていると見なされる証明書は、現地のポリシーの問題です。
The remaining parameters described here are used with the address lookup service.
ここで説明する残りのパラメーターは、アドレスルックアップサービスで使用されます。
The LOCATOR parameter contains the addresses that the host wishes to make available using the lookup service. A host MAY publish its current preferred IPv4 and IPv6 locators, for example.
ロケーターパラメーターには、ルックアップサービスを使用してホストが利用可能にしたいアドレスが含まれています。ホストは、たとえば、現在の優先IPv4およびIPv6ロケーターを公開する場合があります。
The SEQ parameter contains an unsigned 32-bit sequence number, the Update ID. This is typically initialized to zero and incremented by one for each new HDRR that is published by the host. The host SHOULD retain the last Update ID value it used for each HIT across reboots, or perform a self lookup in the DHT. The Update ID value may be retained in the DHT records and will determine the preferred address used by peers.
SEQパラメーターには、署名されていない32ビットシーケンス番号、更新IDが含まれています。これは通常、ゼロに初期化され、ホストが公開する新しいHDRRごとに1つずつ増加します。ホストは、再起動全体でヒットするたびに使用された最後の更新ID値を保持するか、DHTでセルフルックアップを実行する必要があります。更新ID値はDHTレコードに保持される場合があり、ピアが使用する優先アドレスを決定します。
The HOST_ID parameter contains the Host Identity that corresponds with the Sender's HIT. (The encoding of this parameter is defined in Section 5.2.8 of [RFC5201].)
HOST_IDパラメーターには、送信者のヒットに対応するホストIDが含まれています。（このパラメーターのエンコードは、[RFC5201]のセクション5.2.8で定義されています。）
The HOST_ID parameter and HIP_SIGNATURE parameter MUST be used with the HDRR so that HIP clients receiving the record can validate the sender and the included LOCATOR parameter. The HIT_KEY used for the DHT key will also be verified against the Host Identity.
HOST_IDパラメーターとHIP_SignatureパラメーターをHDRRで使用して、レコードを受信するHIPクライアントが送信者と含まれるロケーターパラメーターを検証できるようにする必要があります。DHTキーに使用されるHIT_KEYは、ホストIDに対しても検証されます。
The client that receives the HDRR from the DHT response MUST perform the signature and HIT_KEY verification. If the signature is invalid for the given Host Identity or the HIT_KEY used to retrieve the record does not match the Host Identity, the DHT record retrieved MUST be ignored. Note that for client-only verification, the DHT server does not need to be modified.
DHT応答からHDRRを受信するクライアントは、署名とHIT_KEYの検証を実行する必要があります。指定されたホストIDに対して署名が無効である場合、またはレコードを取得するために使用されるHIT_KEYがホストIDと一致しない場合、取得したDHTレコードは無視する必要があります。クライアントのみの検証の場合、DHTサーバーを変更する必要はないことに注意してください。
The Sender's HIT in the HDRR MUST correspond with the key used for the lookup and Host Identity verification. The Receiver's HIT MUST be NULL (all zeroes) in the HDRR header.
HDRRでの送信者のヒットは、ルックアップおよびホストIDの確認に使用されるキーに対応する必要があります。レシーバーのヒットは、HDRRヘッダーのnull（すべてゼロ）でなければなりません。
When several HDRR records are returned by the server, the client SHOULD pick the most recent record as indicated by the Update ID in the SEQ TLV of the HDRR and perform verification on that record. The order in which records are returned should not be considered.
サーバーによっていくつかのHDRRレコードが返される場合、クライアントはHDRRのSEQ TLVの更新IDで示されているように、最新のレコードを選択し、そのレコードで検証を実行する必要があります。記録が返される順序は考慮されるべきではありません。
The DHT server MAY also verify the SIGNATURE and HOST_ID, with some modifications to the Bamboo DHT software and a new return code with the OpenDHT interface. The signature in the put MUST be verified using the given Host Identity (public key), and the HIT_KEY provided as the lookup key MUST match this Host Identity according to the Overlay Routable Cryptographic Hash Identifiers (ORCHID) generation method defined by [RFC4843]. If either signature or HIT verification
DHTサーバーは、Bamboo DHTソフトウェアの変更とOpenDHTインターフェイスを備えた新しいリターンコードを使用して、署名とhost_idを検証することもできます。PUTの署名は、指定されたホストID（公開鍵）を使用して検証する必要があり、検索キーとして提供されたHIT_KEYは、[RFC4843]で定義されたオーバーレイルーティング可能な暗号化ハッシュ識別子（蘭）生成方法に従ってこのホストIDと一致する必要があります。署名またはヒット検証のいずれかの場合
fails, the put MUST not be recorded into the DHT, and the server returns a failure code. The failure code is an additional return code not defined by OpenDHT, with a value of 3.
失敗すると、プットをDHTに記録してはなりません。サーバーは障害コードを返します。障害コードは、opendhtによって定義されていない追加の返品コードであり、値は3です。
This server-side verification of records could introduce a source of a denial-of-service attack. The server policy could require clients to have an active HIP association. See Section 7 for further discussion.
このサーバー側のレコードの検証により、サービス拒否攻撃のソースが導入される可能性があります。サーバーポリシーでは、クライアントにアクティブな股関節関連を持たせる必要があります。詳細については、セクション7を参照してください。
This document defines a HIT lookup and address lookup service for use with HIP. The HIT lookup uses a text name to discover a peer's HIT. The address lookup uses a peer's HIT to discover its current addresses.
このドキュメントでは、HIPで使用するためのヒットルックアップとアドレスルックアップサービスを定義します。ヒットルックアップでは、テキスト名を使用してピアのヒットを発見します。アドレスルックアップでは、ピアのヒットを使用して現在のアドレスを発見します。
The two lookups are defined below. The abbreviated notation refers to the HIP parameter types; for example, HIP_SIG is the HIP signature parameter defined by [RFC5201].
2つのルックアップを以下に定義します。短縮された表記は、股関節パラメータータイプを指します。たとえば、HIP_SIGは[RFC5201]で定義された股関節シグネチャパラメーターです。
HDRR([CERT]) = get(SHA-1("name"))
HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY)
The HIT lookup service returns the Host Identity Tag of a peer given a name. The name SHOULD be the FQDN, hostname, or some other alias. This HIT is found in the Sender's HIT field of the HDRR. The HIT is the hash of the public-key-based Host Identity as described in [RFC5201]. There are no security properties of the name, unlike the HIT. An optional certificate MAY be included in the record, for validating the name, providing some measure of security. Which certificates are considered trusted is a local policy issue. This service is intended for use when legacy DNS servers do not support HIP resource records, or when hosts do not have administrative access to publish their own DNS records. Such an unmanaged naming service may help facilitate experimentation.
ヒットルックアップサービスは、名前が付けられたピアのホストIDタグを返します。名前は、FQDN、ホスト名、またはその他のエイリアスである必要があります。このヒットは、HDRRの送信者のヒットフィールドにあります。[RFC5201]に記載されているように、ヒットはパブリックキーベースのホストIDのハッシュです。ヒットとは異なり、名前のセキュリティプロパティはありません。名前を検証し、ある程度のセキュリティを提供するために、オプションの証明書が記録に含まれる場合があります。信頼されていると見なされる証明書は、現地のポリシーの問題です。このサービスは、Legacy DNSサーバーが股関節リソースレコードをサポートしていない場合、またはホストが独自のDNSレコードを公開する管理アクセスを持たない場合に使用することを目的としています。このような管理されていない命名サービスは、実験を促進するのに役立つかもしれません。
The address lookup returns a locator and other validation data in the HDRR for a given HIT. Before a HIP association can be initiated (not in opportunistic mode), a HIP host needs to know the peer's HIT and the current address at which the peer is reachable. Often the HIT will be pre-configured, available via DNS lookup using a hostname lookup [RFC5205], or retrieved using the HIT lookup service defined in this document. With HIP mobility [RFC5206], IP addresses may be used as locators and may often change. The Host Identity and the HIT remain relatively constant and can be used to securely identify a host, so the HIT serves as a suitable DHT key for storing and retrieving addresses.
アドレスルックアップは、特定のヒットに対してHDRRのロケーターとその他の検証データを返します。（日和見モードではなく）股関節関連を開始する前に、ヒップホストはピアのヒットとピアに到達可能な現在のアドレスを知る必要があります。多くの場合、ヒットは事前に構成され、ホスト名Lookup [RFC5205]を使用してDNSルックアップを使用して利用できます。また、このドキュメントで定義されたヒットルックアップサービスを使用して取得します。HIPモビリティ[RFC5206]を使用すると、IPアドレスがロケーターとして使用される場合があり、しばしば変更される場合があります。ホストのアイデンティティとヒットは比較的一定であり、ホストを安全に識別するために使用できるため、ヒットはアドレスを保存および取得するための適切なDHTキーとして機能します。
The address lookup service includes the peer's Host Identity and a signature over the locators. This allows the DHT client or server to validate the address information stored in the DHT.
アドレスルックアップサービスには、ピアのホストIDとロケーター上の署名が含まれます。これにより、DHTクライアントまたはサーバーがDHTに保存されているアドレス情報を検証できます。
These two separate lookups are defined instead of one because the address record is expected to change more frequently, while the name-to-HIT binding should remain relatively constant. For example, local policy may specify checking the name-to-HIT binding on a daily basis, while the address record is updated hourly for active peers. Also, the client and server validation of the two records is different, with the HIT lookup using certificates verifying the name and the address lookup using a signature produced by the bearer of a particular Host Identity/HIT.
アドレスレコードはより頻繁に変更されると予想されるため、これら2つの個別のルックアップは1つではなく定義されますが、名前からヒットのバインディングは比較的一定のままである必要があります。たとえば、ローカルポリシーは、日常的に名前からヒットのバインディングをチェックすることを指定する場合がありますが、アドレスレコードはアクティブピアの1時間ごとに更新されます。また、2つのレコードのクライアントとサーバーの検証は異なります。ヒットルックアップは、特定のホストID/ヒットのベアラーが作成した署名を使用して、名前とアドレスルックアップを確認する証明書を使用して検索します。
These services reduce the amount of pre-configuration required at each HIP host. The address of each peer no longer needs to be known ahead of time, if peers also participate by publishing their addresses. If peers choose to publish their HITs with a name, peer HITs also no longer require pre-configuration. However, discovering an available DHT server for servicing these lookups will require some additional configuration.
これらのサービスは、各股関節ホストで必要な事前構成の量を減らします。ピアのアドレスも事前に知られる必要はありません。ピアが名前でヒットを公開することを選択した場合、ピアヒットも再構成を必要としなくなります。ただし、これらのルックアップにサービスを提供するために利用可能なDHTサーバーを発見するには、追加の構成が必要です。
Given the SHA-1 hash of a name, a lookup returns the HIT of the peer. The hash of a name is used because OpenDHT keys are limited to 20 bytes, so this allows for longer names. Publish, lookup, and remove operations are defined below.
名前のSHA-1ハッシュを考えると、ルックアップがピアのヒットを返します。Opendhtキーは20バイトに制限されているため、名前のハッシュが使用されているため、より長い名前が可能になります。公開、検索、および削除操作を以下に定義します。
HDRR([CERT]) = get(SHA-1("name"))
put(SHA-1("name"), HDRR([CERT]), [SHA-1(secret)])
rm(SHA-1("name"), SHA-1(HDRR), secret)
HIT publish
パブリッシュをヒットします
+----------------+----------------------------------------+---------+
| field | value | data |
| | | type |
+----------------+----------------------------------------+---------+
| application | "hip-name-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA-1 hash of a name | base64 |
| | | encoded |
| | | |
| value | HDRR([CERT]), with the HIT to be | base64 |
| | published contained in the Sender's | encoded |
| | HIT field of the HDRR, and an optional | |
| | certificate for validating the name | |
| | used as the key | |
| | | |
| ttl_sec | lifetime for this record, value from | numeric |
| | 0-604800 seconds | string |
| | | |
| secret_hash | optional SHA-1 hash of secret value | base64 |
| | | encoded |
+----------------+----------------------------------------+---------+
HIT lookup
ヒットルックアップ
+----------------+---------------------------------+----------------+
| field | value | data type |
+----------------+---------------------------------+----------------+
| application | "hip-name-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA-1 hash of a name | base64 encoded |
| | | |
| maxvals | (implementation dependent) | numeric string |
| | | |
| placemark | (NULL, or used from server | base64 encoded |
| | reply) | |
+----------------+---------------------------------+----------------+
HIT remove (optional)
HIT remove（オプション）
+----------------+----------------------------------------+---------+
| field | value | data |
| | | type |
+----------------+----------------------------------------+---------+
| application | "hip-name-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA-1 hash of a name | base64 |
| | | encoded |
| | | |
| value_hash | SHA-1 hash of HDRR (value used during | base64 |
| | publish) to remove | encoded |
| | | |
| ttl_sec | lifetime for the remove should be | numeric |
| | greater than or equal to the amount of | string |
| | time remaining for the record | |
| | | |
| secret | secret value (SHA-1 of this was used | base64 |
| | in put) | encoded |
+----------------+----------------------------------------+---------+
The key for both HIT publish and lookup is the SHA-1 hash of the name. The name does not necessarily need to be associated with a valid DNS or host name. It does not need to be related to the Domain Identifier found in the HI TLV. OpenDHT limits the keys to 20 bytes in length, so the SHA-1 hash is used to allow arbitrary name lengths.
ヒットパブリッシュとルックアップの両方のキーは、名前のSHA-1ハッシュです。名前は、必ずしも有効なDNSまたはホスト名に関連付ける必要はありません。Hi TLVで見つかったドメイン識別子に関連する必要はありません。Opendhtはキーを長さ20バイトに制限するため、SHA-1ハッシュは任意の名前の長さを許可するために使用されます。
The value used in the publish and lookup response MUST be the base64- encoded HDRR containing the HIT, and MAY include an optional certificate. The HIT MUST be stored in the Sender's HIT field in the HDRR header and is a 128-bit value that can be identified as a HIT both by its length and by the ORCHID prefix [RFC4843] that it starts with.
パブリッシュおよびルックアップ応答で使用される値は、ヒットを含むbase64-エンコードされたHDRRでなければならず、オプションの証明書が含まれる場合があります。ヒットは、HDRRヘッダーの送信者のヒットフィールドに保存する必要があり、その長さと蘭のプレフィックス[RFC4843]の両方でヒットとして識別できる128ビット値です。
If a certificate is included in this HIT record, the name used for the DHT key MUST be listed in the certificate. The CERT parameter is defined in [RFC6253]. The Common Name (CN) field from the Distinguished Name (DN) of the X.509.v3 certificate MUST be used. The server can hash this name to verify it matches the DHT key.
このヒットレコードに証明書が含まれている場合、DHTキーに使用される名前を証明書にリストする必要があります。CERTパラメーターは[RFC6253]で定義されています。X.509.V3証明書の著名な名前（DN）からの一般名（CN）フィールドを使用する必要があります。サーバーは、この名前をハッシュして、DHTキーと一致することを確認できます。
The ttl_sec field specifies the number of seconds requested by the client that the entry should be stored by the DHT server, which is implementation or policy dependent.
TTL_SECフィールドは、エントリが実装またはポリシーに依存するDHTサーバーによって保存する必要があることをクライアントが要求する秒数を指定します。
The secret_hash is an optional field used with HIT publish if the value will later be removed with an rm operation. It is RECOMMENDED that clients support these rm operations for the values they publish. The secret_hash contains the base64-encoded SHA-1 hash of some secret value known only to the publishing host. A different secret value SHOULD be used for each put because rm requests are visible on the network. The max_vals and placemark fields used with the HIT lookup are defined by the get XML-RPC interface.
Secret_Hashは、RM操作で値が後で削除される場合、ヒットパブリッシュで使用されるオプションのフィールドです。クライアントが公開する価値に対してこれらのRM操作をサポートすることをお勧めします。Secret_Hashには、出版ホストのみに知られている秘密の価値のbase64エンコードSHA-1ハッシュが含まれています。RM要求がネットワーク上に表示されるため、PUTごとに別の秘密値を使用する必要があります。ヒットルックアップで使用されるMAX_VALSおよびPLACEMARKフィールドは、GET XML-RPCインターフェイスによって定義されます。
Given a HIT, a lookup returns the IP address of the peer. The address is contained in a LOCATOR TLV inside the HDRR, along with other validation data. This interface has publish, lookup, and remove operations. A summary of these three operations is listed below. The abbreviated notation refers to the HIP parameter types; for example, HIP_SIG is the HIP signature parameter defined by [RFC5201]. The details of these DHT operations is then described in greater detail.
ヒットを与えられた場合、ルックアップはピアのIPアドレスを返します。アドレスは、他の検証データとともに、HDRR内のロケーターTLVに含まれています。このインターフェイスには、操作を公開、検索、削除します。これら3つの操作の概要を以下に示します。短縮された表記は、股関節パラメータータイプを指します。たとえば、HIP_SIGは[RFC5201]で定義された股関節シグネチャパラメーターです。これらのDHT操作の詳細については、詳細に説明します。
HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY)
put(HIT_KEY, HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG),
[SHA-1(secret)])
rm(HIT_KEY, SHA-1(HDRR), secret)
The HDRR is defined in Section 3. It contains one or more locators that the peer wants to publish, a sequence number, the peer's Host Identity, an optional certificate, and a signature over the contents.
HDRRはセクション3で定義されています。ピアが公開したい1つまたは複数のロケーター、シーケンス番号、ピアのホストID、オプションの証明書、およびコンテンツの署名が含まれています。
The HIT_KEY is comprised of the last 100 bits of the HIT appended with 60 zero bits. This is the portion of the HIT used as a DHT key. The last 100 bits are used to avoid uneven distribution of the stored values across the DHT servers. The HIT's ORCHID Prefix (defined by [RFC4843]) is comprised of the first 28 bits, and this prefix is dropped because it is the same for all HITs, which would cause this uneven distribution. Zero padding is appended to this 100-bit value to fill the length required by the DHT, 160 bits total.
HIT_KEYは、60ゼロビットで追加されたヒットの最後の100ビットで構成されています。これは、DHTキーとして使用されるヒットの部分です。最後の100ビットは、DHTサーバー全体の保存値の不均一な分布を回避するために使用されます。ヒットのオーキッドプレフィックス（[RFC4843]で定義）は最初の28ビットで構成されており、この接頭辞はすべてのヒットで同じであるため、この不均一な分布を引き起こすため、ドロップされます。ゼロパディングは、この100ビット値に追加され、DHTで必要な長さ、合計160ビットが埋められます。
Address publish
アドレス公開
+----------------+----------------------------------------+---------+
| field | value | data |
| | | type |
+----------------+----------------------------------------+---------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | HIT_KEY | base64 |
| | | encoded |
| | | |
| value | HDRR(LOCATOR, SEQ, HOST_ID, [CERT], | base64 |
| | HIP_SIG), with the IP address to be | encoded |
| | published contained in the LOCATOR TLV | |
| | in the HDRR, along with other | |
| | validation data | |
| | | |
| ttl_sec | amount of time HDRR should be valid, | numeric |
| | or the lifetime of the preferred | string |
| | address, a value from 0-604800 seconds | |
| | | |
| secret_hash | optional SHA-1 hash of secret value | base64 |
| | | encoded |
+----------------+----------------------------------------+---------+
Address lookup
アドレスルックアップ
+----------------+---------------------------------+----------------+
| field | value | data type |
+----------------+---------------------------------+----------------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | HIT_KEY | base64 encoded |
| | | |
| maxvals | (implementation dependent) | numeric string |
| | | |
| placemark | (NULL, or used from server | base64 encoded |
| | reply) | |
+----------------+---------------------------------+----------------+
Address remove (optional)
アドレス削除（オプション）
+----------------+-------------------------------------+------------+
| field | value | data type |
+----------------+-------------------------------------+------------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | HIT_KEY | base64 |
| | | encoded |
| | | |
| value_hash | SHA-1 hash of HDRR (value used | base64 |
| | during publish) to remove | encoded |
| | | |
| ttl_sec | old address lifetime | numeric |
| | | string |
| | | |
| secret | secret value (SHA-1 of this was | base64 |
| | used in put) | encoded |
+----------------+-------------------------------------+------------+
The application and client_library fields are used for logging in OpenDHT. The client_library may vary between different implementations, specifying the name of the XML-RPC library used or the application that directly makes XML-RPC calls.
ApplicationおよびClient_Libraryフィールドは、Opendhtでのログに使用されます。client_libraryは、使用されるXML-RPCライブラリの名前を指定し、XML-RPC呼び出しを直接作成するアプリケーションを指定して、実装が異なる場合があります。
The key used with the address lookup and with publishing the address is the HIT_KEY as defined above, 160 bits base64 encoded [RFC2045]. The value used in the publish and lookup response is the base64- encoded HDRR containing one or more LOCATORs.
アドレスルックアップとアドレスの公開で使用されるキーは、上記の160ビットBase64エンコード[RFC2045]のHIT_KEYです。パブリッシュおよびルックアップ応答で使用される値は、1つ以上のロケーターを含むbase64-エンコードされたHDRRです。
The ttl_sec field used with address publish indicates the time-to-live (TTL). This is the number of seconds for which the entry will be stored by the DHT. The TTL SHOULD be set to the number of seconds remaining in the address lifetime.
アドレスパブリッシュで使用されるTTL_SECフィールドは、寿命までの時間（TTL）を示します。これは、エントリがDHTによって保存される秒数です。TTLは、アドレスの寿命に残っている秒数に設定する必要があります。
The secret_hash is an optional field that MAY be used with address publish if the value will later be removed with an rm operation. The secret_hash contains the base64-encoded SHA-1 hash of some secret value that MUST be known only to the publishing host. Clients SHOULD include the secret_hash and remove outdated values to reduce the amount of data the peer needs to handle. A different secret value SHOULD be used for each put because rm requests are visible on the network.
Secret_Hashは、RM操作で値を後で削除する場合、アドレスパブリッシュで使用できるオプションのフィールドです。Secret_Hashには、出版ホストにのみ知られている必要がある秘密の価値のbase64エンコードSha-1ハッシュが含まれています。クライアントは、Secret_Hashを含め、時代遅れの値を削除して、ピアが処理する必要があるデータの量を減らす必要があります。RM要求がネットワーク上に表示されるため、PUTごとに別の秘密値を使用する必要があります。
The max_vals and placemark fields used with address lookup are defined by the get XML-RPC interface. The get operation needs to know the maximum number of values to retrieve. The placemark is a value found in the server reply that causes the get to continue to retrieve values starting where it left off.
アドレスルックアップで使用されるMAX_VALSおよびPLACEMARKフィールドは、GET XML-RPCインターフェイスによって定義されます。GET操作は、取得する値の最大数を知る必要があります。PlaceMarkは、サーバーの返信にある値であり、Getが中断されたところから始まる値を取得し続けます。
Below are some suggestions of when a HIP implementation MAY want to use the HIT and address lookup services.
以下は、股関節の実装がヒットおよびアドレスルックアップサービスを使用したい場合のいくつかの提案です。
To learn of a peer's HIT, a host might first consult DNS using the peer's hostname if the DNS server supports the HIP resource record defined by [RFC5205]. Sometimes hosts do not have administrative authority over their DNS entries and/or the DNS server is not able to support HIP resource records. Hosts may want to associate other non-DNS names with their HITs. For these and other reasons, a host MAY use the HIT publish service defined in Section 4.1. The peer HIT may be learned by performing a DHT lookup of such a name.
ピアのヒットを知るために、DNSサーバーが[RFC5205]で定義された股関節リソースレコードをサポートしている場合、ホストは最初にピアのホスト名を使用してDNSに相談することができます。ホストがDNSエントリに対する管理機関を持っていない場合があり、DNSサーバーは股関節リソースレコードをサポートできない場合があります。ホストは、他の非DNS名をヒットに関連付けたい場合があります。これらおよびその他の理由により、ホストはセクション4.1で定義されているヒットパブリッシュサービスを使用する場合があります。ピアヒットは、そのような名前のDHTルックアップを実行することで学習できます。
Once a peer HIT is learned or configured, an address lookup MAY be performed so that the LOCATORs can be cached and immediately available for when an association is requested. Implementations might load a list of peer HITs on startup, resulting in several lookups that can take some time to complete.
ピアヒットが学習または構成されたら、アドレスルックアップを実行して、ロケーターをキャッシュし、関連付けが要求されたときにすぐに利用できるようにすることができます。実装は、スタートアップにピアヒットのリストをロードする可能性があり、その結果、完了するまでに時間がかかるいくつかの検索が行われる可能性があります。
However, cached LOCATORs may quickly become obsolete, depending on how often the peer changes its preferred address. Performing an address lookup before sending the I1 may be needed. At this time, the latency of a lookup may be intolerable, and a lookup could instead be performed after the I1 retransmission timer fires -- when no R1 reply has been received -- to detect any change in address.
ただし、ピアが優先アドレスを変更する頻度に応じて、キャッシュされたロケーターはすぐに時代遅れになる可能性があります。i1を送信する前にアドレスルックアップを実行する必要がある場合があります。現時点では、ルックアップの遅延は耐えられない場合があり、代わりにI1再送信タイマーの火災が発生した後、R1の返信がない場合、住所の変更を検出した後、ルックアップを実行できます。
A HIP host SHOULD publish its preferred LOCATORs upon startup, so other hosts may determine where it is reachable. The host SHOULD periodically refresh its HDRR entry because each entry carries a TTL and will eventually expire. Also, when there is a change in the preferred address, usually associated with sending UPDATE packets with included locator parameters, the host SHOULD update its HDRR with the DHT. The old HDRR SHOULD be removed using the rm operation, if a secret value was used in the put.
HIPホストは、スタートアップ時に優先ロケーターを公開する必要があるため、他のホストが到達可能な場所を決定する場合があります。各エントリがTTLを持ち、最終的に期限切れになるため、ホストはHDRRエントリを定期的に更新する必要があります。また、通常のロケーターパラメーターを含む更新パケットを送信することに通常関連付けられている優先アドレスに変更がある場合、ホストはDHTでHDRRを更新する必要があります。PUTで秘密の値が使用されている場合は、RM操作を使用して古いHDRRを削除する必要があります。
Addresses from the private address space SHOULD NOT be published to the DHT. If the host is located behind a NAT, for example, the host could publish the address of its Rendezvous Server (RVS, from [RFC5204]) to the DHT if that is how it is reachable. In this case, however, a peer could instead simply use the RVS field of the NATed host's HIP DNS record, which would eliminate a separate DHT lookup.
プライベートアドレススペースからのアドレスをDHTに公開しないでください。たとえば、ホストがNATの後ろにある場合、ホストは、Rendezvousサーバー（RVS、[RFC5204]からRVS）のアドレスをDHTに公開できます。ただし、この場合、ピアは代わりに、Nated Hostの股関節DNSレコードのRVSフィールドを使用するだけで、別のDHTルックアップが排除されます。
A HIP host SHOULD also publish its HIT upon startup or whenever a new HIT is configured, for use with the HIT lookup service, if desired. The host SHOULD first check if the name already exists in the DHT by performing a lookup, to avoid interfering with an existing name-to-HIT mapping. The name-to-HIT binding needs to be refreshed periodically before the TTL expires.
ヒップホストは、スタートアップ時にヒットを公開するか、必要に応じてヒットルックアップサービスで使用するために、新しいヒットが構成されている場合はいつでも公開する必要があります。ホストは、既存の名前からヒットマッピングへの干渉を避けるために、ルックアップを実行することにより、最初に名前がDHTに既に存在するかどうかを確認する必要があります。TTLの有効期限が切れる前に、名前からヒットのバインディングを定期的に更新する必要があります。
When publishing data to the DHT server, care should be taken to check the response from the server. The server may respond with an "over capacity" code, indicating that its resources are too burdened to honor the given size and TTL. The host SHOULD then select another server for publishing or reduce the TTL and retry the put operation.
データをDHTサーバーに公開するときは、サーバーからの応答を確認するように注意する必要があります。サーバーは「容量過剰」コードで応答する場合があり、そのリソースが与えられたサイズとTTLを尊重するには重荷がかかりすぎていることを示しています。ホストは、TTLを公開または削減するために別のサーバーを選択し、プット操作を再試行する必要があります。
The DHT put operation does not replace existing values. If a host does not remove its old HDRR before adding another, several entries may be present. A client performing a lookup SHOULD determine the most recent address based on the Update ID from the SEQ TLV of the HDRR. The order of values returned in the server's response may not be guaranteed. Before performing each put, a host SHOULD remove its old HDRR data using the rm operation.
DHTプット操作は、既存の値を置き換えません。別の追加を追加する前にホストが古いHDRRを削除しない場合、いくつかのエントリが存在する場合があります。ルックアップを実行するクライアントは、HDRRのSEQ TLVからの更新IDに基づいて最新のアドレスを決定する必要があります。サーバーの応答で返される値の順序は保証されない場合があります。各プットを実行する前に、ホストはRM操作を使用して古いHDRRデータを削除する必要があります。
In the case of the HIT lookup service, there is nothing preventing different hosts from publishing the same name. A lookup performed on this name will return multiple HITs that belong to different devices. The server may enforce a policy that requires clients to include a certificate when publishing a HIT, and only store HITs with a name that has been authorized by some trusted certificate. Otherwise, this is an unmanaged free-for-all service, and it is RECOMMENDED that a host simply pick another name.
ヒットルックアップサービスの場合、異なるホストが同じ名前を公開するのを妨げるものはありません。この名前で実行されるルックアップは、異なるデバイスに属する複数のヒットを返します。サーバーは、ヒットを公開するときにクライアントが証明書を含めることを要求するポリシーを実施し、信頼できる証明書によって承認された名前のヒットのみを保存することができます。それ以外の場合、これは管理されていない自由なサービスであり、ホストが単に別の名前を選択することをお勧めします。
Selecting an appropriate DHT server to use is not covered here. If a particular server becomes unavailable, the connect will timeout and some server selection algorithm SHOULD be performed, such as trying the next server in a configured list. OpenDHT formerly provided a DNS-based anycast service; when one performed a lookup of "opendht.nyuld.net", it returned the two nearest OpenDHT servers.
使用する適切なDHTサーバーを選択することは、ここではカバーされていません。特定のサーバーが利用できなくなった場合、Connectはタイムアウトになり、構成されたリストで次のサーバーを試すなど、一部のサーバー選択アルゴリズムを実行する必要があります。Opendhtは以前、DNSベースのAnycastサービスを提供していました。「opendht.nyuld.net」の検索を実行すると、2つの最も近いOpendhtサーバーを返しました。
The latency involved with the DHT put and get operations should be considered when using these services with HIP. The calls rely on servers that may be located across the Internet and may trigger communications between servers that add delay. The DHT operations themselves may be slow to produce a response.
これらのサービスをHIPで使用する場合は、DHT PutおよびGet操作に伴う遅延を考慮する必要があります。呼び出しは、インターネット上にあるサーバーに依存しており、遅延を追加するサーバー間の通信をトリガーする可能性があります。DHT操作自体は、応答を生成するのが遅い場合があります。
The maximum size of 1024 bytes for the value field will limit the maximum size of the Host Identity and certificates that may be used within the HDRR.
値フィールドの最大サイズ1024バイトは、HDRR内で使用できるホストIDの最大サイズと証明書を制限します。
There are two classes of attacks on this information exchange between the host and DHT server: attacks on the validity of the information provided by the DHT to the host (such as a spoofed DHT response) and attacks on the DHT records themselves (such as polluted records for a given key). Without the server performing some measure of verification, not much can be done to prevent these attacks.
ホストとDHTサーバーの間でこの情報交換には2つのクラスの攻撃があります。DHTがホストに提供する情報の有効性（スプーフィングDHT応答など）とDHTレコード自体の攻撃（汚染などの攻撃があります。特定のキーのレコード）。サーバーがある程度の検証を実行しないと、これらの攻撃を防ぐためにはあまりできません。
For the HIT lookup based on a name (Section 4.1), there are no guarantees on the validity of the HIT. Users concerned with the validity of HITs found in the DHT SHOULD simply exchange HITs out-of-band with peers. Including a signature will not help here because the HIT that identifies the Host Identity for signing is not known ahead of time. A certificate MAY be included with the HIT, which guarantees that the name used for the lookup has been authorized by some third-party authority. Which certificates are considered trusted is a local policy issue.
名前（セクション4.1）に基づくヒット検索の場合、ヒットの有効性に関する保証はありません。DHTで見つかったヒットの妥当性に関係するユーザーは、単にピアと帯域外のヒットを交換する必要があります。署名を含めることは、署名のためのホストのアイデンティティを識別するヒットが事前に知られていないため、ここでは役に立ちません。証明書はヒットに含まれる場合があります。これは、ルックアップに使用される名前がサードパーティの当局によって承認されていることを保証します。信頼されていると見なされる証明書は、現地のポリシーの問題です。
For the address lookup based on HIT (Section 4.2), the validity of the DHT response MUST be checked with the HOST_ID and SIGNATURE parameters in the HDRR. A HIP initiating host SHOULD also validate the DHT response after the R1 message is received during a HIP exchange. The Host Identity provided in the R1 can be hashed to obtain a HIT that MUST be checked against the original HIT. However, a legacy OpenDHT service without server modifications does not prevent an attacker from polluting the DHT records for a known HIT, thereby causing a denial-of-service attack, since server validation is not performed.
ヒット（セクション4.2）に基づくアドレスルックアップの場合、DHT応答の有効性は、HDRRのhost_idおよび署名パラメーターで確認する必要があります。HIP開始ホストは、股関節交換中にR1メッセージが受信された後、DHT応答を検証する必要があります。R1で提供されるホストIDは、元のヒットに対してチェックする必要があるヒットを取得するためにハッシュすることができます。ただし、サーバーの変更を伴わないレガシーOpendHTサービスでは、攻撃者が既知のヒットのためにDHTレコードを汚染することを妨げず、サーバーの検証が実行されないため、サービス拒否攻撃を引き起こします。
Relying solely on client validation may be harmful. An attacker can replay the put packets containing the signed HDRR, possibly causing stale or invalid information to exist in the DHT. If an attacker replays the signed put message and changes some aspect each time, and if the server is not performing signature and HIT validation, there could be a multitude of invalid entries stored in the DHT. When a client retrieves these records, it would need to perform signature and HIT verification on each one, which could cause unacceptable amounts of delay or computation.
クライアントの検証のみに依存することは有害な場合があります。攻撃者は、署名されたHDRRを含むPutパケットを再生でき、おそらくDHTに古くなったり無効な情報が存在したりする可能性があります。攻撃者が署名されたプットメッセージを再生し、毎回いくつかの側面を変更し、サーバーが署名を実行していない場合、検証をヒットした場合、DHTに保存されている多数の無効なエントリが存在する可能性があります。クライアントがこれらのレコードを取得すると、署名を実行し、それぞれの検証をヒットする必要があります。これにより、許容できない量の遅延または計算が発生する可能性があります。
To protect against this type of attack, the DHT server SHOULD perform signature and HIT verification of each put operation as described in Section 3. Another option would be the server running HIP itself and requiring client authentication with a HIP association before accepting HDRR puts. Further validation would be only accepting HIT and address records from the association bound to the same HIT.
このタイプの攻撃から保護するために、DHTサーバーは署名を実行し、セクション3で説明した各プット操作の検証をヒットする必要があります。別のオプションは、HDRRプットを受け入れる前に、ヒップ自体を実行し、股関節関連でクライアント認証を必要とするサーバーです。さらなる検証は、同じヒットに縛られた協会のヒットとアドレスの記録のみを受け入れることになります。
Performing server-side verification adds to the processing burden of the DHT server and may be a source for a denial-of-service attack. Requiring a HIP association before accepting HDRR puts may help here. The HIT verification is less computationally intensive by design, using a hash algorithm. Certificate validation (for name lookups) and signature verification (for HDRRs) may cause unacceptable amounts of computation. A server may rate limit the number of puts that it allows.
サーバー側の検証を実行すると、DHTサーバーの処理負担が追加され、サービス拒否攻撃のソースになる可能性があります。HDRRプットを受け入れる前に股関節関連を必要とすることは、ここで役立つ場合があります。ヒット検証は、ハッシュアルゴリズムを使用して、設計により計算的に集中的ではありません。証明書の検証（名前検索用）および署名検証（HDRRの場合）は、受け入れられない量の計算を引き起こす可能性があります。サーバーは、許可するプットの数を制限する場合があります。
The SHA-1 message digest algorithm is used in two ways in this document, and the security of using this algorithm should be considered within the context of [RFC6194]. The first use is with the OpenDHT put and remove operations, described in Section 2, and the second is to reduce the size of the name string for the HIT lookup service in Section 4.1.
SHA-1メッセージダイジェストアルゴリズムは、このドキュメントで2つの方法で使用されており、[RFC6194]のコンテキスト内でこのアルゴリズムを使用するセキュリティを考慮する必要があります。最初の使用は、セクション2で説明されているOpenDht Putおよび削除操作でのものであり、2番目はセクション4.1のヒットルックアップサービスの名前文字列のサイズを縮小することです。
The first use is intended to protect the secret values used to store records in the DHT as described by the OpenDHT interface. An attacker would be able to remove a record, after capturing the plaintext put, if a secret value could be found that produces the same secret hash. The purpose of this document is to maintain interoperable compatibility with that interface, which prescribes the use of SHA-1. Future revisions of that interface should consider hash algorithm agility. The OpenDHT FAQ states that future support for other hash algorithms is planned.
最初の使用は、OpenDHTインターフェイスで説明されているように、DHTにレコードを保存するために使用される秘密の値を保護することを目的としています。攻撃者は、同じ秘密のハッシュを生成する秘密の値が見つかった場合、プレーンテキストをキャプチャした後、レコードを削除することができます。このドキュメントの目的は、SHA-1の使用を規定するインターフェイスとの相互運用可能な互換性を維持することです。そのインターフェイスの将来の改訂は、ハッシュアルゴリズムの俊敏性を考慮する必要があります。Opendht FAQは、他のハッシュアルゴリズムに対する将来のサポートが計画されていると述べています。
The second use of the SHA-1 algorithm is to reduce the arbitrarily sized name strings to fit the fixed OpenDHT key size. No security properties of the SHA-1 algorithm are used in this context.
SHA-1アルゴリズムの2番目の使用は、固定されたOpenDhtキーサイズに合わせて任意にサイズの名前文字列を減らすことです。このコンテキストでは、SHA-1アルゴリズムのセキュリティプロパティは使用されません。
This document defines a new HIP Packet Type, the "HIP Distributed Hash Table Resource Record (HDRR)". This packet type is defined in Section 3 with a value of 20.
このドキュメントでは、新しい股関節パケットタイプ、「HIP分散ハッシュテーブルリソースレコード（HDRR）」を定義しています。このパケットタイプは、値が20のセクション3で定義されています。
Thanks to Tom Henderson, Samu Varjonen, Andrei Gurtov, Miika Komu, Kristian Slavov, Ken Rimey, Ari Keranen, and Martin Stiemerling for providing comments. Samu most notably contributed the resolver packet and its suggested parameters, which became the HDRR here.
トム・ヘンダーソン、サム・ヴァルヨン、アンドレイ・ガルトフ、ミイカ・コム、クリスチャン・スラヴォフ、ケン・ライミー、アリ・ケラネン、マーティン・スティミーリングにコメントを提供してくれたことに感謝します。Samuは、特にResolver Packetとその提案されたパラメーターに最も顕著に寄与しました。これがここでHDRRになりました。
[OPENDHT] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., Stocia, I., and H. Yu, "OpenDHT: A Public DHT Service and Its Uses", Proceedings of ACM SIGCOMM 2005, August 2005.
[Opendht] Rhea、S.、Godfrey、B.、Karp、B.、Kubiatowicz、J.、Ratnasamy、S.、Shenker、S.、Stocia、I。、およびH. Yu、 "Opendht：A Public DHTサービスその用途」、ACM Sigcomm 2005の議事録、2005年8月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[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月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843] Nikander、P.、Laganier、J。、およびF. Dupont、「オーバーレイのルーティング可能な暗号ハッシュ識別子（蘭）のIPv6プレフィックス」、RFC 4843、2007年4月。
[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月。
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, April 2008.
[RFC5205] Nikander、P。およびJ. Laganier、「ホストIDプロトコル（HIP）ドメイン名システム（DNS）拡張機能」、RFC 5205、2008年4月。
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[RFC6194] Polk、T.、Chen、L.、Turner、S。、およびP. Hoffman、「SHA-0およびSHA-1メッセージダイジェストアルゴリズムのセキュリティ上の考慮事項」、RFC 6194、2011年3月。
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011.
[RFC6253] Heer、T。およびS. Varjonen、「ホストIDプロトコル証明書」、RFC 6253、2011年5月。
[HIT2IP] Ponomarev, O. and A. Gurtov, "Embedding Host Identity Tags Data in DNS", Work in Progress, July 2009.
[HIT2IP] Ponomarev、O。およびA. Gurtov、「DNSのホストIDタグデータの埋め込み」、2009年7月の作業。
[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月。
Author's Address
著者の連絡先
Jeff Ahrenholz The Boeing Company P.O. Box 3707 Seattle, WA USA
ボーイングカンパニーP.O.ボックス3707シアトル、ワシントンアメリカ
EMail: jeffrey.m.ahrenholz@boeing.com