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
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）サービスでホスト識別プロトコル（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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットResearch Task Force（IRTF）のHIP研究グループのコンセンサスを表しています。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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].
ホストアイデンティティプロトコル（HIP）[RFC5201]は分散ハッシュテーブル（のDHT）に基づいて、ルックアップ・サービスから利益を得ることができます。ホストのアイデンティティの名前空間は階層的なドメインネームシステム（DNS）とは対照的に、公開鍵からなる、平坦です。これらのキーは、ハッシュされ、ホスト識別タグのような大きな乱数を表示される（ヒット）、形成するために接頭辞が付いています。現在の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の一つ自由に利用可能な実装がOpenDHTという名前の無料サービスを形成するために、プラネット・サーバーにデプロイされているJavaベースのソフトウェアである竹DHT、です。 OpenDHTは、任意のデータを格納および取得するための任意のプログラムのためにインターネット経由で利用可能でした。 OpenDHTは取得、プットを搭載し、明確に定義された拡張マークアップ言語、リモートプロシージャ呼び出し（XML-RPC）インターフェイスを使用して、操作を削除します。 DHTとして実装されていないがOpenLookupは、このOpenDHTインターフェースと互換性のオープンソース・ソフトウェアの別の展開です。この文書では、さまざまなHIPの実験者が相互運用可能な方法で検索サービスを利用することができるように、このOpenDHTインタフェースを使用するHIPのための一般的な方法について説明します。
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 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.
この文書では、IRTFのHIP研究グループ（RG）の製品です。 HIP研究グループは、このインタフェース仕様は椅子を含む少なくとも6人のRGのメンバーによる文書レビューに基づいて、実験的RFCとして公開され、実装経験に基づくべきであるという合意に達しました。この文書は、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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サーバの公開展開だった、と竹プロジェクトがサーバー上で実行されている実際のソフトウェアを提供したが、ここで我々が使用していますOpenDHT、のみを参照します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.
それは研究コミュニティ内で使用される、よく知られ、一般に公開DHTだったのでOpenDHTが選ばれました。そのインターフェイスは、簡単にHIPの開発者によって実装することができ、簡単な、標準ベースのプロトコルを提供しています。この文書では、ここで説明するだけのサービスとサーバーが使用されるべきではなく、容易に利用可能なツールを選択すると、これらのサービスの経験を積むための出発点として機能するものであることを指示することを目指していません。
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バイトまでとすることができます。値がアップ詳細については604800秒（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.
三つのRPC操作がサポートされています、入れて取得し、RM（削除します）。プットは、そのハッシュインデックスとしてキーを使用して格納される値を引き起こし、キーと値のパラメータで呼び出されます。あなたが鍵を持っているし、値を取得する際に、重要なパラメータで呼び出されます。 RMは秘密値、プット操作に含まれたのハッシュと一緒に削除された値のハッシュと呼ばれています。
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:
put操作は、次の引数を取ります。
+----------------+--------------------------------------+
| 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、および2 - サーバーは、整数で応答します。戻りコード3は、「失敗」を示し、セクション3を参照して、署名とヒットの検証を行う改変OpenDHTサーバに使用されます。
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、および2 - サーバーは、整数で応答します。
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と目印フィールドは、値の最大数を取得するためと反復は結果を得るためのものです。
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「成功」のリターンコードは、成功したプットを示したり、操作を削除します。 「容量オーバー」1のリターンコードは、クライアントがサーバー上であまりにも多くのストレージスペースを使用していることを意味します。 2の戻り値「もう一度試しては、」一時的な問題がプットを受け入れることからサーバーを防ぐため、クライアントは、put操作を再試行する必要があることを示します。
In the sections that follow, specific uses for these DHT operations and their XML fields are suggested for use with HIP.
以下のセクションでは、これらのDHTの操作とそのXMLフィールドの特定の用途は、HIPで使用するために提案されています。
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つのルックアップサービスは、このセクションで定義されたHIP DHTリソースレコード（HDRR）を使用します。このレコードは、HIP制御パケットに類似の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]で定義される。）このパケットの符号化は、このデータは、実際にDHTサーバによって記憶され、検索されたリソースレコードではなく、上で送信されたパケットであっても、便宜として使用されますHIPプロトコルデーモンによってワイヤー。このHDRR形式は[RFC5205]で定義されるように、ドメインネームシステムによって使用されるHIPのRRとは異なることに留意されたいです。それは異なっている理由は、それが機能的な観点が異なるレコードであることである：ここでは、クエリのキーがある一方、DNSで、クエリのキーは完全修飾ドメイン名（FQDN）で、戻り値はHITですヒット。
HIP header values for the HDRR:
HDRR用HIPヘッダ値：
HIP Header: Packet Type = 20 DHT Resource Record SRC HIT = Sender's HIT DST HIT = NULL
HIPヘッダー：パケットタイプ= 20 DHTリソースレコードSRCのHIT =送信者のHIT DSTのHIT = NULL
HDRR used with HIT lookup: HIP ( [CERT] )
HITルックアップとともに使用HDRR：HIP（[CERT]）
HDRR used with address lookup: HIP ( LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIGNATURE )
HIP（LOCATOR、SEQ、HOST_ID、[CERT]、HIP_SIGNATURE）：アドレスルックアップとともに使用HDRR
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.
イニシエータのHIT（送信者のHIT、SRCのHIT）は、ホストが検索サービスを使用して利用できるようにしたいHITに設定しなければなりません。 HIT検索サービスでは、これは、get操作で返された情報の主な作品です。アドレス検索サービスでは、このHITはDHTのキーとして使用HIT_KEYを導出するために使用されるものと同じでなければなりません。データは、任意のホストのために意図されているのでレスポンダのHIT（ReceiverのHIT、DSTのHIT）は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.
HIT検索サービスで使用される唯一の他のTLVは、DHTのキーとして使用されている名前を検証するための証明書を含むオプションのCERTパラメータです。 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.
LOCATORパラメタは、ホストが検索サービスを使用して利用できるようにしたいアドレスが含まれています。ホストは、例えば、現在の優先IPv4とIPv6ロケータを公開してもよい（MAY）。
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つずつインクリメントされます。ホストは、それが再起動しても、各HITのために使用された最後の更新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パラメータは、送信者のHITに対応するホストのアイデンティティが含まれています。 （このパラメータの符号化は[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.
レコードを受けHIPクライアントが送信者と含まLOCATORパラメータを検証することができるようにHOST_IDパラメータとHIP_SIGNATUREパラメータがHDRRで使用しなければなりません。 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ため無効である場合、取得した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で送信者のHITは、ルックアップとホストIDの検証に使用されるキーと一致しなければなりません。受信機のHITは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サーバは、竹DHTソフトウェアとOpenDHTインターフェイスを持つ新しいリターンコードにいくつかの修正を加えて、署名とHOST_IDを確認することができます。 PUTにおける署名は、所与のホストID（公開鍵）を使用して確認する必要があり、ルックアップキーとして提供HIT_KEYは[RFC4843]で定義されたオーバーレイルーティング可能な暗号ハッシュ識別子（ORCHID）生成方法によれば、このホストIDが一致しなければなりません。署名やHIT検証のいずれかの場合
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に記録されなければならない、とサーバが故障コードを返し、失敗しました。エラーコードは、3の値と、OpenDHTによって定義されていない追加的な戻りコードです。
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.
レコードのこのサーバー側の検証は、サービス拒否攻撃の源をもたらす可能性があります。サーバーポリシーは、アクティブなHIPの関連性を持つようにクライアントを必要とする可能性があります。さらなる議論については、セクション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で使用するためのHIT検索とアドレス検索サービスを定義します。 HITルックアップは、ピアのHITを発見するためにテキスト名を使用しています。アドレスルックアップは、現在のアドレスを発見するためにピアのHITを使用しています。
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パラメータの種類を指します。例えば、HIP_SIGは[RFC5201]で定義されたHIPシグニチャパラメータです。
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.
HIT検索サービスは、名前を指定し、ピアのホスト識別タグを返します。名前は、FQDN、ホスト名、または他のいくつかの別名であるべきです。このHITはHDRRの送信者のHITフィールドで発見されました。 [RFC5201]に記載されているようにHITは、公開鍵ベースのホストアイデンティティのハッシュです。 HITとは異なり、名前のないセキュリティプロパティは、ありません。オプションの証明書は、セキュリティのいくつかの指標を提供する、名前を検証するために、レコードに含まれるかもしれません。これは信頼できるとみなされた証明書は、ローカルポリシーの問題です。このサービスは、従来のDNSサーバがHIPリソースレコードをサポートしていない時に使用することを意図している、またはホストは、独自の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.
アドレス検索は、与えられたHITためHDRRにロケータや他の検証データを返します。 HIPアソシエーションが（ない日和見モード）を開始する前に、HIPホストはピアのHITとピアが到達可能で、現在のアドレスを知っている必要があります。多くの場合、ホスト名のルックアップを使用してDNSルックアップを介して利用可能なHITする事前設定、[RFC5205]、または本文書で定義されたHIT検索サービスを使用して取得。 HIPモビリティ[RFC5206]を使用すると、IPアドレスがロケータとして使用することができると頻繁に変更されることがあります。ホストIDとHITは、比較的一定のままであり、確実にホストを識別するために使用することができるので、HITは、アドレスを格納し、検索するための適切な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.
アドレスレコードは、名前とHIT結合は比較的一定のままでなければならない一方で、より頻繁に変化することが予想されるため、これら二つの別々のルックアップではなく1の定義されています。アドレスレコードがアクティブピア1時間ごとに更新されている間たとえば、ローカルポリシーは、日常的に結合名前とHITをチェックし指定することもできます。また、2つのレコードのクライアントとサーバの検証は、特定のホストアイデンティティ/ HITのベアラによって生成署名を使用して名前とアドレス検索を検証する証明書を使用してHIT検索して、異なっています。
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.
これらのサービスは、各HIPホストで必要な事前設定の量を減らします。ピアはまた、それらのアドレスを公開することにより、参加される場合、各ピアのアドレスは、もはや、事前に知られてする必要はありません。ピアは名前と彼らのヒット曲を公開することを選択した場合、ピアのヒットも、もはや事前設定を必要としません。しかし、これらの検索にサービスを提供するために利用できる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ハッシュを考えると、ルックアップは、ピアのHITを返します。 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
HITは、パブリッシュ
+----------------+----------------------------------------+---------+
| 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
HIT検索
+----------------+---------------------------------+----------------+
| 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削除（オプション）
+----------------+----------------------------------------+---------+
| 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.
両方のHITが発行し、ルックアップのキーは、名前の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.
公開ルックアップ応答に使用される値がHITを含むbase64-エンコードさHDRRなければなりません、と任意の証明書を含むかもしれません。 HITはHDRRヘッダ内の送信者HITフィールドに格納する必要があり、その長さによって、それが始まること蘭接頭辞[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.
証明書は、このHITレコードに含まれている場合は、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操作で除去される場合に発行HITで使用されるオプションのフィールドです。クライアントが公開値に対するこれらRMの操作をサポートすることが推奨されます。 secret_hashは唯一の出版ホストに知られているいくつかの秘密の値のbase64エンコードSHA-1ハッシュが含まれています。 RM要求がネットワーク上で表示されるので、異なる秘密の値は、各プットのために使用されるべきです。 HITの検索で使用max_valsと目印フィールドは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.
HITを考えると、ルックアップは、ピアのIPアドレスを返します。アドレスは、他の検証データと共に、HDRR内部LOCATOR TLVに含まれています。このインタフェースは、検索を公開して、操作を削除しました。これらの3つの操作の概要は以下のとおりです。略記表記はHIPパラメータの種類を指します。例えば、HIP_SIGは[RFC5201]で定義されたHIPシグニチャパラメータです。これら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は、それは、ピアは、シーケンス番号、ピアのホストID、オプションの証明書、および内容を超える署名を公開したい一の以上のロケータが含まれている3節で定義されています。
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ゼロ個の・ビットが付加HITの最後の100ビットで構成されています。これは、DHTのキーとして使用HITの部分です。最後の100ビットは、DHTのサーバー間で保存された値の偏在を回避するために使用されます。 HITのORCHIDプレフィックス（[RFC4843]で定義される）は、最初の28ビットで構成され、それは、この不均一な分布を引き起こす全てのヒットに対して同じであるため、この接頭辞がドロップされます。ゼロパディングは、DHT、160ビットの合計によって必要とされる長さを埋めるために、この100ビット値に付加されます。
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.
アプリケーションと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.
上記で定義されたように、アドレスルックアップとし、アドレスを公開して使用されるキーはHIT_KEYで、160ビットのBASE64符号化された[RFC2045]。公開ルックアップ応答に使用される値は、一つ以上のロケータを含む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要求がネットワーク上で表示されるので、異なる秘密の値は、各プットのために使用されるべきです。
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と目印フィールドはGET XML-RPCインターフェイスによって定義されています。 get操作は、取得する値の最大数を知る必要があります。目印は、それが中断したところから始まる値を取得し続けるには、getの原因となるサーバの応答で見つかった値です。
Below are some suggestions of when a HIP implementation MAY want to use the HIT and address lookup services.
以下は、HIP実装がHITし、アドレス検索サービスを使用したい場合があり際のいくつかの提案があります。
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]で定義されたHIPリソースレコードをサポートしている場合、ピアのHITを知るために、ホストは最初のピアのホスト名を使用してDNSを参照すると良いかもしれません。時々、ホストは、DNSエントリに対する管理権限を持っていないおよび/またはDNSサーバは、HIPリソースレコードをサポートすることができません。ホストは、彼らのヒット曲を持つ他の非DNS名を関連付けることがあります。これらおよびその他の理由により、ホストは、HITはセクション4.1で定義されたサービスを公開し使用するかもしれません。ピアHITは、そのような名前の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.
ピアHITが学習または設定されるとロケータがキャッシュされ、関連付けが要求されたときのためにすぐに利用できるように、アドレスのルックアップが行われてもよいです。実装が完了するまでにしばらく時間がかかることがあり、いくつかの検索結果として、起動時にピア・ヒットのリストを読み込むことがあります。
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に使用された場合、古いHDRRは、RMの操作を使用して削除する必要があります。
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の背後に配置されている場合はそれはそれが到達可能であるかである場合、例えば、ホストは、DHTへのランデブーサーバ（RVSから、[RFC5204]）のアドレスを公開することができます。しかし、この場合には、ピアではなく、単に別のDHT検索を排除するNAT変換ホストのHIPのDNSレコードのRVSフィールドを、使用することができます。
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.
HIPホストはまた、起動時またはいつでも必要に応じて新しいHITは、HIT検索サービスで使用するために、構成されたそのHITを公開する必要があります。名前が既存の名前とHITマッピングとの干渉を避けるために、ルックアップを実行することにより、DHTに存在する場合、ホストは最初にチェックする必要があります。 TTLの期限が切れる前に定期的に更新される名前とHIT結合ニーズ。
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を削減し、put操作を再試行する必要があります。
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のput操作は、既存の値を置き換えるものではありません。ホストが別のものを追加する前に、その古い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.
HIT検索サービスの場合は、同じ名前を公開から別のホストを防止することは何もありません。この名前に対して実行検索は異なるデバイスに属している複数のヒットを返します。サーバーは、いくつかの信頼できる証明書により許可された名前を持つHITを公開するときに、証明書が含まれるように、クライアントが要求するポリシー、および唯一の店舗のヒットを強制することがあります。そうでなければ、これは管理対象外の自由のために、すべてのサービスであり、そしてホストが、単純に別の名前を選ぶことが推奨されます。
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サーバを選択すると、ここではカバーされていません。特定のサーバーが使用できなくなった場合、接続がタイムアウトし、いくつかのサーバ選択アルゴリズムは、設定されたリスト内の次のサーバーを試して、実行する必要があります。 OpenDHTは、以前はDNSベースのエニーキャストサービスを提供します。 1は「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.
レイテンシーDHTに関与入れてもらう操作はHIPでこれらのサービスを使用する際に考慮されるべきです。呼び出しは、インターネットを介して配置することができるサーバに依存しており、遅延を追加し、サーバ間の通信をトリガすることができます。 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節）に基づいて、HITの検索については、HITの有効性に関する保証はありません。 DHTで見つかったヒットの妥当性に関するユーザーは単に仲間とアウトオブバンドのヒットを交換する必要があります。署名のためのホストIDを識別HITは事前に知られていないので、署名を含めると、ここで助けにはなりません。証明書は、ルックアップのために使用される名前は、いくつかのサードパーティ機関によって認可されていることを保証する、HITに含まれるかもしれません。これは信頼できるとみなされた証明書は、ローカルポリシーの問題です。
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.
HIT（4.2節）に基づいてアドレスのルックアップのために、DHT応答の妥当性は、HDRRでHOST_IDとSIGNATUREパラメータをチェックしなければなりません。 R1メッセージがHIP交換中に受信された後にホストを開始HIPもDHTの応答を検証する必要があります。 R1で提供ホストIDは、元のHITに対してチェックしなければなりませんHITを得るためにハッシュされることができます。サーバの検証が行われないので、サーバ変更せず、レガシーOpenDHTサービスは、それによって、サービス拒否攻撃を引き起こし、公知HITため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.
クライアント検証のみに依存することは有害である可能性があります。攻撃者は、おそらくDHTに存在する失効または無効な情報を引き起こし、署名されたHDRRを含むPUTパケットを再生することができます。攻撃者は、署名された置くメッセージを再生し、いくつかの態様を毎回変更し、サーバは、署名とヒットの検証を行っていない場合、DHTに格納された無効なエントリが多数存在することができれば。クライアントは、これらのレコードを取得すると、それは遅延や計算の許容できない量を引き起こす可能性が各1、上の署名とHIT検証を実行する必要があります。
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サーバは、それぞれの署名とHIT検証を実行しなければならないもう一つのオプションは、サーバーがHIP自体を実行しているとHDRRプットを受け入れる前に、HIP協会とクライアント認証を要求することになる第3節で説明したように操作を置きます。さらなる検証が同じHITにバインドされた関連付けからHITとアドレスの記録を受け入れるだけでしょう。
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プットを受け入れる前に、HIPの関連付けを要求することはここに助けるかもしれません。 HIT検証はハッシュアルゴリズムを使用して、設計することにより、集中少ない計算量です。 （HDRRs用）（名前のルックアップのための）証明書の検証と署名検証は、計算の許容できない量を引き起こす可能性があります。サーバーは、それが可能にプットの数をレート制限があります。
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に入れて、削除操作であり、第二は、4.1節でHIT検索サービスの名前の文字列のサイズを小さくすることです。
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よくある質問は、他のハッシュアルゴリズムのための将来のサポートが計画されていると述べています。
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）分散HIP」を定義します。このパケットタイプは、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 Varjonen、アンドレイGurtov、Miikaこむ、クリスチャンSlavov、ケンRimey、アリKeranen、そしてマーティンStiemerlingに感謝します。 Samuは最も顕著ここ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]レア、S.、ゴッド、B.、カープ、B.、Kubiatowicz、J.、Ratnasamy、S.、Shenker、S.、Stocia、I.、およびH.優、「OpenDHT：公共サービス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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[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月。
[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.デュポン、RFC 4843、2007年4月 "オーバーレイルーティング可能な暗号ハッシュ識別子（ORCHID）のIPv6プレフィックス"。
[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月。
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, April 2008.
[RFC5205] Nikander、P.およびJ. Laganier、 "ホストアイデンティティプロトコル（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]ポーク、T.、陳、L.、ターナー、S.、およびP.ホフマン、 "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、 "ホストアイデンティティプロトコル証明書"、RFC 6253、2011年5月。
[HIT2IP] Ponomarev, O. and A. Gurtov, "Embedding Host Identity Tags Data in DNS", Work in Progress, July 2009.
[HIT2IP]ポノマリョフ、O.およびA. Gurtov、 "DNSにホストアイデンティティタグデータを埋め込む"、進歩、2009年7月での作業。
[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月。
Author's Address
著者のアドレス
Jeff Ahrenholz The Boeing Company P.O. Box 3707 Seattle, WA USA
ジェフAhrenholzザ・ボーイング社の私書箱ボックス3707シアトル、WA USA
EMail: jeffrey.m.ahrenholz@boeing.com
メールアドレス：jeffrey.m.ahrenholz@boeing.com