RFC5205 日本語訳
5205 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions.P. Nikander, J. Laganier. April 2008. (Format: TXT=34799 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Nikander
Request for Comments: 5205 Ericsson Research NomadicLab
Category: Experimental J. Laganier
DoCoMo Euro-Labs
April 2008
Nikanderがコメントのために要求するワーキンググループP.をネットワークでつないでください: 5205年のエリクソン研究NomadicLabカテゴリ: 実験的なJ.Laganier DoCoMoユーロ研究室2008年4月
Host Identity Protocol (HIP) Domain Name System (DNS) Extension
ホストアイデンティティのプロトコルの(クール)のドメインネームシステム(DNS)拡大
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs).
このドキュメントはドメインネームシステムのための新しいリソース記録(RR)(DNS)と、Host Identityプロトコルと共にそれをどう使用するかを(HIP)指定します。 このRRはHIPノードにDNSにHost Identity(HI、ノード公共の秘密鍵組の公共のコンポーネント)、Host Identity Tag(HIT、公開鍵の端が欠けている細切れ肉料理)、およびランデブーサーバのDomain Names(RVSs)を格納させます。
Nikander & Laganier Experimental [Page 1] RFC 5205 HIP DNS Extension April 2008
クールな[1ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Simple Static Singly Homed End-Host . . . . . . . . . . . 5
3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Using the DNS with HIP . . . . . . . . . . . . . . 8
4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 8
4.2. Initiating Connections Based on DNS Names . . . . . . . . 8
5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 9
5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 9
5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 9
5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . . 10
5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10
5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10
6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . . 12
8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 13
8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative references . . . . . . . . . . . . . . . . . . . 14
11.2. Informative references . . . . . . . . . . . . . . . . . . 15
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 コンベンションは本書では.3 3を使用しました。 用法シナリオ. . . . . . . . . . . . . . . . . . . . . . . 4 3.1。 簡単な静電気は単独で終わりホスト.53.2に家へ帰りました。 モバイル終わりホスト.6 4。 ヒップ. . . . . . . . . . . . . . 8 4.1があるDNSを使用する概観。 DNS. . . . . . . . . . . 8 4.2にHI、ヒット、およびRVSを格納します。 コネクションズを開始すると、名前. . . . . . . . 8 5はDNSに基づきました。 クールなRR格納形式. . . . . . . . . . . . . . . . . . . . 9 5.1。 長さの形式. . . . . . . . . . . . . . . . . . . . 9 5.2を打ってください。 PKアルゴリズム形式. . . . . . . . . . . . . . . . . . . 9 5.3。 PK長さの形式. . . . . . . . . . . . . . . . . . . . . 10 5.4。 形式. . . . . . . . . . . . . . . . . . . . . . . . 10 5.5を打ってください。 公開鍵形式. . . . . . . . . . . . . . . . . . . . 10 5.6。 ランデブーサーバは.106をフォーマットします。 クールなRRプレゼンテーション形式. . . . . . . . . . . . . . . . . . 10 7。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 12 8.1。 不安定なクールなRR. . . . . . . . 12 8.2をいじっている攻撃者。 細切れ肉料理とヒット衝突. . . . . . . . . . . . . . . . . 13 8.3。 DNSSEC. . . . . . . . . . . . . . . . . . . . . . . . . . 13 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 13 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 14 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 14 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 15
Nikander & Laganier Experimental [Page 2] RFC 5205 HIP DNS Extension April 2008
クールな[2ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
1. Introduction
1. 序論
This document specifies a new resource record (RR) for the Domain Name System (DNS) [RFC1034], and how to use it with the Host Identity Protocol (HIP) [RFC5201]. This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public- private key pair), Host Identity Tag (HIT, a truncated hash of its HI), and the Domain Names of its rendezvous servers (RVSs) [RFC5204].
このドキュメントはドメインネームシステム(DNS)[RFC1034]と、Host Identityプロトコル(HIP)と共にそれをどう使用するか[RFC5201]ためには新しいリソース記録(RR)を指定します。 このRRはHIPノードにDNSにHost Identity(HI、ノード公立の秘密鍵組の公共のコンポーネント)、Host Identity Tag(HIT、HIの端が欠けている細切れ肉料理)、およびランデブーサーバ(RVSs)のDomain Names[RFC5204]を格納させます。
Currently, most of the Internet applications that need to communicate with a remote host first translate a domain name (often obtained via user input) into one or more IP address(es). This step occurs prior to communication with the remote host, and relies on a DNS lookup.
現在、最初にリモートホストとコミュニケートする必要があるインターネットアプリケーションの大部分はドメイン名(ユーザ入力でしばしば得る)を1つ以上のIPアドレス(es)に翻訳します。 このステップは、リモートホストとのコミュニケーションの前に起こって、DNSルックアップを当てにします。
With HIP, IP addresses are intended to be used mostly for on-the-wire communication between end hosts, while most Upper Layer Protocols (ULP) and applications use HIs or HITs instead (ICMP might be an example of an ULP not using them). Consequently, we need a means to translate a domain name into an HI. Using the DNS for this translation is pretty straightforward: We define a new HIP resource record. Upon query by an application or ULP for a name to IP address lookup, the resolver would then additionally perform a name to HI lookup, and use it to construct the resulting HI to IP address mapping (which is internal to the HIP layer). The HIP layer uses the HI to IP address mapping to translate HIs and HITs into IP addresses and vice versa.
HIPと共に、ほとんど有線通信の終わりのホストにIPアドレスが使用されることを意図します、ほとんどのUpper Layerプロトコル(ULP)とアプリケーションが代わりにHIsかHITsを使用しますが(ICMPは彼らを使用しないULPに関する例であるかもしれません)。 その結果、私たちはドメイン名をHIに翻訳する手段を必要とします。 この翻訳にDNSを使用するのはかなり簡単です: 私たちは新しいHIPリソース記録を定義します。 IPアドレスルックアップへの名前のためのアプリケーションかULPによる質問のときに、レゾルバは、次に、さらに、HIルックアップに名前を実行して、IPアドレス・マッピングに結果として起こるHIを組み立てるのにそれを使用するでしょう(HIP層に内部です)。 HIP層は、逆もまた同様にHIsとHITsをIPアドレスに翻訳するのにIPアドレス・マッピングにHIを使用します。
The HIP Rendezvous Extension [RFC5204] allows a HIP node to be reached via the IP address(es) of a third party, the node's rendezvous server (RVS). An Initiator willing to establish a HIP association with a Responder served by an RVS would typically initiate a HIP exchange by sending an I1 towards the RVS IP address rather than towards the Responder IP address. Consequently, we need a means to find the name of a rendezvous server for a given host name.
HIP Rendezvous Extension[RFC5204]は、第三者(ノードのランデブーサーバ(RVS))のIPアドレス(es)でHIPノードに達するのを許容します。 RVSによって役立たれているResponderとのHIP協会を設立しても構わないと思っているInitiatorは、Responder IPアドレスに向かってというよりむしろRVS IPアドレスに向かってI1を送ることによって、HIP交換を通常起こすでしょう。 その結果、私たちは与えられたホスト名に関してランデブーサーバの名前を見つける手段を必要とします。
This document introduces the new HIP DNS resource record to store the Rendezvous Server (RVS), Host Identity (HI), and Host Identity Tag (HIT) information.
このドキュメントは、Rendezvous Server(RVS)、Host Identity(HI)とHost Identity Tag(HIT)情報を格納するために新しいHIP DNSリソース記録を紹介します。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Nikander & Laganier Experimental [Page 3] RFC 5205 HIP DNS Extension April 2008
クールな[3ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
3. Usage Scenarios
3. 用法シナリオ
In this section, we briefly introduce a number of usage scenarios where the DNS is useful with the Host Identity Protocol.
このセクションでは、私たちは簡潔に、DNSがHost Identityプロトコルによって役に立つ多くの用法シナリオを紹介します。
With HIP, most applications and ULPs are unaware of the IP addresses used to carry packets on the wire. Consequently, a HIP node could take advantage of having multiple IP addresses for fail-over, redundancy, mobility, or renumbering, in a manner that is transparent to most ULPs and applications (because they are bound to HIs; hence, they are agnostic to these IP address changes).
HIPに、ほとんどのアプリケーションとULPsがワイヤの上にパケットを運ぶのに使用されるIPアドレスに気づきません。 その結果、HIPノードはフェイルオーバーのための複数のIPアドレスを持っているか、冗長、移動性、または番号を付け替えることを利用するかもしれません、ほとんどのULPsとアプリケーションに見え透いた方法で(それらはHIsに縛られます; したがって、彼らがこれらのIPアドレス変化に不可知論者である、)
In these situations, for a node to be reachable by reference to its Fully Qualified Domain Name (FQDN), the following information should be stored in the DNS:
これらの状況で、ノードがFully Qualified Domain Name(FQDN)の参照で届いているように、以下の情報はDNSに格納されるべきです:
o A set of IP address(es) via A [RFC1035] and AAAA [RFC3596] RR sets
(RRSets [RFC2181]).
o A[RFC1035]とAAAA[RFC3596]RRを通した1セットのIPアドレス(es)は(RRSets[RFC2181])を設定します。
o A Host Identity (HI), Host Identity Tag (HIT), and possibly a set
of rendezvous servers (RVS) through HIP RRs.
o Host Identity(HI)、Host Identity Tag(HIT)、およびことによるとHIP RRsを通した1セットのランデブーサーバ(RVS)。
When a HIP node wants to initiate communication with another HIP node, it first needs to perform a HIP base exchange to set up a HIP association towards its peer. Although such an exchange can be initiated opportunistically, i.e., without prior knowledge of the Responder's HI, by doing so both nodes knowingly risk man-in-the- middle attacks on the HIP exchange. To prevent these attacks, it is recommended that the Initiator first obtain the HI of the Responder, and then initiate the exchange. This can be done, for example, through manual configuration or DNS lookups. Hence, a new HIP RR is introduced.
HIPノードが別のHIPノードとのコミュニケーションを開始したがっているとき、それは、最初に、同輩に向かってHIP協会を設立するためにHIP塩基置換を実行する必要があります。 すなわち、便宜主義的で、予備知識なしにResponderのHIについてそのような交換を起こすことができますが、故意にそう両方のノードをすることによって、中の男性を危険にさらしてください、-、-中央はHIP交換のときに攻撃されます。 これらの攻撃を防ぐために、Initiatorが最初にResponderのHIを得て、次に、交換を起こすのは、お勧めです。 例えば、手動の構成かDNSルックアップを通してこれができます。 したがって、新しいHIP RRを導入します。
When a HIP node is frequently changing its IP address(es), the natural DNS latency for propagating changes may prevent it from publishing its new IP address(es) in the DNS. For solving this problem, the HIP Architecture [RFC4423] introduces rendezvous servers (RVSs) [RFC5204]. A HIP host uses a rendezvous server as a rendezvous point to maintain reachability with possible HIP initiators while moving [RFC5206]. Such a HIP node would publish in the DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up- to-date with its current set of IP addresses.
HIPノードが頻繁にIPアドレス(es)を変えているとき、変化を伝播するための生まれながらのDNS潜在は、それがDNSで新しいIPアドレス(es)を発行するのを防ぐかもしれません。 この問題を解決するために、HIP Architecture[RFC4423]はランデブーサーバ(RVSs)[RFC5204]を紹介します。 ランデブーが[RFC5206]を動かしている間、可能なHIP創始者がいる可到達性を維持するために指すとき、HIPホストはランデブーサーバを使用します。 そのようなHIPノードはこれまで現在のIPアドレスでRVSを上がるように保っている間、DNSでHIP RRのRVSドメイン名を発行するでしょう。
When a HIP node wants to initiate a HIP exchange with a Responder, it will perform a number of DNS lookups. Depending on the type of implementation, the order in which those lookups will be issued may vary. For instance, implementations using HIT in APIs may typically first query for HIP resource records at the Responder FQDN, while
HIPノードがResponderとのHIP交換を起こしたがっているとき、それは多くのDNSルックアップを実行するでしょう。 実現のタイプに頼っていて、それらのルックアップが発行されるオーダーは異なるかもしれません。 例えば、APIでHITを使用する実現は最初にHIPのためにResponder FQDNでのリソース記録について通常質問するかもしれません。
Nikander & Laganier Experimental [Page 4] RFC 5205 HIP DNS Extension April 2008
クールな[4ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
those using an IP address in APIs may typically first query for A and/or AAAA resource records.
APIでIPアドレスを使用する人は最初に、A、そして/または、AAAAリソースのために記録について通常質問するかもしれません。
In the following, we assume that the Initiator first queries for HIP resource records at the Responder FQDN.
以下では、私たちは、Initiatorが最初にHIPのためにResponder FQDNでのリソース記録について質問すると思います。
If the query for the HIP type was responded to with a DNS answer with RCODE=3 (Name Error), then the Responder's information is not present in the DNS and further queries for the same owner name SHOULD NOT be made.
タイプがDNSがRCODE=3(名義のError)、Responderの情報が現在でないその時でDNSに答えるaで反応したHIPのための質問と同じ所有者名前SHOULD NOTのためのさらなる質問であるなら、作られてください。
In case the query for the HIP records returned a DNS answer with RCODE=0 (No Error) and an empty answer section, it means that no HIP information is available at the responder name. In such a case, if the Initiator has been configured with a policy to fallback to opportunistic HIP (initiating without knowing the Responder's HI) or plain IP, it would send out more queries for A and AAAA types at the Responder's FQDN.
HIP記録のための質問がRCODE=0(Errorがない)と空の答え部によるDNS答えを返すといけなかったので、それは、どんなHIP情報も応答者名で利用可能でないことを意味します。 このような場合には、Initiatorが方針によって便宜主義的なHIP(ResponderのHIを知らないで、開始する)か明瞭なIPへの後退に構成されたなら、Aのための、より多くの質問を出すでしょう、そして、AAAAはResponderのFQDNでタイプします。
Depending on the combinations of answers, the situations described in Section 3.1 and Section 3.2 can occur.
答えの組み合わせによって、セクション3.1とセクション3.2で説明された状況は起こることができます。
Note that storing HIP RR information in the DNS at an FQDN that is assigned to a non-HIP node might have ill effects on its reachability by HIP nodes.
非HIPノードに割り当てられるFQDNにDNSのHIP RR情報を格納すると害がHIPノードによって可到達性に持たれているかもしれないことに注意してください。
3.1. Simple Static Singly Homed End-Host
3.1. 簡単な静電気は単独でホストを終わらせて家へ帰りました。
A HIP node (R) with a single static network attachment, wishing to be reachable by reference to its FQDN (www.example.com), would store in the DNS, in addition to its IP address(es) (IP-R), its Host Identity (HI-R) and Host Identity Tag (HIT-R) in a HIP resource record.
FQDN(www.example.com)の参照で届くことを願っていて、ただ一つの静的なネットワーク付属のHIPノード(R)はHIPリソース記録にDNS IPに加えてそのアドレス(es)(IP-R)、Host Identity(HI-R)、およびHost Identity Tag(HIT-R)を格納するでしょう。
An Initiator willing to associate with a node would typically issue the following queries:
ノードと交際しても構わないと思っているInitiatorは以下の質問を通常発行するでしょう:
o QNAME=www.example.com, QTYPE=HIP
o QNAME=www.example.com、QTYPE=ヒップ
o (QCLASS=IN is assumed and omitted from the examples)
o (QCLASS=INは例から想定されて、省略されます)
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with the HIT and HI (e.g., HIT-R and HI-R) of the Responder in the answer section, but no RVS.
答え部にもかかわらず、どんなRVSでもResponderのHITとHI(例えば、HIT-RとHI-R)とRCODE=0と1HIP RRsがあるDNSパケットを返しません。
Nikander & Laganier Experimental [Page 5] RFC 5205 HIP DNS Extension April 2008
クールな[5ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
o QNAME=www.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA
o QNAME=www.example.com、QTYPE=A QNAME=www.example.com、QTYPE=AAAA
Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs containing IP address(es) of the Responder (e.g., IP-R) in the answer section.
1RCODE=0とAかAAAA RRsが答え部にResponder(例えば、IP-R)のIPアドレス(es)を保管であっている中のパケットをDNSに返します。
Caption: In the remainder of this document, for the sake of keeping
diagrams simple and concise, several DNS queries and answers
are represented as one single transaction, while in fact
there are several queries and answers flowing back and
forth, as described in the textual examples.
以下と見出しをつけてください。 このドキュメントの残りでは、簡単で簡潔にダイヤグラムを保管することのためにいくつかのDNS質問と答えは1つの単一取引として表されます、前後に流れるいくつかの質問と答えが事実上ありますが、原文の例で説明されるように。
[HIP? A? ]
[www.example.com] +-----+
+-------------------------------->| |
| | DNS |
| +-------------------------------| |
| | [HIP? A? ] +-----+
| | [www.example.com]
| | [HIP HIT-R HI-R ]
| | [A IP-R ]
| v
+-----+ +-----+
| |--------------I1------------->| |
| I |<-------------R1--------------| R |
| |--------------I2------------->| |
| |<-------------R2--------------| |
+-----+ +-----+
[クールですか? A? ] [www.example.com] +-----+ +-------------------------------->|、|、|、| DNS| | +-------------------------------| | | | [クールですか? A? ] +-----+ | | [www.example.com]| | [クールなヒットR高R]| | [IP-R]| +に対して-----+ +-----+ | |--------------I1------------->|、|、| I| <、-、-、-、-、-、-、-、-、-、-、-、--R1--------------| R| | |--------------I2------------->|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、--R2--------------| | +-----+ +-----+
Static Singly Homed Host
静電気が単独で家へ帰った、ホスト
The Initiator would then send an I1 to the Responder's IP addresses (IP-R).
そして、InitiatorはResponderのIPアドレス(IP-R)にI1を送るでしょう。
3.2. Mobile end-host
3.2. モバイル終わりホスト
A mobile HIP node (R) wishing to be reachable by reference to its FQDN (www.example.com) would store in the DNS, possibly in addition to its IP address(es) (IP-R), its HI (HI-R), HIT (HIT-R), and the domain name(s) of its rendezvous server(s) (e.g., rvs.example.com) in HIP resource record(s). The mobile HIP node also needs to notify its rendezvous servers of any change in its set of IP address(es).
FQDN(www.example.com)の参照で届くようになりたがっている可動のHIPノード(R)はHIPリソース記録にDNSと、ことによるとIPアドレス(es)(IP-R)、HI(HI-R)、HIT(HIT-R)、およびランデブーのドメイン名に加えてサーバ(例えば、rvs.example.com)を格納するでしょう。 また、可動のHIPノードは、IPアドレス(es)のセットにおけるどんな変化のランデブーサーバにも通知する必要があります。
An Initiator willing to associate with such a mobile node would typically issue the following queries:
そのような可動のノードと交際しても構わないと思っているInitiatorは以下の質問を通常発行するでしょう:
o QNAME=www.example.com, QTYPE=HIP
o QNAME=www.example.com、QTYPE=ヒップ
Nikander & Laganier Experimental [Page 6] RFC 5205 HIP DNS Extension April 2008
クールな[6ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
Which returns a DNS packet with RCODE=0 and one or more HIP RRs with the HIT, HI, and RVS domain name(s) (e.g., HIT-R, HI-R, and rvs.example.com) of the Responder in the answer section.
ResponderのHIT、HIとRVSドメイン名(例えば、HIT-R、HI-R、およびrvs.example.com)が答え部にある状態で、RCODE=0と1HIP RRsがあるDNSパケットを返します。
o QNAME=rvs.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA
o QNAME=rvs.example.com、QTYPE=A QNAME=www.example.com、QTYPE=AAAA
Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs containing IP address(es) of the Responder's RVS (e.g., IP-RVS) in the answer section.
1RCODE=0とAかAAAA RRsが答え部にResponderのRVS(例えば、IP-RVS)のIPアドレス(es)を保管であっている中のパケットをDNSに返します。
[HIP? ]
[www.example.com]
[クールな]? [www.example.com]
[A? ]
[rvs.example.com] +-----+
+----------------------------------------->| |
| | DNS |
| +----------------------------------------| |
| | [HIP? ] +-----+
| | [www.example.com ]
| | [HIP HIT-R HI-R rvs.example.com]
| |
| | [A? ]
| | [rvs.example.com]
| | [A IP-RVS ]
| |
| | +-----+
| | +------I1----->| RVS |-----I1------+
| | | +-----+ |
| | | |
| | | |
| v | v
+-----+ +-----+
| |<---------------R1------------| |
| I |----------------I2----------->| R |
| |<---------------R2------------| |
+-----+ +-----+
[A]? [rvs.example.com] +-----+ +----------------------------------------->|、|、|、| DNS| | +----------------------------------------| | | | [クールな]? +-----+ | | [www.example.com]| | [HIP HIT-R HI-R rvs.example.com]| | | | [A]? | | [rvs.example.com]| | [IP-RVS]| | | | +-----+ | | +------I1----->| RVS|-----I1------+ | | | +-----+ | | | | | | | | | | v| +に対して-----+ +-----+ | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--R1------------| | | I|----------------I2----------->| R| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--R2------------| | +-----+ +-----+
Mobile End-Host
モバイル終わりホスト
The Initiator would then send an I1 to the RVS IP address (IP-RVS). Following, the RVS will relay the I1 up to the mobile node's IP address (IP-R), which will complete the HIP exchange.
そして、InitiatorはRVS IPアドレス(IP-RVS)にI1を送るでしょう。 続いて、RVSはI1を可動のノードのIPアドレス(IP-R)までリレーするでしょう。(それは、HIP交換を終了するでしょう)。
Nikander & Laganier Experimental [Page 7] RFC 5205 HIP DNS Extension April 2008
クールな[7ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
4. Overview of Using the DNS with HIP
4. ヒップがあるDNSを使用する概観
4.1. Storing HI, HIT, and RVS in the DNS
4.1. DNSの打たれたHIを格納して、RVS
For any HIP node, its Host Identity (HI), the associated Host Identity Tag (HIT), and the FQDN of its possible RVSs can be stored in a DNS HIP RR. Any conforming implementation may store a Host Identity (HI) and its associated Host Identity Tag (HIT) in a DNS HIP RDATA format. HI and HIT are defined in Section 3 of the HIP specification [RFC5201].
どんなHIPノードに関してはも、DNS HIP RRにHost Identity(HI)、関連Host Identity Tag(HIT)、および可能なRVSsのFQDNを格納できます。 どんな従う実現もDNS HIP RDATA形式でHost Identity(HI)とその関連Host Identity Tag(HIT)を格納するかもしれません。 HIとHITはHIP仕様[RFC5201]のセクション3で定義されます。
Upon return of a HIP RR, a host MUST always calculate the HI- derivative HIT to be used in the HIP exchange, as specified in Section 3 of the HIP specification [RFC5201], while the HIT possibly embedded along SHOULD only be used as an optimization (e.g., table lookup).
HIP仕様[RFC5201]のセクション3で指定されるようにHIP交換に使用されて、ホストは、期待のためにHITがことによるとずっとSHOULDを埋め込んでいた間、HIP RRの復帰のときに最適化(例えば、索表)として単に使用されるようにHIの派生しているHITをいつも見込まなければなりません。
The HIP resource record may also contain one or more domain name(s) of rendezvous server(s) towards which HIP I1 packets might be sent to trigger the establishment of an association with the entity named by this resource record [RFC5204].
また、HIPリソース記録はHIP I1パケットがこのリソース記録[RFC5204]によって命名される実体との協会の設立の引き金となるように送られるかもしれないランデブーサーバの1つ以上のドメイン名を含むかもしれません。
The rendezvous server field of the HIP resource record stored at a given owner name MAY include the owner name itself. A semantically equivalent situation occurs if no rendezvous server is present in the HIP resource record stored at that owner name. Such situations occur in two cases:
与えられた所有者名で格納されたHIPリソース記録のランデブーサーバ分野は所有者名自体を含むかもしれません。 どんなランデブーサーバもその所有者名で格納されたHIPリソース記録に存在していないなら、意味的に同等な状況は起こります。 そのような状況は2つの場合で起こります:
o The host is mobile, and the A and/or AAAA resource record(s)
stored at its host name contain the IP address(es) of its
rendezvous server rather than its own one.
o ホストは可動です、そして、ホスト名で格納されたA、そして/または、AAAAリソース記録はそれ自身の1よりむしろランデブーサーバのIPアドレス(es)を含んでいます。
o The host is stationary, and can be reached directly at the IP
address(es) contained in the A and/or AAAA resource record(s)
stored at its host name. This is a degenerated case of rendezvous
service where the host somewhat acts as a rendezvous server for
itself.
o ホストを、静止していて、直接Aに含まれたIPアドレス(es)、そして/または、ホスト名で格納されたAAAAリソース記録で連絡できます。 これはホストがそれ自体のためのランデブーサーバとしていくらか務める堕落されたランデブーサービスのそうです。
An RVS receiving such an I1 would then relay it to the appropriate Responder (the owner of the I1 receiver HIT). The Responder will then complete the exchange with the Initiator, typically without ongoing help from the RVS.
そして、そのようなI1を受けるRVSは適切なResponder(I1受信機HITの所有者)にそれをリレーするでしょう。 そして、ResponderはRVSからInitiatorと、通常、進行中の助けなしで交換を終了するでしょう。
4.2. Initiating Connections Based on DNS Names
4.2. DNS名に基づくコネクションズを開始します。
On a HIP node, a Host Identity Protocol exchange SHOULD be initiated whenever a ULP attempts to communicate with an entity and the DNS lookup returns HIP resource records.
HIPノードで、Host IdentityプロトコルはSHOULDを交換します。ULPが、実体で交信するのを試みて、DNSルックアップがHIPリソース記録を返すときはいつも、開始されてください。
Nikander & Laganier Experimental [Page 8] RFC 5205 HIP DNS Extension April 2008
クールな[8ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
5. HIP RR Storage Format
5. クールなRR格納形式
The RDATA for a HIP RR consists of a public key algorithm type, the HIT length, a HIT, a public key, and optionally one or more rendezvous server(s).
HIP RRのためのRDATAは公開鍵アルゴリズムタイプから成ります、HITの長さ、HIT、公開鍵、そして、任意に、ものか以上がサーバを集合させます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HIT length | PK algorithm | PK length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HIT ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+ +
| Public Key |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Rendezvous Servers ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HITの長さ| PKアルゴリズム| PKの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~、を打ってください。| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+ + | 公開鍵| ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ ランデブーサーバ~| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+
The HIT length, PK algorithm, PK length, HIT, and Public Key fields are REQUIRED. The Rendezvous Servers field is OPTIONAL.
HITの長さ、PKアルゴリズム、PKの長さ、HIT、およびPublic Key分野はREQUIREDです。 Rendezvous Servers分野はOPTIONALです。
5.1. HIT Length Format
5.1. 長さの形式を打ってください。
The HIT length indicates the length in bytes of the HIT field. This is an 8-bit unsigned integer.
HITの長さはHIT分野のバイトで表現される長さを示します。 これは8ビットの符号のない整数です。
5.2. PK Algorithm Format
5.2. PKアルゴリズム形式
The PK algorithm field indicates the public key cryptographic algorithm and the implied public key field format. This is an 8-bit unsigned integer. This document reuses the values defined for the 'algorithm type' of the IPSECKEY RR [RFC4025].
PKアルゴリズム分野は公開鍵暗号アルゴリズムと暗示している公開鍵フィールド形式を示します。 これは8ビットの符号のない整数です。 このドキュメントはIPSECKEY RR[RFC4025]の'アルゴリズムタイプ'のために定義された値を再利用します。
Presently defined values are listed in Section 9 for reference.
現在定義された値は参照のためにセクション9に記載されています。
Nikander & Laganier Experimental [Page 9] RFC 5205 HIP DNS Extension April 2008
クールな[9ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
5.3. PK Length Format
5.3. PK長さの形式
The PK length indicates the length in bytes of the Public key field. This is a 16-bit unsigned integer in network byte order.
PKの長さはPublicキーフィールドのバイトで表現される長さを示します。 これはネットワークバイトオーダーで16ビットの符号のない整数です。
5.4. HIT Format
5.4. 形式を打ってください。
The HIT is stored as a binary value in network byte order.
HITは2進の値としてネットワークバイトオーダーに格納されます。
5.5. Public Key Format
5.5. 公開鍵形式
Both of the public key types defined in this document (RSA and DSA) reuse the public key formats defined for the IPSECKEY RR [RFC4025].
本書では定義された公開鍵タイプ(RSAとDSA)の両方がIPSECKEY RR[RFC4025]のために定義された公開鍵書式を再利用します。
The DSA key format is defined in RFC 2536 [RFC2536].
DSAの主要な書式はRFC2536[RFC2536]で定義されます。
The RSA key format is defined in RFC 3110 [RFC3110] and the RSA key size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025] specification.
RSAの主要な書式はRFC3110[RFC3110]で定義されます、そして、RSAの主要なサイズ限界(4096ビット)はIPSECKEY RR[RFC4025]仕様でリラックスします。
5.6. Rendezvous Servers Format
5.6. ランデブーサーバ形式
The Rendezvous Servers field indicates one or more variable length wire-encoded domain names of rendezvous server(s), as described in Section 3.3 of RFC 1035 [RFC1035]. The wire-encoded format is self- describing, so the length is implicit. The domain names MUST NOT be compressed. The rendezvous server(s) are listed in order of preference (i.e., first rendezvous server(s) are preferred), defining an implicit order amongst rendezvous servers of a single RR. When multiple HIP RRs are present at the same owner name, this implicit order of rendezvous servers within an RR MUST NOT be used to infer a preference order between rendezvous servers stored in different RRs.
Rendezvous Servers分野はランデブーサーバの1つ以上の可変長のワイヤでコード化されたドメイン名を示します、RFC1035[RFC1035]のセクション3.3で説明されるように。 ワイヤでコード化された形式が自己説明であるので、長さは暗黙です。 ドメイン名を圧縮してはいけません。 ランデブーサーバは好みの順に記載されています(すなわち、最初に、ランデブーサーバは好まれます)、独身のRRのランデブーサーバの中で暗黙のオーダーを定義して。 複数のときに、HIP RRsは同じ所有者名で存在しています、ランデブーサーバのこの暗黙の注文。RR MUST NOTの中では、使用されて、異なったRRsに格納されたランデブーサーバの間の好みの命令を推論してください。
6. HIP RR Presentation Format
6. クールなRRプレゼンテーション形式
This section specifies the representation of the HIP RR in a zone master file.
このセクションはゾーン基本ファイルにおける、HIP RRの表現を指定します。
The HIT length field is not represented, as it is implicitly known thanks to the HIT field representation.
それがHIT分野表現のおかげでそれとなく知られているようにHIT長さの分野は表されません。
The PK algorithm field is represented as unsigned integers.
PKアルゴリズム分野は符号のない整数として表されます。
The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a. hex or hexadecimal) of the HIT. The encoding MUST NOT contain whitespaces to distinguish it from the public key field.
HIT分野はHITの[RFC4648](通称十六進法か16進)をコード化するBase16として表されます。 コード化は公開鍵分野とそれを区別する空白を含んではいけません。
Nikander & Laganier Experimental [Page 10] RFC 5205 HIP DNS Extension April 2008
クールな[10ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
The Public Key field is represented as the Base64 encoding [RFC4648] of the public key. The encoding MUST NOT contain whitespace(s) to distinguish it from the Rendezvous Servers field.
Public Key分野は公開鍵の[RFC4648]をコード化するBase64として表されます。 コード化はRendezvous Servers分野とそれを区別する空白を含んではいけません。
The PK length field is not represented, as it is implicitly known thanks to the Public key field representation containing no whitespaces.
PK長さの分野は表されません、それが空白を全く含まないPublicキーフィールド表現のおかげでそれとなく知られているように。
The Rendezvous Servers field is represented by one or more domain name(s) separated by whitespace(s).
Rendezvous Servers分野は空白によって切り離された1つ以上のドメイン名によって表されます。
The complete representation of the HPIHI record is:
HPIHI記録の完全表記は以下の通りです。
IN HIP ( pk-algorithm
base16-encoded-hit
base64-encoded-public-key
rendezvous-server[1]
...
rendezvous-server[n] )
ヒップで(base64が公開カギをコード化しているpk-アルゴリズムbase16がヒットをコード化しているサーバ[1]…ランデブーを集合させているサーバ[n] )
When no RVSs are present, the representation of the HPIHI record is:
どんなRVSsも存在していないとき、HPIHI記録の表現は以下の通りです。
IN HIP ( pk-algorithm
base16-encoded-hit
base64-encoded-public-key )
ヒップで(打たれて、コード化されたpk-アルゴリズムbase16、base64が公開カギをコード化した、)
7. Examples
7. 例
In the examples below, the public key field containing no whitespace is wrapped since it does not fit in a single line of this document.
以下の例では、このドキュメントの単線をうまくはめ込まないので、空白を全く含まない公開鍵分野は包装されます。
Example of a node with HI and HIT but no RVS:
HIがあるノードにもかかわらず、HITにもかかわらず、RVSがない例:
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578
AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D )
www.example.com。 ヒップで(2 200100107B1A74DF365639CC39F1D578AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D)
Example of a node with a HI, HIT, and one RVS:
HI、HIT、および1RVSとのノードに関する例:
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578
AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
rvs.example.com. )
www.example.com。 ヒップで(2 200100107B1A74DF365639CC39F1D578AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D rvs.example.com。)
Nikander & Laganier Experimental [Page 11] RFC 5205 HIP DNS Extension April 2008
クールな[11ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
Example of a node with a HI, HIT, and two RVSs:
HI、HIT、および2RVSsとのノードに関する例:
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578
AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
rvs1.example.com.
rvs2.example.com. )
www.example.com。 ヒップで(2 200100107B1A74DF365639CC39F1D578AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D rvs1.example.com. rvs2.example.com。)
8. Security Considerations
8. セキュリティ問題
This section contains a description of the known threats involved with the usage of the HIP DNS Extension.
このセクションはHIP DNS Extensionの使用法にかかわる知られている脅威の記述を含みます。
In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS Extension allows for the provision of two HIP nodes with the public keying material (HI) of their peer. These HIs will be subsequently used in a key exchange between the peers. Hence, the HIP DNS Extension introduces the same kind of threats that IPSECKEY does, plus threats caused by the possibility given to a HIP node to initiate or accept a HIP exchange using "opportunistic" or "unpublished Initiator HI" modes.
IPSECKEY RR[RFC4025]と同様の方法で、HIP DNS Extensionは公衆が彼らの同輩の材料(HI)を合わせている2つのHIPノードに関する条項を考慮します。 これらのHIsは次に、同輩の間の主要な交換に使用されるでしょう。 したがって、HIP DNS Extensionは同じ種類のIPSECKEYがして、脅威がHIPノードに与えられた可能性でHIP交換が使用していると「便宜主義的な」状態で開始するか、または受け入れることを引き起こした脅威か「未発表のInitiator HI」モードを導入します。
A HIP node SHOULD obtain HIP RRs from a trusted party trough a secure channel ensuring data integrity and authenticity of the RRs. DNSSEC [RFC4033] [RFC4034] [RFC4035] provides such a secure channel. However, it should be emphasized that DNSSEC only offers data integrity and authenticity guarantees to the channel between the DNS server publishing a zone and the HIP node. DNSSEC does not ensure that the entity publishing the zone is trusted. Therefore, the RRSIG signature of the HIP RRSet MUST NOT be misinterpreted as a certificate binding the HI and/or the HIT to the owner name.
A HIPノードSHOULDはRRsのデータ保全と信憑性を確実にする信じられたパーティーくさびa安全なチャンネルからHIP RRsを入手します。 DNSSEC[RFC4033][RFC4034][RFC4035]はそのような安全なチャンネルを提供します。 しかしながら、DNSSECがゾーンを発行するDNSサーバとHIPノードの間のチャンネルにデータ保全と信憑性保証を提供するだけであると強調されるべきです。 DNSSECは、ゾーンを発行する実体が信じられるのを確実にしません。 したがって、所有者名にHI、そして/または、HITを縛る証明書としてHIP RRSetのRRSIG署名を誤解してはいけません。
In the absence of a proper secure channel, both parties are vulnerable to MitM and DoS attacks, and unrelated parties might be subject to DoS attacks as well. These threats are described in the following sections.
適切な安全なチャンネルがないとき、双方はMitMとDoS攻撃に傷つきやすいです、そして、関係ないパーティーはまた、DoS攻撃を受けることがあるかもしれません。 これらの脅威は以下のセクションで説明されます。
8.1. Attacker Tampering with an Insecure HIP RR
8.1. 不安定なクールなRRをいじっている攻撃者
The HIP RR contains public keying material in the form of the named peer's public key (the HI) and its secure hash (the HIT). Both of these are not sensitive to attacks where an adversary gains knowledge of them. However, an attacker that is able to mount an active attack on the DNS, i.e., tampers with this HIP RR (e.g., using DNS spoofing), is able to mount Man-in-the-Middle attacks on the cryptographic core of the eventual HIP exchange (Responder's HIP RR rewritten by the attacker).
HIP RRは命名された同輩の公開鍵のフォーム(HI)とその安全な細切れ肉料理(HIT)の中に材料を合わせる公衆を含みます。 敵がそれらに関する知識を獲得するところでこれらの両方が攻撃に敏感ではありません。 しかしながら、DNSに対する活発な攻撃を仕掛けることができる攻撃者(すなわち、このHIP RR(例えば、DNSスプーフィングを使用する)があるタンパー)は最後のHIP交換(攻撃者によって書き直された応答者のHIP RR)の暗号のコアに対する中央のMan攻撃を仕掛けることができます。
Nikander & Laganier Experimental [Page 12] RFC 5205 HIP DNS Extension April 2008
クールな[12ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
The HIP RR may contain a rendezvous server domain name resolved into a destination IP address where the named peer is reachable by an I1, as per the HIP Rendezvous Extension [RFC5204]. Thus, an attacker able to tamper with this RR is able to redirect I1 packets sent to the named peer to a chosen IP address for DoS or MitM attacks. Note that this kind of attack is not specific to HIP and exists independently of whether or not HIP and the HIP RR are used. Such an attacker might tamper with A and AAAA RRs as well.
HIP RRは命名された同輩がI1で届いている送付先IPアドレスに変えられたランデブーサーバドメイン名を含むかもしれません、HIP Rendezvous Extension[RFC5204]に従って。 したがって、このRRをいじるのにおいて有能な攻撃者はDoSかMitM攻撃のための選ばれたIPアドレスに命名された同輩に送られたI1パケットを向け直すことができます。 この種類の攻撃がHIPに特定でなく、HIPとHIP RRが使用されているかどうかの如何にかかわらず存在することに注意してください。 そのような攻撃者はまた、AとAAAA RRsをいじるかもしれません。
An attacker might obviously use these two attacks in conjunction: It will replace the Responder's HI and RVS IP address by its own in a spoofed DNS packet sent to the Initiator HI, then redirect all exchanged packets to him and mount a MitM on HIP. In this case, HIP won't provide confidentiality nor Initiator HI protection from eavesdroppers.
攻撃者は接続詞に明らかにこれらの2つの攻撃を使用するかもしれません: それは、HIPにInitiator HIに送られただまされたDNSパケットでそれ自身のものによるResponderのHIとRVS IPアドレスを置き換えて、次に、すべての交換されたパケットを彼に向け直して、MitMを取り付けるでしょう。 この場合、HIPは秘密性を提供しないでしょう。または、立ち聞きする者からのInitiator HI保護。
8.2. Hash and HITs Collisions
8.2. 細切れ肉料理とヒット衝突
As with many cryptographic algorithms, some secure hashes (e.g., SHA1, used by HIP to generate a HIT from an HI) eventually become insecure, because an exploit has been found in which an attacker with reasonable computation power breaks one of the security features of the hash (e.g., its supposed collision resistance). This is why a HIP end-node implementation SHOULD NOT authenticate its HIP peers based solely on a HIT retrieved from the DNS, but SHOULD rather use HI-based authentication.
多くの暗号アルゴリズムのように或るものが安全にする、論じ尽くす、(例えばHIからHITを発生させるのにHIPによって使用されたSHA1)は結局不安定になります、妥当な計算パワーがある攻撃者が細切れ肉料理(例えば、想定された衝突抵抗)のセキュリティ機能の1つを壊す功績が見つけられたので。 これはHIPエンドノード実現SHOULD NOTが唯一DNSから検索されたHITに基づくHIP同輩を認証する理由ですが、SHOULDはむしろHIベースの認証を使用します。
8.3. DNSSEC
8.3. DNSSEC
In the absence of DNSSEC, the HIP RR is subject to the threats described in RFC 3833 [RFC3833].
DNSSECが不在のとき、HIP RRはRFC3833[RFC3833]で説明された脅威を受けることがあります。
9. IANA Considerations
9. IANA問題
IANA has allocated one new RR type code (55) for the HIP RR from the standard RR type space.
IANAはHIP RRのために標準のRRタイプスペースから1つの新しいRRタイプコード(55)を割り当てました。
IANA does not need to open a new registry for public key algorithms of the HIP RR because the HIP RR reuses "algorithms types" defined for the IPSECKEY RR [RFC4025]. Presently defined values are shown here for reference only:
HIP RRがIPSECKEY RR[RFC4025]のために定義された「アルゴリズムタイプ」を再利用するので、IANAはHIP RRの公開鍵アルゴリズムのために新しい登録を開く必要はありません。 現在定義された値は参照だけのためにここに示されます:
0 is reserved
0は予約されています。
1 is DSA
1はDSAです。
2 is RSA
2はRSAです。
Nikander & Laganier Experimental [Page 13] RFC 5205 HIP DNS Extension April 2008
クールな[13ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
In the future, if a new algorithm is to be used for the HIP RR, a new algorithm type and corresponding public key encoding should be defined for the IPSECKEY RR. The HIP RR should reuse both the same algorithm type and the same corresponding public key format as the IPSECKEY RR.
将来、新しいアルゴリズムタイプと対応する公開鍵コード化は新しいアルゴリズムがHIP RRに使用されることであるなら、IPSECKEY RRのために定義されるべきです。 HIP RRはIPSECKEY RRとしての同じアルゴリズムタイプと同じ対応する公開鍵形式の両方を再利用するはずです。
10. Acknowledgments
10. 承認
As usual in the IETF, this document is the result of a collaboration between many people. The authors would like to thank the author (Michael Richardson), contributors, and reviewers of the IPSECKEY RR [RFC4025] specification, after which this document was framed. The authors would also like to thank the following people, who have provided thoughtful and helpful discussions and/or suggestions, that have helped improve this document: Jeff Ahrenholz, Rob Austein, Hannu Flinck, Olafur Gudmundsson, Tom Henderson, Peter Koch, Olaf Kolkman, Miika Komu, Andrew McGregor, Erik Nordmark, and Gabriel Montenegro. Some parts of this document stem from the HIP specification [RFC5201].
いつものように、IETFでは、このドキュメントは多くの人々の間の共同の結果です。 作者はIPSECKEY RR[RFC4025]仕様の作者(マイケル・リチャードソン)、貢献者、および評論家に感謝したがっています。(その時、このドキュメントは縁どられました後)。 また、作者は考え深くて役立っている議論、そして/または、提案を提供した以下の人々に感謝したがっていて、それは、このドキュメントを改良するのを助けました: ジェフAhrenholz、Austein、ハンヌ・フリンク、Olafurグドムンソン、トム・ヘンダーソン、ピーター・コッホ、オラフKolkman、ミカKomu、アンドリュー・マクレガー、エリックNordmark、およびガブリエル・モンテネグロから、略奪してください。 このドキュメントのいくつかの部分がHIP仕様[RFC5201]によります。
11. References
11. 参照
11.1. Normative references
11.1. 引用規格
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC3596]トムソン、S.、Huitema、C.、Ksinant、V.、そして、M.Souissi、「DNS拡張子、IPをバージョン6インチ支持してください、RFC3596、2003インチ年10月。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005.
[RFC4025] 2005年3月のリチャードソン、M.、「DNSで材料を合わせながらIPsecを格納するための方法」RFC4025。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
Nikander & Laganier Experimental [Page 14] RFC 5205 HIP DNS Extension April 2008
クールな[14ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4035]Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson、2006年10月のS.、「Base16、Base32、およびBase64データEncodings」RFC4648。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]マスコウィッツ、R.、Nikander、P.、Jokela、P.、エド、T.ヘンダーソン、「ホストアイデンティティプロトコル」、RFC5201、4月2008日
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008.
[RFC5204] LaganierとJ.とL.エッゲルト、「ホストのアイデンティティのプロトコルの(クール)のランデブー拡大」、RFC5204、2008年4月。
11.2. Informative references
11.2. 有益な参照
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC2536]イーストレーク、D.と、「ドメインネームシステム(DNS)におけるDSAキーとSIG」(RFC2536)は1999を行進させます。
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001.
[RFC3110] イーストレークと、D.と、「ドメインネームシステム(DNS)におけるRSA/SHA-1SIGとRSAキー」(RFC3110)は2001がそうするかもしれません。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[RFC3833] アトキンスとD.とR.Austein、「ドメインネームシステム(DNS)の脅威分析」、RFC3833、2004年8月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4423] マスコウィッツ、R.、およびP.Nikander(「ホストのアイデンティティのプロトコルの(クール)の構造」、RFC4423)は2006がそうするかもしれません。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming
with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] ヘンダーソン、T.、エド、「ホストのアイデンティティがある終わりホストの移動性とマルチホーミングは議定書を作る」、RFC5206、4月2008日
Nikander & Laganier Experimental [Page 15] RFC 5205 HIP DNS Extension April 2008
クールな[15ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
Authors' Addresses
作者のアドレス
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
ペッカ・Nikanderエリクソン研究NomadicLab JORVASフィン-02420フィンランド
Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com
以下に電話をしてください。 +358 9 299 1 メール: pekka.nikander@nomadiclab.com
Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany
ジュリアンLaganier DoCoMoコミュニケーション研究所ヨーロッパGmbHランツベルガーストラッセ312ミュンヘン80687ドイツ
Phone: +49 89 56824 231 EMail: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/
以下に電話をしてください。 +49 89 56824 231メール: julien.ietf@laposte.net ユリ: http://www.docomolab-euro.com/
Nikander & Laganier Experimental [Page 16] RFC 5205 HIP DNS Extension April 2008
クールな[16ページ]RFC5205DNS拡大2008年4月に実験的なNikander&Laganier
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Nikander & Laganier Experimental [Page 17]
Nikander&Laganier実験的です。[17ページ]
一覧
スポンサーリンク
