RFC4423 日本語訳
4423 Host Identity Protocol (HIP) Architecture. R. Moskowitz, P.Nikander. May 2006. (Format: TXT=61049 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Moskowitz
Request for Comments: 4423 ICSA Labs, a division of Cybertrust, Inc.
Category: Informational P. Nikander
Ericsson Research Nomadic Lab
May 2006
コメントを求めるワーキンググループR.マスコウィッツの要求をネットワークでつないでください: 4423ICSA Labs、Cybertrust Inc.Categoryの分割: 研究室2006年5月に遊牧民的な情報のP.Nikanderエリクソンの研究
Host Identity Protocol (HIP) Architecture
ホストアイデンティティプロトコル(クールな)アーキテクチャ
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol (HIP), between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since. This document represents one stable point in that evolution of understanding.
このメモは提案された新しい名前空間、Host Identity名前空間、および新しいプロトコル層の後ろで推理のスナップについて説明します、Host Identityプロトコル(HIP)、インターネットワーキングとトランスポート層の間で。 現在の名前空間と、それらの長所と、短所と、新しい名前空間がどうそれらに完全性を加えるかに関する基礎はここに提示されます。 プロトコルのこの新しい名前空間の役割は定義されます。 メモはFall2003現在作者の考えについて説明します。 アーキテクチャは以来に発展したかもしれません。 このドキュメントは理解のその発展で安定した1ポイントを表します。
Table of Contents
目次
1. Disclaimer ......................................................2
2. Introduction ....................................................2
3. Terminology .....................................................4
3.1. Terms Common to Other Documents ............................4
3.2. Terms Specific to This and Other HIP Documents .............4
4. Background ......................................................6
4.1. A Desire for a Namespace for Computing Platforms ...........6
5. Host Identity Namespace .........................................8
5.1. Host Identifiers ...........................................9
5.2. Storing Host Identifiers in DNS ............................9
5.3. Host Identity Tag (HIT) ...................................10
5.4. Local Scope Identifier (LSI) ..............................10
6. New Stack Architecture .........................................11
1. 注意書き…2 2. 序論…2 3. 用語…4 3.1. 他のドキュメントに共通の用語…4 3.2. これに特定の用語と他のクールなドキュメント…4 4. バックグラウンド…6 4.1. コンピューティングのための名前空間に関する願望は載せられます…6 5. アイデンティティ名前空間を接待してください…8 5.1. 識別子をホスティングしてください…9 5.2. DNSのホスト識別子を保存します…9 5.3. アイデンティティタグ(ヒット)を接待してください…10 5.4. ローカルの範囲識別子(LSI)…10 6. 新しいスタック・アーキテクチャ…11
Moskowitz & Nikander Informational [Page 1] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[1ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
6.1. Transport Associations and End-points .....................11
7. End-host Mobility and Multi-homing .............................12
7.1. Rendezvous Mechanism ......................................13
7.2. Protection against Flooding Attacks .......................13
8. HIP and IPsec ..................................................14
9. HIP and NATs ...................................................15
9.1. HIP and TCP Checksums .....................................15
10. Multicast .....................................................16
11. HIP Policies ..................................................16
12. Benefits of HIP ...............................................16
12.1. HIP's Answers to NSRG Questions ..........................17
13. Security Considerations .......................................19
13.1. HITs Used in ACLs ........................................21
13.2. Non-security considerations ..............................21
14. Acknowledgements ..............................................22
15. Informative References ........................................22
6.1. 協会とエンドポイントを輸送してください…11 7. 移動性とマルチホーミングを終わりでホスティングしてください…12 7.1. メカニズムを集合させてください…13 7.2. 氾濫に対する保護は攻撃されます…13 8. ヒップとIPsec…14 9. ヒップとNATs…15 9.1. ヒップとTCPチェックサム…15 10. マルチキャスト…16 11. クールな方針…16 12. ヒップの利益…16 12.1. ヒップのNSRG質問の答え…17 13. セキュリティ問題…19 13.1. ACLsで使用されるヒット…21 13.2. 非セキュリティ問題…21 14. 承認…22 15. 有益な参照…22
1. Disclaimer
1. 注意書き
The purpose of this memo is to provide a stable reference point in the development of the Host Identity Protocol architecture. This memo describes the thinking of the authors as of Fall 2003; their thinking may have evolved since then. Occasionally, this memo may be confusing or self-contradicting. That is (partially) intentional, and it reflects the snapshot nature of this memo.
このメモの目的はHost Identityプロトコルアーキテクチャの開発に安定した基準点を提供することです。 このメモはFall2003現在作者の考えについて説明します。 それらの考えはそれ以来、発展したかもしれません。 このメモは、時折、紛らわしいか自己に逆らっているかもしれません。 すなわち(部分的である)、意図的である、それはこのメモのスナップ本質を反映します。
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review. However, the ideas put forth in this RFC have generated significant interest, including the formation of the IETF HIP Working Group and the IRTF HIP Research Group. These groups are expected to generate further documents, sharing their findings with the whole Internet community.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFはどんな目的と発行するという決定がIETFレビューに基づいていないというメモのためにもこのRFCのフィットネスに関するどんな知識も放棄します。 しかしながら、このRFCで提議された考えは重要な関心を呼びました、IETF HIP作業部会とIRTF HIP Research Groupの構成を含んでいて。 全体のインターネットコミュニティとそれらの調査結果を共有して、これらのグループがさらなるドキュメントを作ると予想されます。
2. Introduction
2. 序論
The Internet has two important global namespaces: Internet Protocol (IP) addresses and Domain Name Service (DNS) names. These two namespaces have a set of features and abstractions that have powered the Internet to what it is today. They also have a number of weaknesses. Basically, since they are all we have, we try to do too much with them. Semantic overloading and functionality extensions have greatly complicated these namespaces.
インターネットには、2つの重要なグローバルな名前空間があります: インターネットプロトコル(IP)アドレスとDomain Name Service(DNS)名。 これらの2つの名前空間には、今日それが何であるかということにインターネットを動かした1セットの特徴と抽象化があります。 また、彼らには、多くの弱点があります。 基本的に、私たちは、彼らが持っているすべてので、それらを処理し過ぎようとします。 意味積みすぎと機能性拡張子はこれらの名前空間を大いに複雑にしました。
The proposed Host Identity namespace fills an important gap between the IP and DNS namespaces. The Host Identity namespace consists of Host Identifiers (HIs). A Host Identifier is cryptographic in its
提案されたHost Identity名前空間はIPとDNS名前空間の重要な不足をいっぱいにしています。 Host Identity名前空間はHost Identifiers(HIs)から成ります。 Host Identifierが暗号である、それ
Moskowitz & Nikander Informational [Page 2] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[2ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
nature; it is the public key of an asymmetric key-pair. Each host will have at least one Host Identity, but it will typically have more than one. Each Host Identity uniquely identifies a single host; i.e., no two hosts have the same Host Identity. The Host Identity, and the corresponding Host Identifier, can be either public (e.g., published in the DNS) or unpublished. Client systems will tend to have both public and unpublished Identities.
自然。 それは非対称の主要な組の公開鍵です。 各ホストは少なくとも1Host Identityを持つでしょうが、それには、1つ以上が通常あるでしょう。 各Host Identityは唯一独身のホストを特定します。 すなわち、いいえtwo、ホストは同じHost Identityを持っています。 Host Identity、および対応するHost Identifierは公共であるか(例えば、DNSでは、発行されます)、または未発表である場合があります。 クライアントシステムは、公共のものと同様に未発表のIdentitiesを持っている傾向があるでしょう。
There is a subtle but important difference between Host Identities and Host Identifiers. An Identity refers to the abstract entity that is identified. An Identifier, on the other hand, refers to the concrete bit pattern that is used in the identification process.
Host IdentitiesとHost Identifiersの間には、微妙な、しかし、重要な違いがあります。 Identityは特定される抽象的実体について言及します。 他方では、Identifierは識別プロセスで使用される具体的なビット・パターンを示します。
Although the Host Identifiers could be used in many authentication systems, such as the Internet Key Exchange (IKEv2) Protocol [9], the presented architecture introduces a new protocol, called the Host Identity Protocol (HIP), and a cryptographic exchange, called the HIP base exchange; see also Section 8. The HIP protocols provide for limited forms of trust between systems, enhance mobility, multi- homing, and dynamic IP renumbering; aid in protocol translation/transition; and reduce certain types of denial-of-service (DoS) attacks.
提示されたアーキテクチャがインターネット・キー・エクスチェンジ(IKEv2)プロトコル[9]などのように紹介する多くの認証システムでHost Identifiersを使用できましたが、Host Identityプロトコル(HIP)、および暗号の交換と呼ばれる新しいプロトコルは、HIPを塩基置換と呼びました。 また、セクション8を見てください。 HIPプロトコルはシステムと、機能アップの移動性と、マルチの家へ帰りと、ダイナミックなIPの番号を付け替えることの間の限局型の信頼に備えます。 プロトコル変換/変遷では、支援してください。 そして、あるタイプのサービスの否定(DoS)攻撃を抑えてください。
When HIP is used, the actual payload traffic between two HIP hosts is typically, but not necessarily, protected with IPsec. The Host Identities are used to create the needed IPsec Security Associations (SAs) and to authenticate the hosts. When IPsec is used, the actual payload IP packets do not differ in any way from standard IPsec- protected IP packets.
通常、であるIPsecと共に保護されて、HIPが使用されているとき、2人のHIPホストの間の実際のペイロードトラフィックは必ずそうであるというわけではありません。 Host Identitiesは、必要なIPsec Security Associations(SAs)を作成して、ホストを認証するのに使用されます。 IPsecが使用されているとき、実際のペイロードIPパケットは何らかの方法で標準のIPsec保護されたIPパケットと異なっていません。
Moskowitz & Nikander Informational [Page 3] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[3ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
3. Terminology
3. 用語
3.1. Terms Common to Other Documents
3.1. 他のドキュメントに共通の用語
+--------------+----------------------------------------------------+ | Term | Explanation | +--------------+----------------------------------------------------+ | public key | The public key of an asymmetric cryptographic key | | | pair. Used as a publicly known identifier for | | | cryptographic identity authentication. | | | | | Private key | The private or secret key of an asymmetric | | | cryptographic key pair. Assumed to be known only | | | to the party identified by the corresponding | | | public key. Used by the identified party to | | | authenticate its identity to other parties. | | | | | public key | An asymmetric cryptographic key pair consisting of | | pair | public and private keys. For example, | | | Rivest-Shamir-Adelman (RSA) and Digital Signature | | | Algorithm (DSA) key pairs are such key pairs. | | | | | end-point | A communicating entity. For historical reasons, | | | the term 'computing platform' is used in this | | | document as a (rough) synonym for end-point. | +--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+ | 用語| 説明| +--------------+----------------------------------------------------+ | 公開鍵| 非対称の暗号化キーの公開鍵| | | 対にしてください。 公的に知られている識別子として、使用されます。| | | 暗号のアイデンティティ認証。 | | | | | 秘密鍵| 個人的であるか秘密のキー、非対称| | | 暗号化キー組。 知られていると思われる、唯一| | | 対応で特定されたパーティーに| | | 公開鍵。 特定されたパーティーによって使用されます。| | | 相手へのアイデンティティを認証してください。 | | | | | 公開鍵| 非対称の暗号化キーは成ることを対にします。| | 組| 公衆と秘密鍵。 例えば| | | 最もRivestなシャミル・エーデルマン(RSA)とデジタル署名| | | アルゴリズム(DSA)主要な組はそのように主要な組です。 | | | | | エンドポイント| 交信実体。 歴史的な理由で| | | 'コンピューティングプラットホーム'という用語はこれで使用されます。| | | (あぶれ者)として、エンドポイントのために同義語を記録してください。 | +--------------+----------------------------------------------------+
3.2. Terms Specific to This and Other HIP Documents
3.2. これに特定の用語と他のクールなドキュメント
It should be noted that many of the terms defined herein are tautologous, self-referential, or defined through circular reference to other terms. This is due to the succinct nature of the definitions. See the text elsewhere in this document for more elaborate explanations.
ここに定義された用語の多くが自己参考の、または、他の用語の循環参照で定義されたtautologousであることに注意されるべきです。これは定義の簡潔な本質のためです。 本書ではより入念な説明のためのほかの場所でテキストを見てください。
Moskowitz & Nikander Informational [Page 4] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[4ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
+--------------+----------------------------------------------------+ | Term | Explanation | +--------------+----------------------------------------------------+ | computing | An entity capable of communicating and computing, | | platform | for example, a computer. See the definition of | | | 'end-point', above. | | | | | HIP base | A cryptographic protocol; see also Section 8. | | exchange | | | | | | HIP packet | An IP packet that carries a 'Host Identity | | | Protocol' message. | | | | | Host | An abstract concept assigned to a 'computing | | Identity | platform'. See 'Host Identifier', below. | | | | | Host | A namespace formed by all possible Host | | Identity | Identifiers. | | namespace | | | | | | Host | A protocol used to carry and authenticate Host | | Identity | Identifiers and other information. | | Protocol | | | | | | Host | A 128-bit datum created by taking a cryptographic | | Identity Tag | hash over a Host Identifier. | | | | | Host | A public key used as a name for a Host Identity. | | Identifier | | | | | | Local Scope | A 32-bit datum denoting a Host Identity. | | Identifier | | | | | | Public Host | A published or publicly known Host Identifier used | | Identifier | as a public name for a Host Identity, and the | | and Identity | corresponding Identity. | | | | | Unpublished | A Host Identifier that is not placed in any public | | Host | directory, and the corresponding Host Identity. | | Identifier | Unpublished Host Identities are typically | | and Identity | shortlived in nature, being often replaced and | | | possibly used just once. | | | | | Rendezvous | A mechanism used to locate mobile hosts based on | | Mechanism | their Host Identity Tag (HIT). | +--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+ | 用語| 説明| +--------------+----------------------------------------------------+ | コンピューティング| 交信とコンピューティングができる実体| | プラットホーム| 例えば、コンピュータ。 定義を見ます。| | | 上の'エンドポイント'。 | | | | | HIPベース| 暗号のプロトコル。 また、セクション8を見てください。 | | 交換| | | | | | HIPパケット| 'ホストIdentity'を運ぶIPパケット| | | ''メッセージについて議定書の中で述べてください。 | | | | | ホスト| 'コンピューティング'に割り当てられた抽象概念| | アイデンティティ| 'プラットホーム'。 以下の'ホストIdentifier'を見てください。 | | | | | ホスト| すべての可能なHostによって形成された名前空間| | アイデンティティ| 識別子。 | | 名前空間| | | | | | ホスト| プロトコルは、Hostを運んで、以前はよく認証していました。| | アイデンティティ| 識別子と他の情報。 | | プロトコル| | | | | | ホスト| aを取ることによって暗号で作成された128ビットのデータ| | アイデンティティタグ| Host Identifierを論じ尽くしてください。 | | | | | ホスト| Host Identityに名前として使用される公開鍵。 | | 識別子| | | | | | 地方の範囲| Host Identityを指示する32ビットのデータ。 | | 識別子| | | | | | 公共のホスト| 使用される発行されたか、または公的に知られているHost Identifier| | 識別子| そしてHost Identityのための公共の名前として。| | そして、アイデンティティ| 対応するIdentity。 | | | | | 未発表| どんな公衆にも置かれないHost Identifier| | ホスト| ディレクトリ、および対応するHost Identity。 | | 識別子| 未発表のHost Identitiesは通常、そうです。| | そして、アイデンティティ| そしてしばしば取り替えて、現実にshortlivedした。| | | ことによるとかつてまさしく使用されています。 | | | | | ランデブー| ベースのモバイルホストの居場所を見つけるのにおいて中古のメカニズム| | メカニズム| それらのHost Identity Tag(HIT)。 | +--------------+----------------------------------------------------+
Moskowitz & Nikander Informational [Page 5] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[5ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
4. Background
4. バックグラウンド
The Internet is built from three principal components: computing platforms (end-points), packet transport (i.e., internetworking) infrastructure, and services (applications). The Internet exists to service two principal components: people and robotic services (silicon-based people, if you will). All these components need to be named in order to interact in a scalable manner. Here we concentrate on naming computing platforms and packet transport elements.
インターネットは3つの主成分から造られます: コンピューティングは(エンドポイント)、パケット輸送(すなわち、インターネットワーキング)インフラストラクチャ、およびサービス(アプリケーション)を載せます。 インターネットは2つの主成分を調整するために存在しています: 人々とロボットのサービス(言わばシリコンベースの人々)。 これらのすべてのコンポーネントが、スケーラブルな方法で相互作用するように命名される必要があります。 ここで、私たちはコンピューティングプラットホームとパケット輸送を要素と命名するのに集中します。
There are two principal namespaces in use in the Internet for these components: IP numbers and Domain Names. Domain Names provide hierarchically assigned names for some computing platforms and some services. Each hierarchy is delegated from the level above; there is no anonymity in Domain Names. Email, HTTP, and SIP addresses all reference Domain Names.
これらのコンポーネントに、インターネットで使用中の2つの主要な名前空間があります: IP番号とDomain Names。 ドメインNamesはいくつかのコンピューティングプラットホームといくつかのサービスに階層的に割り当てられた名前を提供します。 レベルから各階層構造を上へ代表として派遣します。 匿名が全くDomain Namesにありません。 メール、HTTP、およびSIPアドレス参照Domain Names。
IP numbers are a confounding of two namespaces, the names of a host's
networking interfaces and the names of the locations ('confounding'
is a term used in statistics to discuss metrics that are merged into
one with a gain in indexing, but a loss in informational value). The
names of locations should be understood as denoting routing direction
vectors, i.e., information that is used to deliver packets to their
destinations.
IP番号は2つの名前空間の困惑です、ホストが位置のインタフェースと名前をネットワークでつなぐ名前('困惑'は索引をつける際に利得で1つに合併されている測定基準について議論しますが、情報の値で損失について議論するのに統計に使用される用語です)。 位置の名前はルーティング方向ベクトル(すなわち、それらの送付先にパケットを提供するのに使用される情報)を指示するとして理解されるべきです。
IP numbers name networking interfaces, and typically only when the interface is connected to the network. Originally, IP numbers had long-term significance. Today, the vast number of interfaces use ephemeral and/or non-unique IP numbers. That is, every time an interface is connected to the network, it is assigned an IP number.
インタフェースがネットワークに関連づけられるときだけ、IP番号はネットワークインタフェースを通常命名します。 元々、IP番号には、長期の意味がありました。 今日、インタフェースの膨大な数ははかない、そして/または、非ユニークなIP番号を使用します。 すなわち、インタフェースがネットワークに関連づけられるときはいつも、IP番号はそれに割り当てられます。
In the current Internet, the transport layers are coupled to the IP addresses. Neither can evolve separately from the other. IPng deliberations were strongly shaped by the decision that a corresponding TCPng would not be created.
現在のインターネットでは、トランスポート層はIPアドレスと結合されます。 どちらも別々にもう片方から発展できません。 対応するTCPngが作成されないだろうという決定でIPng熟考は強く形成されました。
There are three critical deficiencies with the current namespaces. First, dynamic readdressing cannot be directly managed. Second, anonymity is not provided in a consistent, trustable manner. Finally, authentication for systems and datagrams is not provided. All of these deficiencies arise because computing platforms are not well named with the current namespaces.
現在の名前空間がある3つの重要な欠乏があります。 まず最初に、直接ダイナミックなあて名を書き直すことに対処できません。 2番目に、匿名は一貫して、「信頼-可能」な方法で提供されません。 最終的に、システムとデータグラムのための認証は提供されません。 コンピューティングプラットホームが現在の名前空間でよく命名されないので、これらの欠乏のすべてが起こります。
4.1. A Desire for a Namespace for Computing Platforms
4.1. コンピューティングプラットホームへの名前空間に関する願望
An independent namespace for computing platforms could be used in end-to-end operations independent of the evolution of the internetworking layer and across the many internetworking layers.
インターネットワーキング層の発展の如何にかかわらず多くのインターネットワーキング層の向こう側に終わりから終わりへの操作にコンピューティングプラットホームへの独立している名前空間を使用できました。
Moskowitz & Nikander Informational [Page 6] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[6ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
This could support rapid readdressing of the internetworking layer because of mobility, rehoming, or renumbering.
これは移動性、「再-家へ帰」り、または番号を付け替えるのでインターネットワーキング層の急速なあて名を書き直すことをサポートするかもしれません。
If the namespace for computing platforms is based on public key cryptography, it can also provide authentication services. If this namespace is locally created without requiring registration, it can provide anonymity.
また、コンピューティングプラットホームへの名前空間が公開鍵暗号に基づいているなら、それは認証サービスを提供できます。 この名前空間が局所的に登録を必要としないで作成されるなら、それは匿名を提供できます。
Such a namespace (for computing platforms) and the names in it should have the following characteristics:
そのような名前空間(コンピューティングプラットホームへの)とそれの名前には、以下の特性があるべきです:
o The namespace should be applied to the IP 'kernel'. The IP kernel
is the 'component' between applications and the packet transport
infrastructure.
o 名前空間はIP'カーネル'に適用されるべきです。 IPカーネルはアプリケーションとパケット輸送インフラの間の'コンポーネント'です。
o The namespace should fully decouple the internetworking layer from
the higher layers. The names should replace all occurrences of IP
addresses within applications (like in the Transport Control
Block, TCB). This may require changes to the current APIs. In
the long run, it is probable that some new APIs are needed.
o 名前空間は完全により高い層からインターネットワーキング層の衝撃を吸収するべきです。 名前はアプリケーション(Transport Control Block、TCBでは、好きである)の中でIPアドレスのすべての発生に取って代わるべきです。 これは現在のAPIへの変化を必要とするかもしれません。 結局、いくつかの新しいAPIが必要であるのは、ありえそうです。
o The introduction of the namespace should not mandate any
administrative infrastructure. Deployment must come from the
bottom up, in a pairwise deployment.
o 名前空間の導入はどんな管理インフラストラクチャも強制するべきではありません。 展開は対状展開で下から来なければなりません。
o The names should have a fixed-length representation, for easy
inclusion in datagram headers and existing programming interfaces
(e.g., the TCB).
o 名前はデータグラムヘッダーとインタフェースをプログラムしながら存在する際に(例えば、TCB)簡単な包含の固定長表現を持つべきです。
o Using the namespace should be affordable when used in protocols.
This is primarily a packet size issue. There is also a
computational concern in affordability.
o プロトコルに使用されると、名前空間を使用するのは手頃であるべきです。 これは主としてパケットサイズ問題です。 また、入手可能性におけるコンピュータの関心があります。
o Name collisions should be avoided as much as possible. The
mathematics of the birthday paradox can be used to estimate the
chance of a collision in a given population and hash space. In
general, for a random hash space of size n bits, we would expect
to obtain a collision after approximately 1.2*sqrt(2**n) hashes
were obtained. For 64 bits, this number is roughly 4 billion. A
hash size of 64 bits may be too small to avoid collisions in a
large population; for example, there is a 1% chance of collision
in a population of 640M. For 100 bits (or more), we would not
expect a collision until approximately 2**50 (1 quadrillion)
hashes were generated.
o 名前衝突はできるだけ避けられるべきです。 与えられた人口とハッシュスペースの衝突の機会を見積もるのに誕生日のパラドックスの数学を使用できます。 一般に、nビットのサイズの無作為のハッシュスペースに、私たちは、およそ1.2の*sqrt(2**n)ハッシュを得た後に衝突を得ると予想するでしょう。 この数は64ビット、およそ40億です。 64ビットのハッシュサイズは多数の人口における衝突を避けることができないくらい小さいかもしれません。 例えば、640Mの人口における、衝突の1%の確率があります。 100ビット(さらに)、およそ2つの**50(1000兆)ハッシュが生成されるまで、私たちは衝突を予想しないでしょう。
o The names should have a localized abstraction that can be used in
existing protocols and APIs.
o 名前には、既存のプロトコルとAPIで使用できるローカライズしている抽象化があるべきです。
Moskowitz & Nikander Informational [Page 7] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[7ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
o It must be possible to create names locally. This can provide
anonymity at the cost of making resolvability very difficult.
o 局所的に名前を作成するのは可能であるに違いありません。 これは「再-解決可能性」を非常に難しくする費用で匿名を提供できます。
* Sometimes the names may contain a delegation component. This
is the cost of resolvability.
* 時々、名前は委譲コンポーネントを含むかもしれません。 これは「再-解決可能性」の費用です。
o The namespace should provide authentication services.
o 名前空間は認証サービスを提供するべきです。
o The names should be long-lived, but replaceable at any time. This
impacts access control lists; short lifetimes will tend to result
in tedious list maintenance or require a namespace infrastructure
for central control of access lists.
o 名前は、いつでも、長命ですが、取替え可能であるべきです。 これはアクセスコントロールリストに影響を与えます。 短い寿命は、退屈なリスト管理をもたらすか、またはアクセスリストの集中管理のために名前空間インフラストラクチャを必要とする傾向があるでしょう。
In this document, a new namespace approaching these ideas is called the Host Identity namespace. Using Host Identities requires its own protocol layer, the Host Identity Protocol, between the internetworking and transport layers. The names are based on public key cryptography to supply authentication services. Properly designed, it can deliver all of the above-stated requirements.
本書では、これらの考えにアプローチする新しい名前空間はHost Identity名前空間と呼ばれます。 Host Identitiesを使用するのはインターネットワーキングとトランスポート層の間でそれ自身のプロトコル層、Host Identityプロトコルを必要とします。 名前は、認証サービスを供給するために公開鍵暗号に基づいています。 適切に設計されていて、それは上で述べられた要件のすべてを提供できます。
5. Host Identity Namespace
5. ホストアイデンティティ名前空間
A name in the Host Identity namespace, a Host Identifier (HI), represents a statistically globally unique name for naming any system with an IP stack. This identity is normally associated with, but not limited to, an IP stack. A system can have multiple identities, some 'well known', some unpublished or 'anonymous'. A system may self- assert its own identity, or may use a third-party authenticator like DNS Security (DNSSEC) [2], Pretty Good Privacy (PGP), or X.509 to 'notarize' the identity assertion. It is expected that the Host Identifiers will initially be authenticated with DNSSEC and that all implementations will support DNSSEC as a minimal baseline.
Host Identifier(HI)というHost Identity名前空間における名前は、IPスタックでどんなシステムも命名するために統計的にグローバルにユニークな名前を表します。 通常、このアイデンティティと交際して、他、IPは積み重ねられます。 システムは複数のアイデンティティ、いくつか'よく知られている'いくつかを未発表か'匿名'に持つことができます。 システムは使用します。自己それ自身のアイデンティティについて断言してください、またはアイデンティティ主張を'公証すること'にDNS Security(DNSSEC)[2]のような第三者固有識別文字、プリティ・グッド・プライバシ(PGP)、またはX.509を使用するかもしれません。 Host Identifiersが初めは、DNSSECと共に認証されて、すべての実装が最小量の基線としてDNSSECをサポートすると予想されます。
In theory, any name that can claim to be 'statistically globally unique' may serve as a Host Identifier. However, in the authors' opinion, a public key of a 'public key pair' makes the best Host Identifier. As will be specified in the Host Identity Protocol specification, a public-key-based HI can authenticate the HIP packets and protect them from man-in-the-middle attacks. Since authenticated datagrams are mandatory to provide much of HIP's DoS protection, the Diffie-Hellman exchange in HIP has to be authenticated. Thus, only public key HI and authenticated HIP messages are supported in practice. In this document, the non-cryptographic forms of HI and HIP are presented to complete the theory of HI, but they should not be implemented as they could produce worse DoS attacks than the Internet has without Host Identity.
理論上、'統計的にグローバルにユニークである'と主張できるどんな名前もHost Identifierとして機能するかもしれません。 しかしながら、作者の意見では、'公開鍵組'の公開鍵は最も良いHost Identifierを作ります。 指定されているように、公開鍵ベースのHIはHost Identityプロトコル仕様では、介入者攻撃からHIPパケットを認証して、それらを保護できます。 認証されたデータグラムがHIPのDoS保護の多くを提供するために義務的であるので、HIPのディフィー-ヘルマンの交換は認証されなければなりません。 公開鍵のHIの、そして、認証されたHIPメッセージだけが実際にはサポートされます。 本書では、HIの理論を完成するためにHIとHIPの非暗号のフォームを提示しますが、インターネットがHost Identityなしで持っているより悪いDoS攻撃を起こすかもしれないようにそれらを実装するべきではありません。
Moskowitz & Nikander Informational [Page 8] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[8ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
5.1. Host Identifiers
5.1. ホスト識別子
Host Identity adds two main features to Internet protocols. The first is a decoupling of the internetworking and transport layers; see Section 6. This decoupling will allow for independent evolution of the two layers. In addition, it can provide end-to-end services over multiple internetworking realms. The second feature is host authentication. Because the Host Identifier is a public key, this key can be used for authentication in security protocols like IPsec.
ホストIdentityは2つの主な出し物をインターネットプロトコルに追加します。 1番目はインターネットワーキングとトランスポート層のデカップリングです。 セクション6を見てください。 このデカップリングは2つの層の独立している発展を考慮するでしょう。 さらに、それは複数のインターネットワーキング分野にわたって終わりから終わりに対するサービスを提供できます。2番目の特徴はホスト認証です。 Host Identifierが公開鍵であるので、IPsecのようなセキュリティプロトコルにおける認証にこのキーを使用できます。
The only completely defined structure of the Host Identity is that of a public/private key pair. In this case, the Host Identity is referred to by its public component, the public key. Thus, the name representing a Host Identity in the Host Identity namespace, i.e., the Host Identifier, is the public key. In a way, the possession of the private key defines the Identity itself. If the private key is possessed by more than one node, the Identity can be considered to be a distributed one.
Host Identityの唯一の完全に定義された構造が1公衆/秘密鍵組のものです。 この場合、Host Identityは公共のコンポーネント、公開鍵によって言及されます。 したがって、すなわち、Host IdentifierというHost Identity名前空間でHost Identityを表す名前は公開鍵です。 ある意味で、秘密鍵の所有物はIdentity自身を定義します。 秘密鍵が1つ以上のノードによって持たれているなら、分配されたものであるとIdentityを考えることができます。
Architecturally, any other Internet naming convention might form a usable base for Host Identifiers. However, non-cryptographic names should only be used in situations of high trust / low risk, that is, any place where host authentication is not needed (no risk of host spoofing and no use of IPsec). However, at least for interconnected networks spanning several operational domains, the set of environments where the risk of host spoofing allowed by non- cryptographic Host Identifiers is acceptable is the null set. Hence, the current HIP documents do not specify how to use any other types of Host Identifiers but public keys.
建築上、いかなる他のインターネット命名規則もHost Identifiersに、使用可能なベースを形成するかもしれません。 しかしながら、非暗号の名前は高い信頼/低いリスク(ホスト認証は必要でない(ホストスプーフィングのリスクがなくてIPsecの無駄)すなわちどんな場所も)の状況で使用されるだけであるべきです。 しかしながら、少なくともいくつかの操作上のドメインにかかる相互接続ネットワークにおいて、非暗号のHost Identifiersによって許容されたホストスプーフィングのリスクが許容できる環境のセットは零集合です。 したがって、現在のHIPドキュメントはいかなる他のタイプのHost Identifiersにもかかわらず、公開鍵も使用する方法を指定しません。
The actual Host Identities are never directly used in any Internet protocols. The corresponding Host Identifiers (public keys) may be stored in various DNS or Lightweight Directory Access Protocol (LDAP) directories as identified elsewhere in this document, and they are passed in the HIP base exchange. A Host Identity Tag (HIT) is used in other protocols to represent the Host Identity. Another representation of the Host Identities, the Local Scope Identifier (LSI), can also be used in protocols and APIs.
実際のHost Identitiesはどんなインターネットプロトコルにも直接決して使用されません。 対応するHost Identifiers(公開鍵)はほかの場所で本書では特定されるように様々なDNSかライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)ディレクトリに保存されるかもしれません、そして、それらはHIP塩基置換で通過されます。 Host Identity Tag(HIT)は、Host Identityを表すのに他のプロトコルに使用されます。 また、プロトコルとAPIでHost Identitiesの別の表現(Local Scope Identifier(LSI))を使用できます。
5.2. Storing Host Identifiers in DNS
5.2. DNSのホスト識別子を保存します。
The public Host Identifiers should be stored in DNS; the unpublished Host Identifiers should not be stored anywhere (besides the communicating hosts themselves). The (public) HI is stored in a new Resource Record (RR) type, to be defined. This RR type is likely to be quite similar to the IPSECKEY RR [6].
公共のHost IdentifiersはDNSに保存されるべきです。 何処にも未発表のHost Identifiersを保存するべきではありません(そのうえ、交信は自分たちを接待します)。 (公共)のHIは、定義されるために新しいResource Record(RR)タイプで保存されます。 このRRタイプはIPSECKEY RR[6]と全く同様である傾向があります。
Moskowitz & Nikander Informational [Page 9] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[9ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
Alternatively, or in addition to storing Host Identifiers in the DNS, they may be stored in various kinds of Public Key Infrastructure (PKI). Such a practice may allow them to be used for purposes other than pure host identification.
代わりに、またはDNSにHost Identifiersを保存することに加えて、彼らは公開鍵基盤(PKI)の様々な種類で保存されるかもしれません。 そのような習慣は、それらが純粋なホスト識別以外の目的に使用されるのを許容するかもしれません。
5.3. Host Identity Tag (HIT)
5.3. ホストアイデンティティタグ(ヒット)
A Host Identity Tag is a 128-bit representation for a Host Identity. It is created by taking a cryptographic hash over the corresponding Host Identifier. There are two advantages of using a hash over using the Host Identifier in protocols. First, its fixed length makes for easier protocol coding and also better manages the packet size cost of this technology. Second, it presents the identity in a consistent format to the protocol independent of the cryptographic algorithms used.
Host Identity TagはHost Identityの128ビットの表現です。 それは、対応するHost Identifierの上に暗号のハッシュを取ることによって、作成されます。 プロトコルにHost Identifierを使用する上でハッシュを使用する2つの利点があります。 まず最初に、固定長は、より簡単なプロトコルコード化になって、また、この技術のパケットサイズ費用を管理するほうがよいです。 2番目に、使用される暗号アルゴリズムの如何にかかわらずそれは一貫した形式でプロトコルにアイデンティティを提示します。
In the HIP packets, the HITs identify the sender and recipient of a packet. Consequently, a HIT should be unique in the whole IP universe as long as it is being used. In the extremely rare case of a single HIT mapping to more than one Host Identity, the Host Identifiers (public keys) will make the final difference. If there is more than one public key for a given node, the HIT acts as a hint for the correct public key to use.
HIPパケットでは、HITsはパケットの送付者と受取人を特定します。 その結果、それが使用されている限り、HITは全体のIP宇宙の中でユニークであるべきです。 Host Identityを1つ以上に写像する独身のHITの非常にまれな場合では、Host Identifiers(公開鍵)は最終的な違いを作るでしょう。 与えられたノードのための1つ以上の公開鍵があれば、HITは正しい公開鍵が使用するヒントとして機能します。
5.4. Local Scope Identifier (LSI)
5.4. ローカルの範囲識別子(LSI)
A Local Scope Identifier (LSI) is a 32-bit localized representation for a Host Identity. The purpose of an LSI is to facilitate using Host Identities in existing protocols and APIs. LSI's advantage over HIT is its size; its disadvantage is its local scope.
Local Scope Identifier(LSI)はHost Identityの32ビットのローカライズしている表現です。 LSIの目的は既存のプロトコルとAPIでHost Identitiesを使用するのを容易にすることです。 HITよりLSIの利点はサイズです。 不都合は地方の範囲です。
Examples of how LSIs can be used include: as the address in an FTP command and as the address in a socket call. Thus, LSIs act as a bridge for Host Identities into IPv4-based protocols and APIs.
どうLSIを使用できるかに関する例は: FTPコマンドにおけるアドレスとしてソケットのアドレスとして、電話をしてください。 したがって、LSIはHost IdentitiesのためのブリッジとしてIPv4ベースのプロトコルとAPIに機能します。
Moskowitz & Nikander Informational [Page 10] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[10ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
6. New Stack Architecture
6. 新しいスタック・アーキテクチャ
One way to characterize Host Identity is to compare the proposed new architecture with the current one. As discussed above, the IP addresses can be seen to be a confounding of routing direction vectors and interface names. Using the terminology from the IRTF Name Space Research Group Report [7] and, e.g., the unpublished Internet Draft "Endpoints and Endpoint Names" [10] by Noel Chiappa, the IP addresses currently embody the dual role of locators and end- point identifiers. That is, each IP address names a topological location in the Internet, thereby acting as a routing direction vector, or locator. At the same time, the IP address names the physical network interface currently located at the point-of- attachment, thereby acting as an end-point name.
Host Identityを特徴付ける1つの方法は提案された新しいアーキテクチャを現在のものと比べることです。 上で議論するように、ルーティング方向ベクトルとインタフェース名の困惑であることをIPアドレスを見ることができます。 IRTF Name Space Research Group Report[7]から用語を使用する、例えば、クリスマスChiappaによる未発表のインターネットDraft「終点と終点名」[10]、IPアドレスは現在、ロケータと終わりのポイント識別子のニ重の役割を具体化します。 すなわちそれぞれのIPアドレスはインターネットで位相的な位置を命名します、その結果、ルーティング方向ベクトル、またはロケータとして、機能します。 同時にアドレスが現在物理ネットワークインタフェースを命名するIPがポイントで場所を見つけられた、-、-、その結果、付属、エンドポイント名としての芝居。
In the HIP architecture, the end-point names and locators are separated from each other. IP addresses continue to act as locators. The Host Identifiers take the role of end-point identifiers. It is important to understand that the end-point names based on Host Identities are slightly different from interface names; a Host Identity can be simultaneously reachable through several interfaces.
HIPアーキテクチャでは、エンドポイント名とロケータは互いと切り離されます。 IPアドレスは、ロケータとして機能し続けています。 Host Identifiersはエンドポイント識別子の役割を果たします。 Host Identitiesに基づくエンドポイント名がインタフェース名とわずかに異なっているのを理解しているのは重要です。 Host Identityは同時に、いくつかのインタフェースを通して届いている場合があります。
The difference between the bindings of the logical entities is illustrated in Figure 1.
論理的な実体の結合の違いは図1で例証されます。
Service ------ Socket Service ------ Socket
| |
| |
| |
| |
End-point | End-point --- Host Identity
\ | |
\ | |
\ | |
\ | |
Location --- IP address Location --- IP address
サービス------ ソケットサービス------ ソケット| | | | | | | | エンドポイント| エンドポイント--- アイデンティティを接待してください、\| | \ | | \ | | \ | | 位置--- IPアドレスLocation--- IPアドレス
Figure 1
図1
6.1. Transport Associations and End-points
6.1. 輸送協会とエンドポイント
Architecturally, HIP provides for a different binding of transport- layer protocols. That is, the transport-layer associations, i.e., TCP connections and UDP associations, are no longer bound to IP addresses but to Host Identities.
建築上、HIPは輸送層のプロトコルの異なった結合に備えます。 すなわち、トランスポート層協会(すなわち、TCP接続とUDP協会)は、もうアドレスにもかかわらず、Host IdentitiesへのIPに縛られません。
Moskowitz & Nikander Informational [Page 11] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[11ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
It is possible that a single physical computer hosts several logical end-points. With HIP, each of these end-points would have a distinct Host Identity. Furthermore, since the transport associations are bound to Host Identities, HIP provides for process migration and clustered servers. That is, if a Host Identity is moved from one physical computer to another, it is also possible to simultaneously move all the transport associations without breaking them. Similarly, if it is possible to distribute the processing of a single Host Identity over several physical computers, HIP provides for cluster-based services without any changes at the client end-point.
単一の物理的なコンピュータがいくつかの論理的なエンドポイントを接待するのは、可能です。 HIPがあるので、それぞれのこれらのエンドポイントには、異なったHost Identityがあるでしょう。 その上、輸送協会がHost Identitiesに縛られるので、HIPはプロセス移行とクラスタリングしているサーバに備えます。 また、すなわち、Host Identityが1台の物理的なコンピュータから別のものに移されるなら、同時にそれらを壊さないですべての輸送協会を動かすのも可能です。 同様に、数台の物理的なコンピュータの上に独身のHost Identityの処理を広げるのが可能であるなら、HIPは少しも変化なしでクライアントエンドポイントでクラスタベースのサービスに備えます。
7. End-host Mobility and Multi-homing
7. 終わりホストの移動性とマルチホーミング
HIP decouples the transport from the internetworking layer, and binds the transport associations to the Host Identities (through actually either the HIT or LSI). Consequently, HIP can provide for a degree of internetworking mobility and multi-homing at a low infrastructure cost. HIP mobility includes IP address changes (via any method) to either party. Thus, a system is considered mobile if its IP address can change dynamically for any reason like PPP, Dynamic Host Configuration Protocol (DHCP), IPv6 prefix reassignments, or a Network Address Translation (NAT) device remapping its translation. Likewise, a system is considered multi-homed if it has more than one globally routable IP address at the same time. HIP links IP addresses together, when multiple IP addresses correspond to the same Host Identity, and if one address becomes unusable, or a more preferred address becomes available, existing transport associations can easily be moved to another address.
HIPはインターネットワーキング層から輸送の衝撃を吸収して、輸送協会をHost Identitiesに縛ります(実際にHITかLSIを通して)。 その結果、HIPは低いインフラストラクチャ費用でインターネットワーキングの移動性とマルチホーミングの度合いに備えることができます。 HIPの移動性はIPアドレス変化を何れの当事者に含んでいます(どんなメソッドでも)。 したがって、IPアドレスがダイナミックに翻訳を再写像するPPPのようなどんな理由、Dynamic Host Configuration Protocol(DHCP)、IPv6接頭語再割当て、またはNetwork Address Translation(NAT)デバイスも交換できるなら、システムはモバイルであると考えられます。 同様に、システムが考えられる、マルチ、家へ帰り、1つ以上が同時にそれでIPアドレスをグローバルに発送可能するなら。 IPが一緒に扱うHIPリンク、複数のIPアドレスが同じHost Identityに一致しているとき、1つのアドレスが使用不可能になるか、または、より都合のよいアドレスが利用可能になるなら、容易に既存の輸送協会を別のアドレスに動かすことができます。
When a node moves while communication is already ongoing, address changes are rather straightforward. The peer of the mobile node can just accept a HIP or an integrity protected IPsec packet from any address and ignore the source address. However, as discussed in Section 7.2 below, a mobile node must send a HIP readdress packet to inform the peer of the new address(es), and the peer must verify that the mobile node is reachable through these addresses. This is especially helpful for those situations where the peer node is sending data periodically to the mobile node (that is restarting a connection after the initial connection).
コミュニケーションが既に進行中である間ノードが移行するとき、アドレス変化はかなり簡単です。 モバイルノードの同輩は、どんなアドレスからもHIPか保全の保護されたIPsecパケットをただ受け入れて、ソースアドレスを無視できます。 しかしながら、以下に、モバイルノードが送らなければならないセクション7.2で議論するように、HIPは新しいアドレス(es)について同輩に知らせるためにパケットにあて名を書き直させます、そして、同輩はモバイルノードにこれらのアドレスを通って届いていることを確かめなければなりません。 それらの状況において、これは同輩ノードが定期的にモバイルノード(すなわち、初期の接続の後に接続を再出発する)にデータを送るところで特に役立っています。
Moskowitz & Nikander Informational [Page 12] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[12ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
7.1. Rendezvous Mechanism
7.1. ランデブーメカニズム
Making a contact to a mobile node is slightly more involved. In order to start the HIP exchange, the initiator node has to know how to reach the mobile node. Although infrequently moving HIP nodes could use Dynamic DNS [1] to update their reachability information in the DNS, an alternative to using DNS in this fashion is to use a piece of new static infrastructure to facilitate rendezvous between HIP nodes.
接触をモバイルノードにするのはわずかにさらにかかわります。 HIP交換を始めるために、創始者ノードはモバイルノードに達する方法を知らなければなりません。 HIPノードをまれに動かすと、Dynamic DNS[1]はDNSの彼らの可到達性情報をアップデートするのに使用されるかもしれませんが、こんなやり方でDNSを使用することへの代替手段はHIPノードの間のランデブーを容易にするのに1つの新しい静的なインフラストラクチャを使用することです。
The mobile node keeps the rendezvous infrastructure continuously updated with its current IP address(es). The mobile nodes must trust the rendezvous mechanism to properly maintain their HIT and IP address mappings.
モバイルノードは、現在のIPアドレス(es)で絶え間なくランデブーインフラストラクチャをアップデートし続けます。 モバイルノードは、適切にそれらのHITとIPアドレス・マッピングを維持するためにランデブーメカニズムを信じなければなりません。
The rendezvous mechanism is also needed if both of the nodes happen to change their address at the same time, either because they are mobile and happen to move at the same time, because one of them is off-line for a while, or because of some other reason. In such a case, the HIP readdress packets will cross each other in the network and never reach the peer node.
また、ノードの両方が同時にそれらの1つがしばらくオフラインであるので、それらがモバイルであり、同時にたまたま移行するためかある他の理由のでたまたま住所を変更するなら、ランデブーメカニズムが必要です。 このような場合には、HIPはパケット意志の交差している互いにネットワークであて名を書き直させて、同輩ノードに決して達しません。
A separate document will specify the details of the HIP rendezvous mechanism.
別々のドキュメントはHIPランデブーメカニズムの細部を指定するでしょう。
7.2. Protection against Flooding Attacks
7.2. フラッディング攻撃に対する保護
Although the idea of informing about address changes by simply sending packets with a new source address appears appealing, it is not secure enough. That is, even if HIP does not rely on the source address for anything (once the base exchange has been completed), it appears to be necessary to check a mobile node's reachability at the new address before actually sending any larger amounts of traffic to the new address.
新しいソースアドレスでアドレス変化に関して単にパケットを送ることによって知らせるという考えは魅力的に見えますが、それは十分安全ではありません。 すなわち、HIPが何のためのもソースアドレスを当てにしないでも(塩基置換がいったん終了されると)、実際にどんな多く以上の量のトラフィックも新しいアドレスに送る前に新しいアドレスでモバイルノードの可到達性をチェックするのが必要であるように見えます。
Blindly accepting new addresses would potentially lead to flooding DoS attacks against third parties [8]. In a distributed flooding attack, an attacker opens high-volume HIP connections with a large number of hosts (using unpublished HIs), and then claims to all of these hosts that it has moved to a target node's IP address. If the peer hosts were to simply accept the move, the result would be a packet flood to the target node's address. To close this attack, HIP includes an address check mechanism where the reachability of a node is separately checked at each address before using the address for larger amounts of traffic.
盲目的に新しいアドレスを受け入れるのは、第三者[8]に対してDoS攻撃をあふれさせるのに潜在的に通じるでしょう。 分配されたフラッディング攻撃では、攻撃者は、多くのホスト(未発表のHIsを使用します)との大容量HIP接続を開いて、次に、それが目標ノードのIPアドレスに移行したとこれらのホストのすべてに主張します。 同輩ホストが単に移動を受け入れるなら、結果は目標ノードのアドレスへのパケット洪水でしょうに。 この攻撃を終えるために、HIPは多く以上の量のトラフィックにアドレスを使用する前にノードの可到達性が別々に各アドレスでチェックされるアドレス検査メカニズムを含んでいます。
Whenever HIP is used between two hosts that fully trust each other, the hosts may optionally decide to skip the address tests. However,
HIPが互いを完全に信じる2人のホストの間で使用されるときはいつも、ホストは、アドレステストをサボると任意に決めるかもしれません。 しかしながら
Moskowitz & Nikander Informational [Page 13] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[13ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
such performance optimization must be restricted to peers that are known to be trustworthy and capable of protecting themselves from malicious software.
そのようなパフォーマンスの最適化を信頼できて悪意があるソフトウェアから我が身をかばうことができるのが知られている同輩に制限しなければなりません。
8. HIP and IPsec
8. ヒップとIPsec
The preferred way of implementing HIP is to use IPsec to carry the actual data traffic. As of today, the only completely defined method is to use IPsec Encapsulating Security Payload (ESP) to carry the data packets. In the future, other ways of transporting payload data may be developed, including ones that do not use cryptographic protection.
HIPを実装する都合のよい方法は実際のデータ通信量を運ぶのにIPsecを使用することです。 今日現在、唯一の完全に定義されたメソッドはデータ・パケットを運ぶのに、IPsec Encapsulating Security有効搭載量(超能力)を使用することです。 将来、暗号の保護を使用しないものを含んでいて、ペイロードデータを輸送する他の方法は開発されるかもしれません。
In practice, the HIP base exchange uses the cryptographic Host Identifiers to set up a pair of ESP Security Associations (SAs) to enable ESP in an end-to-end manner. This is implemented in a way that can span addressing realms.
実際には、HIP塩基置換は、終わりから終わりへの方法で超能力を可能にするために、1組の超能力Security Associations(SAs)をセットアップするのに暗号のHost Identifiersを使用します。 これは分野に演説しながらわたることができる方法で実装されます。
While it would be possible, at least in theory, to use some existing cryptographic protocol, such as IKEv2 together with Host Identifiers, to establish the needed SAs, HIP defines a new protocol. There are a number of historical reasons for this, and there are also a few architectural reasons. First, IKE and IKEv2 were not designed with middle boxes in mind. As adding a new naming layer allows one to potentially add a new forwarding layer (see Section 9, below), it is very important that the HIP protocols are friendly toward any middle boxes.
それは可能でしょうが、Host Identifiersに伴うIKEv2などの既存の暗号の何らかのプロトコルを使用して、必要なSAsを証明するために、少なくとも理論上、HIPは新しいプロトコルを定義します。 多くのこの歴史的な理由があります、そして、また、いくつかの建築理由があります。 まず最初に、IKEとIKEv2は中央箱で念頭に設計されませんでした。 人が新しい命名層で潜在的に新しい推進層を加えることができる(以下でセクション9を見る)と言い足すとして、HIPプロトコルがどんな中央箱に向かっても好意的であることは、非常に重要です。
Second, from a conceptual point of view, the IPsec Security Parameter Index (SPI) in ESP provides a simple compression of the HITs. This does require per-HIT-pair SAs (and SPIs), and a decrease of policy granularity over other Key Management Protocols, such as IKE and IKEv2. In particular, the current thinking is limited to a situation where, conceptually, there is only one pair of SAs between any given pair of HITs. In other words, from an architectural point of view, HIP only supports host-to-host (or endpoint-to-endpoint) Security Associations. If two hosts need more pairs of parallel SAs, they should use separate HITs for that. However, future HIP extensions may provide for more granularity and creation of several ESP SAs between a pair of HITs.
2番目に、概念的な観点から、超能力におけるIPsec Security Parameter Index(SPI)はHITsの簡単な圧縮を提供します。 これは他のKey Managementプロトコルに関してHIT組あたりSAs(そして、SPIs)、および方針粒状の1回の減少を必要とします、IKEやIKEv2のように。 特に、現在の考えはどんな与えられた組のHITsの間にも1組のSAsしか概念的にない状況に制限されます。 言い換えれば、建築観点から、HIPはホストからホスト(または、終点から終点)へのセキュリティAssociationsをサポートするだけです。 2人のホストが、より多くの組の平行なSAsを必要とするなら、彼らはそれに別々のHITsを使用するべきです。 しかしながら、将来のHIP拡張子は1組のHITsの間の数個の超能力SAsの、より多くの粒状と作成に備えるかもしれません。
Since HIP is designed for host usage, not for gateways or so-called Bump-in-the-Wire (BITW) implementations, only ESP transport mode is supported. An ESP SA pair is indexed by the SPIs and the two HITs (both HITs since a system can have more than one HIT). The SAs need not be bound to IP addresses; all internal control of the SA is by the HITs. Thus, a host can easily change its address using Mobile IP, DHCP, PPP, or IPv6 readdressing and still maintain the SAs.
HIPがゲートウェイかワイヤのいわゆるBump(BITW)実装のために設計されているのではなく、ホスト用法のために設計されているので、超能力交通機関だけがサポートされます。 ESP SA組はSPIsと2HITsによって索引をつけられます(システム以来の両方のHITsは1HITを持つことができます)。 SAsはIPアドレスに縛られる必要はありません。 SAのすべての内部管理がHITsであります。 したがって、ホストは、モバイルIP、DHCP、PPP、またはIPv6のあて名を書き直すことを使用することで容易に住所を変更して、まだSAsを維持できます。
Moskowitz & Nikander Informational [Page 14] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[14ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
Since the transports are bound to the SA (via an LSI or a HIT), any active transport is also maintained. Thus, real-world conditions like loss of a PPP connection and its re-establishment or a mobile handover will not require a HIP negotiation or disruption of transport services [12].
輸送がSA(LSIかHITを通した)に縛られるので、また、どんな能動輸送も維持されます。 したがって、PPP接続とその再建の損失やモバイル引き渡しのような本当の世界状態は輸送サービス[12]のHIP交渉か分裂を必要としないでしょう。
Since HIP does not negotiate any SA lifetimes, all lifetimes are local policy. The only lifetimes a HIP implementation must support are sequence number rollover (for replay protection) and SA timeout. An SA times out if no packets are received using that SA. Implementations may support lifetimes for the various ESP transforms.
HIPがどんなSA生涯も交渉しないので、すべての寿命がローカルの方針です。 HIP実装がサポートしなければならない唯一の寿命が、一連番号ロールオーバー(反復操作による保護のための)とSAタイムアウトです。 SA回のアウトはパケットでないならそのSAを使用するのにおいて受け取られています。 実装は様々な超能力変換のために生涯をサポートするかもしれません。
9. HIP and NATs
9. ヒップとNATs
Passing packets between different IP addressing realms requires changing IP addresses in the packet header. This may happen, for example, when a packet is passed between the public Internet and a private address space, or between IPv4 and IPv6 networks. The address translation is usually implemented as Network Address Translation (NAT) [4] or NAT Protocol Translation (NAT-PT) [3].
異なったIPアドレシング分野の間にパケットを通過するのは、パケットのヘッダーでIPアドレスを変えるのを必要とします。 パケットが公共のインターネットとプライベート・アドレススペースの間、または、IPv4とIPv6ネットワークの間で通過されるとき、例えば、これは起こるかもしれません。 通常、アドレス変換はNetwork Address Translation(NAT)[4]かNATプロトコルTranslation(太平洋標準時のNAT)[3]として実装されます。
In a network environment where identification is based on the IP addresses, identifying the communicating nodes is difficult when NAT is used. With HIP, the transport-layer end-points are bound to the Host Identities. Thus, a connection between two hosts can traverse many addressing realm boundaries. The IP addresses are used only for routing purposes; they may be changed freely during packet traversal.
識別がIPアドレスに基づいているネットワーク環境で、NATが使用されているとき、交信ノードを特定するのは難しいです。 HIPと共に、トランスポート層エンドポイントはHost Identitiesに縛られます。 したがって、2人のホストの間の接続は多くのアドレシング分野の限界を横断できます。 IPアドレスはルーティング目的にだけ使用されます。 パケット縦断の間、自由にそれらを変えるかもしれません。
For a HIP-based flow, a HIP-aware NAT or NAT-PT system tracks the mapping of HITs, and the corresponding IPsec SPIs, to an IP address. The NAT system has to learn mappings both from HITs and from SPIs to IP addresses. Many HITs (and SPIs) can map to a single IP address on a NAT, simplifying connections on address-poor NAT interfaces. The NAT can gain much of its knowledge from the HIP packets themselves; however, some NAT configuration may be necessary.
HIPベースの流れのために、HIP意識しているNATか太平洋標準時のNATシステムはHITsに関するマッピング、および対応するIPsec SPIsを追跡します、IPアドレスに。 NATシステムはHITsとSPIsからIPアドレスまでマッピングを学ばなければなりません。 アドレス貧しいNATインタフェースで接続を簡素化して、多くのHITs(そして、SPIs)がNATに関するアドレスを単一のIPに写像できます。 NATはHIPパケット自体から知識の多くを獲得できます。 しかしながら、何らかのNAT構成が必要であるかもしれません。
NAT systems cannot touch the datagrams within the IPsec envelope; thus, application-specific address translation must be done in the end systems. HIP provides for 'Distributed NAT', and uses the HIT or the LSI as a placeholder for embedded IP addresses.
NATシステムはIPsec封筒の中にデータグラムに触れることができません。 エンドシステムでしたがって、アプリケーション特有のアドレス変換をしなければなりません。HIPは埋め込まれたIPアドレスにプレースホルダとして'分配されたNAT'に備えて、HITかLSIを使用します。
9.1. HIP and TCP Checksums
9.1. ヒップとTCPチェックサム
There is no way for a host to know if any of the IP addresses in an IP header are the addresses used to calculate the TCP checksum. That is, it is not feasible to calculate the TCP checksum using the actual IP addresses in the pseudo header; the addresses received in the incoming packet are not necessarily the same as they were on the
ホストがIPヘッダーのIPアドレスのどれかがTCPチェックサムについて計算するのに使用されるアドレスであるかどうかを知る方法が全くありません。 すなわち、疑似ヘッダーで実際のIPアドレスを使用するTCPチェックサムについて計算するのは可能ではありません。 入って来るパケットに受け取られたアドレスは必ずそれらがオンであったのと同じであるというわけではありません。
Moskowitz & Nikander Informational [Page 15] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[15ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
sending host. Furthermore, it is not possible to recompute the upper-layer checksums in the NAT/NAT-PT system, since the traffic is IPsec protected. Consequently, the TCP and UDP checksums are calculated using the HITs in the place of the IP addresses in the pseudo header. Furthermore, only the IPv6 pseudo header format is used. This provides for IPv4/IPv6 protocol translation.
ホストを送ります。 その上、recomputeには、太平洋標準時のNAT/NATシステムの上側の層のチェックサムでありIPsecがトラフィックがそうので保護したのは、可能ではありません。 その結果、TCPとUDPチェックサムは、疑似ヘッダーでIPアドレスの場所でHITsを使用することで計算されます。 その上、IPv6疑似ヘッダー形式だけが使用されています。 これはIPv4/IPv6プロトコル変換に備えます。
10. Multicast
10. マルチキャスト
Back in the Fall of 2003, there were little if any concrete thoughts about how HIP might affect IP-layer or application-layer multicast.
2003年のFallに戻ります、HIPがどうIP-層か応用層マルチキャストに影響するかもしれないかに関するまずの具体的な考えがありました。
11. HIP Policies
11. クールな方針
There are a number of variables that will influence the HIP exchanges that each host must support. All HIP implementations should support at least 2 HIs, one to publish in DNS and an unpublished one for anonymous usage. Although unpublished HIs will be rarely used as responder HIs, they are likely be common for initiators. Support for multiple HIs is recommended.
各ホストがサポートしなければならないHIP交換に影響を及ぼす多くの変数があります。 すべてのHIP実装が少なくとも2HIs(匿名の用法のためにDNSと未発表のもので発行する1つ)をサポートするべきです。 未発表のHIsは応答者HIsとしてめったに使用されないでしょうが、彼らはありそうであるのが、創始者のためのコモンであるということです。 複数のHIsのサポートはお勧めです。
Many initiators would want to use a different HI for different responders. The implementations should provide for a policy of initiator HIT to responder HIT. This policy should also include preferred transforms and local lifetimes.
多くの創始者が異なった応答者に異なったHIを使用したがっているでしょう。 実装は創始者HITの方針に応答者HITに備えるべきです。 また、この方針は都合のよい変換と地方の生涯を含むべきです。
Responders would need a similar policy, describing the hosts allowed to participate in HIP exchanges, and the preferred transforms and local lifetimes.
応答者は同様の方針を必要とするでしょう、HIP交換に参加できたホスト、都合のよい変換、および地方の生涯について説明して。
12. Benefits of HIP
12. ヒップの利益
In the beginning, the network layer protocol (i.e., IP) had the following four "classic" invariants:
初めに、ネットワーク層プロトコル(すなわち、IP)には、以下の4つの「古典的な」不変式がありました:
o Non-mutable: The address sent is the address received.
o 非無常: 送られたアドレスは受け取られたアドレスです。
o Non-mobile: The address does not change during the course of an
"association".
o 非モバイル: アドレスは「協会」のコースの間、変化しません。
o Reversible: A return header can always be formed by reversing the
source and destination addresses.
o リバーシブル: ソースと送付先アドレスを逆にすることによって、リターンヘッダーをいつも形成できます。
o Omniscient: Each host knows what address a partner host can use to
send packets to it.
o 全知: 各ホストは、パートナーホストがパケットをそれに送るのにどんなアドレスを使用できるかを知っています。
Actually, the fourth can be inferred from 1 and 3, but it is worth mentioning for reasons that will be obvious soon if not already.
実際に、1と3から4番目を推論できますが、理由でそれがすぐか既に明白になると言及する価値があります。
Moskowitz & Nikander Informational [Page 16] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[16ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
In the current "post-classic" world, we are intentionally trying to get rid of the second invariant (both for mobility and for multi- homing), and we have been forced to give up the first and the fourth. Realm Specific IP [5] is an attempt to reinstate the fourth invariant without the first invariant. IPv6 is an attempt to reinstate the first invariant.
現在の「ポスト古典的な」世界では、私たちが故意に、2番目の不変式(移動性とマルチの家へ帰りのための)を取り除こうとしています、そして、やむを得ず1番目と4番目をあきらめました。 分野Specific IP[5]は最初の不変式なしで4番目の不変式を復職させる試みです。 IPv6は最初の不変式を復職させる試みです。
Few systems on the Internet have DNS names that are meaningful. That is, if they have a Fully Qualified Domain Name (FQDN), that name typically belongs to a NAT device or a dial-up server, and does not really identify the system itself but its current connectivity. FQDNs (and their extensions as email names) are application-layer names, more frequently naming services than a particular system. This is why many systems on the Internet are not registered in the DNS; they do not have services of interest to other Internet hosts.
インターネットのわずかなシステムにはしか、重要なDNS名がありません。 すなわち、彼らがFully Qualified Domain Name(FQDN)を持っているなら、その名前はNATデバイスかダイヤルアップサーバに通常属して、本当にシステム自体を特定するのではなく、現在の接続性を特定します。 頻繁にFQDNs(そして、メール名としての彼らの拡大)は応用層名、特定のシステムより名前付けサービスです。 これはインターネットの多くのシステムがDNSに登録されない理由です。 彼らには、他のインターネット・ホストにとって、興味深いサービスがありません。
DNS names are references to IP addresses. This only demonstrates the interrelationship of the networking and application layers. DNS, as the Internet's only deployed, distributed database, is also the repository of other namespaces, due in part to DNSSEC-specific and application-specific key records. Although each namespace can be stretched (IP with v6, DNS with KEY records), neither can adequately provide for host authentication or act as a separation between internetworking and transport layers.
DNS名はIPアドレスの参照です。 これはネットワークと応用層の相互関係を示すだけです。 DNS、また、インターネットが展開するだけであったので分散データベースが他の名前空間の倉庫である、一部DNSSEC特有の、そして、アプリケーション特有のキーへの支払われるべきものは記録します。 各名前空間を伸ばすことができますが(v6とIP、KEYとDNSは記録します)、インターネットワーキングと輸送の間の分離が層にされるとき、どちらも、適切にホスト認証に備えることができませんし、行動できません。
The Host Identity (HI) namespace fills an important gap between the IP and DNS namespaces. An interesting thing about the HI is that it actually allows one to give up all but the 3rd network-layer invariant. That is to say, as long as the source and destination addresses in the network-layer protocol are reversible, then things work OK because HIP takes care of host identification, and reversibility allows one to get a packet back to one's partner host. You do not care if the network-layer address changes in transit (mutable), and you do not care what network-layer address the partner is using (non-omniscient).
Host Identity(HI)名前空間はIPとDNS名前空間の重要な不足をいっぱいにしています。 HIの周りのおもしろいものは人が実際にそれで3番目のネットワーク層不変式以外のすべてをあきらめることができるということです。 すなわち、HIPがホスト識別の世話をするので、ネットワーク層プロトコルのソースと送付先アドレスがリバーシブルである限り、次に、いろいろなことはOKに働いています、そして、リバーシブルは1つが人のパートナーホストにパケットを取り戻すのを許容します。 あなたは、ネットワーク層アドレスがトランジット(無常の)で変化するかどうか気にかけません、そして、パートナーがどんなネットワーク層アドレスを使用しているかを(非全知の)気にかけません。
12.1. HIP's Answers to NSRG Questions
12.1. ヒップのNSRG質問の答え
The IRTF Name Space Research Group has posed a number of evaluating questions in its report [7]. In this section, we provide answers to these questions.
IRTF Name Space Research Groupはレポート[7]で多くの評価に質問を提出しました。 このセクションに、私たちはこれらの質問の答えを供給します。
1. How would a stack name improve the overall functionality of the
Internet?
1. スタック名はどのようにインターネットの総合的な機能性を改良しますか?
HIP decouples the internetworking layer from the transport
layer, allowing each to evolve separately. The decoupling
makes end-host mobility and multi-homing easier, also across
それぞれが別々に発展するのを許容して、HIPはトランスポート層からインターネットワーキング層の衝撃を吸収します。 デカップリングで、終わりホストの移動性とマルチホーミングは、より簡単で、また、直径になります。
Moskowitz & Nikander Informational [Page 17] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[17ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
IPv4 and IPv6 networks. HIs make network renumbering easier,
and they also make process migration and clustered servers
easier to implement. Furthermore, being cryptographic in
nature, they provide the basis for solving the security
problems related to end-host mobility and multi-homing.
IPv4とIPv6ネットワーク。 HIsでネットワークの番号を付け替えるのは、より簡単になります、そして、また、彼らはプロセス移行とクラスタリングしているサーバを実装するのをより簡単にします。 その上、現実に暗号であり、彼らは終わりホストの移動性とマルチホーミングに関連する警備上の問題を解決する基礎を提供します。
2. What does a stack name look like?
2. スタック名は何に似ていますか?
A HI is a cryptographic public key. However, instead of using
the keys directly, most protocols use a fixed-size hash of the
public key.
HIは暗号の公開鍵です。 しかしながら、直接キーを使用することの代わりに、ほとんどのプロトコルが公開鍵の固定サイズハッシュを使用します。
3. What is its lifetime?
3. 寿命は何ですか?
HIP provides both stable and temporary Host Identifiers.
Stable HIs are typically long-lived, with a lifetime of years
or more. The lifetime of temporary HIs depends on how long
the upper-layer connections and applications need them, and
can range from a few seconds to years.
HIPは安定して一時的の両方Host Identifiersを提供します。 安定したHIsは何年もの以上の生涯で通常長命です。 一時的なHIsの寿命は、上側の層の接続とアプリケーションがどれくらい長い間それらを必要とするかによって、数秒から何年も及ぶことができます。
4. Where does it live in the stack?
4. どこで、それはスタックで生活していますか?
The HIs live between the transport and internetworking layers.
HIsは輸送とインターネットワーキング層の間に住んでいます。
5. How is it used on the end-points?
5. それはエンドポイントでどのように使用されますか?
The Host Identifiers may be used directly or indirectly (in
the form of HITs or LSIs) by applications when they access
network services. In addition, the Host Identifiers, as
public keys, are used in the built-in key agreement protocol,
called the HIP base exchange, to authenticate the hosts to
each other.
ネットワーク・サービスにアクセスするとき、Host Identifiersはアプリケーションで直接か間接的(HITsかLSIの形で)に使用されるかもしれません。 さらに、公開鍵として、Host Identifiersは、互いのホストを認証するのにHIP塩基置換と呼ばれる内蔵の主要な協定プロトコルに使用されます。
6. What administrative infrastructure is needed to support it?
6. どんな管理インフラストラクチャが、それをサポートするのに必要ですか?
In some environments, it is possible to use HIP
opportunistically, without any infrastructure. However, to
gain full benefit from HIP, the HIs must be stored in the DNS
or a PKI, and a new rendezvous mechanism is needed. Such a
new rendezvous mechanism may need new infrastructure to be
deployed.
いくつかの環境で、少しもインフラストラクチャなしでHIPを便宜主義的に使用するのは可能です。 しかしながら、HIPから完全給付を獲得するために、DNSかPKIにHIsを保存しなければなりません、そして、新しいランデブーメカニズムが必要です。 そのような新しいランデブーメカニズムは、新社会資本が配布される必要があるかもしれません。
7. If we add an additional layer, would it make the address list in
Stream Control Transmission Protocol (SCTP) unnecessary?
7. 私たちが追加層を加えるなら、それで、Stream Control Transmissionプロトコル(SCTP)の住所録は不要になるでしょうか?
Yes.
はい。
Moskowitz & Nikander Informational [Page 18] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[18ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
8. What additional security benefits would a new naming scheme
offer?
8. 新しい命名体系はどんな追加担保利益を提供するでしょうか?
HIP reduces dependency on IP addresses, making the so-called
address ownership [11] problems easier to solve. In practice,
HIP provides security for end-host mobility and multi-homing.
Furthermore, since HIP Host Identifiers are public keys,
standard public key certificate infrastructures can be applied
on the top of HIP.
いわゆるアドレス所有権[11]をより解決しやすい問題にして、HIPはIPアドレスで依存を減少させます。 実際には、HIPは終わりホストの移動性とマルチホーミングにセキュリティを提供します。 その上、HIP Host Identifiersが公開鍵であるので、標準の公開鍵証明書インフラストラクチャをHIPの先端に適用できます。
9. What would the resolution mechanisms be, or what characteristics
of a resolution mechanisms would be required?
9. 解決メカニズムは何であるだろうか、そして、メカニズムがそうする解決のどんな特性が必要ですか?
For most purposes, an approach where DNS names are resolved
simultaneously to HIs and IP addresses is sufficient.
However, if it becomes necessary to resolve HIs into IP
addresses or back to DNS names, a flat resolution
infrastructure is needed. Such an infrastructure could be
based on the ideas of Distributed Hash Tables, but would
require significant new development and deployment.
ほとんどの目的のために、DNS名が同時にHIsとIPアドレスに決議されているところでアプローチは十分です。 しかしながら、IPアドレスにHIsに変えるために必要であるかDNS名に戻るようになるなら、平坦な解決インフラストラクチャが必要です。 そのようなインフラストラクチャは、Distributed Hash Tablesの考えに基づくことができましたが、重要な新開発と展開を必要とするでしょう。
13. Security Considerations
13. セキュリティ問題
HIP takes advantage of the new Host Identity paradigm to provide secure authentication of hosts and to provide a fast key exchange for IPsec. HIP also attempts to limit the exposure of the host to various Denial-of-Service (DoS) and Man-in-the-Middle (MitM) attacks. In so doing, HIP itself is subject to its own DoS and MitM attacks that potentially could be more damaging to a host's ability to conduct business as usual.
HIPは、ホストの安全な認証を提供して、速いIPsecに、主要な交換を供給するのに新しいHost Identityパラダイムを利用します。 また、HIPは、ホストの暴露を様々なサービス妨害(DoS)と中央のMan(MitM)攻撃に制限するのを試みます。 そうする際に、HIP自身は潜在的にいつもどおりの仕事を行うホストの能力によりダメージが大きいかもしれないそれ自身のDoSとMitM攻撃を受けることがあります。
Resource-exhausting DoS attacks take advantage of the cost of setting up a state for a protocol on the responder compared to the 'cheapness' on the initiator. HIP allows a responder to increase the cost of the start of state on the initiator and makes an effort to reduce the cost to the responder. This is done by having the responder start the authenticated Diffie-Hellman exchange instead of the initiator, making the HIP base exchange 4 packets long. There are more details on this process in the Host Identity Protocol.
リソースを枯渇させるDoS攻撃は創始者の'cheapness'と比べて、プロトコルのために応答者に状態を設立する費用を利用します。 HIPは、応答者が創始者における状態の始まりの費用を増強するのを許容して、応答者に生産費を切り下げるために取り組みを作ります。 応答者に創始者の代わりに認証されたディフィー-ヘルマンの交換を始めさせることによって、これをします、HIP塩基置換4パケットを長くして。 Host Identityプロトコルにはこのプロセスに関するその他の詳細があります。
HIP optionally supports opportunistic negotiation. That is, if a host receives a start of transport without a HIP negotiation, it can attempt to force a HIP exchange before accepting the connection. This has the potential for DoS attacks against both hosts. If the method to force the start of HIP is expensive on either host, the attacker need only spoof a TCP SYN. This would put both systems into the expensive operations. HIP avoids this attack by having the responder send a simple HIP packet that it can pre-build. Since this
HIPは任意に便宜主義的な交渉をサポートします。 すなわち、ホストがHIP交渉なしで輸送の始まりを受けるなら、それは、接続を受け入れる前にHIP交換を強制するのを試みることができます。 これはDoS攻撃の可能性を両方のホストに抱きます。 HIPの始まりを強制するメソッドがどちらかのホストで高価であるなら、攻撃者はTCP SYNを偽造するだけでよいです。 これは高価な操作に両方のシステムを入れるでしょう。 応答者にそれがあらかじめ建てることができる簡単なHIPパケットを送らせることによって、HIPはこの攻撃を避けます。 これ以来
Moskowitz & Nikander Informational [Page 19] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[19ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
packet is fixed and easily replayed, the initiator reacts to it only if it has just started a connection to the responder.
修理されていて、容易に再演されたパケット、ちょうど接続を応答者に始めたところな場合にだけ、創始者はそれに反応します。
MitM attacks are difficult to defend against, without third-party authentication. A skillful MitM could easily handle all parts of the HIP base exchange, but HIP indirectly provides the following protection from an MitM attack. If the responder's HI is retrieved from a signed DNS zone or secured by some other means, the initiator can use this to authenticate the signed HIP packets. Likewise, if the initiator's HI is in a secure DNS zone, the responder can retrieve it and validate the signed HIP packets. However, since an initiator may choose to use an unpublished HI, it knowingly risks an MitM attack. The responder may choose not to accept a HIP exchange with an initiator using an unknown HI.
MitM攻撃は第三者認証なしで防御するのが難しいです。 巧みなMitMは容易にHIP塩基置換のすべての部品を扱うことができましたが、HIPはMitM攻撃から以下の保護を間接的に提供します。 応答者のHIを署名しているDNSゾーンから検索するか、またはある他の手段で確保するなら、創始者は、署名しているHIPパケットを認証するのにこれを使用できます。 同様に、創始者のHIが安全なDNSゾーンにあるなら、応答者は、それを検索して、署名しているHIPパケットを有効にすることができます。 しかしながら、創始者が、未発表のHIを使用するのを選ぶかもしれないので、それは故意にMitM攻撃を危険にさらします。 応答者は、創始者と共に未知のHIを使用することでHIP交換を受け入れないのを選ぶかもしれません。
In HIP, the Security Association for IPsec is indexed by the SPI; the source address is always ignored, and the destination address may be ignored as well. Therefore, HIP-enabled IPsec Encapsulated Security Payload (ESP) is IP address independent. This might seem to make it easier for an attacker, but ESP with replay protection is already as well protected as possible, and the removal of the IP address as a check should not increase the exposure of IPsec ESP to DoS attacks.
HIPでは、IPsecのためのSecurity AssociationはSPIによって索引をつけられます。 ソースアドレスはいつも無視されます、そして、また、送付先アドレスは無視されるかもしれません。 したがって、HIPによって可能にされたIPsec Encapsulated Security有効搭載量(超能力)はIPアドレス独立者です。 これはそれを攻撃者には、より簡単にしますが、保護が既にまた、保護される再生がある超能力を可能にするように思えるかもしれません、そして、チェックとしてのIPアドレスの取り外しはDoSへの超能力が攻撃するIPsecの展示を増強するべきではありません。
Since not all hosts will ever support HIP, ICMPv4 'Destination Unreachable, Protocol Unreachable' and ICMPv6 'Parameter Problem, Unrecognized Next Header' messages are to be expected and present a DoS attack. Against an initiator, the attack would look like the responder does not support HIP, but shortly after receiving the ICMP message, the initiator would receive a valid HIP packet. Thus, to protect against this attack, an initiator should not react to an ICMP message until a reasonable time has passed, allowing it to get the real responder's HIP packet. A similar attack against the responder is more involved.
ホストがHIP、ICMPv4の'の目的地のUnreachableと、プロトコルUnreachableと'ICMPv6'パラメタProblemをサポートするというわけではないすべて以来、Unrecognized Next Header'メッセージは、予想されて、DoS攻撃を提示することです。 創始者に対して、攻撃は、応答者がHIPをサポートしないように見えるでしょうが、ICMPメッセージを受け取ったすぐ後に、創始者は有効なHIPパケットを受けるでしょう。 したがって、この攻撃から守るために、妥当な時間が経過するまで、創始者はICMPメッセージに反応するべきではありません、本当の応答者のHIPパケットを得るのを許容して。 応答者に対する同様の攻撃はさらにかかわります。
Another MitM attack is simulating a responder's administrative rejection of a HIP initiation. This is a simple ICMP 'Destination Unreachable, Administratively Prohibited' message. A HIP packet is not used because it would have to either have unique content, and thus difficult to generate, resulting in yet another DoS attack, or be just as spoofable as the ICMP message. Like in the previous case, the defense against this attack is for the initiator to wait a reasonable time period to get a valid HIP packet. If one does not come, then the initiator has to assume that the ICMP message is valid. Since this is the only point in the HIP base exchange where this ICMP message is appropriate, it can be ignored at any other point in the exchange.
別のMitM攻撃は応答者のHIP開始の管理拒絶をシミュレートしています。 これは簡単なICMP'目的地Unreachable、Administratively Prohibited'メッセージです。 HIPパケットはそれには、ユニークな内容がなければならないでしょう、したがって、同じくらい中古でなくて、その結果、さらに別のDoS攻撃をもたらして、生成するのが同じくらい難しいか、ICMPメッセージとまたはちょうど同じくらい偽造可能であってください。 先の事件などのように、この攻撃に対するディフェンスは創始者が有効なHIPパケットを得るために妥当な期間を待つことです。 1つが来ないなら、創始者は、ICMPメッセージが有効であると仮定しなければなりません。 これがHIP塩基置換でこのICMPメッセージが適切である唯一のポイントであるので、いかなる他のポイントでも交換でそれを無視できます。
Moskowitz & Nikander Informational [Page 20] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[20ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
13.1. HITs Used in ACLs
13.1. ACLsで使用されるヒット
It is expected that HITs will be used in Access Control Lists (ACLs). Future firewalls can use HITs to control egress and ingress to networks, with an assurance level difficult to achieve today. As discussed above in Section 8, once a HIP session has been established, the SPI value in an IPsec packet may be used as an index, indicating the HITs. In practice, firewalls can inspect HIP packets to learn of the bindings between HITs, SPI values, and IP addresses. They can even explicitly control IPsec usage, dynamically opening IPsec ESP only for specific SPI values and IP addresses. The signatures in HIP packets allow a capable firewall to ensure that the HIP exchange is indeed happening between two known hosts. This may increase firewall security.
HITsがAccess Control Lists(ACLs)で使用されると予想されます。 将来のファイアウォールは、保証レベルが今日達成するのが難しい状態で出口とイングレスをネットワークに制御するのにHITsを使用できます。 セクション8で上で議論するように、HIPセッションがいったん確立されると、IPsecパケットのSPI値はインデックスとして使用されるかもしれません、HITsを示して。 実際には、ファイアウォールは、HITsの間の結合、SPI値、およびIPアドレスを知るためにHIPパケットを点検できます。 ダイナミックに、特定のSPIのためだけの超能力が評価して、IPが扱うIPsecを開いて、彼らは明らかにIPsec用法を制御さえできます。 HIPパケットの署名で、できるファイアウォールは、本当に、HIP交換が2人の知られているホストの間で起こっているのを保証できます。 これはファイアウォールセキュリティを増強するかもしれません。
There has been considerable bad experience with distributed ACLs that contain public-key-related material, for example, with Secure SHell Protocol (SSH). If the owner of a key needs to revoke it for any reason, the task of finding all locations where the key is held in an ACL may be impossible. If the reason for the revocation is due to private key theft, this could be a serious issue.
例えばSecure SHellプロトコル(SSH)で公開鍵関連の材料を含む分配されたACLsにはかなりの悪い経験がありました。 キーの所有者が、どんな理由でもそれを取り消す必要があるなら、かぎがACLで握られるすべての位置を見つけるタスクは不可能であるかもしれません。 取消しの理由が秘密鍵窃盗のためであるなら、これは重大な問題であるかもしれません。
A host can keep track of all of its partners that might use its HIT in an ACL by logging all remote HITs. It should only be necessary to log responder hosts. With this information, the host can notify the various hosts about the change to the HIT. There has been no attempt to develop a secure method to issue the HIT revocation notice.
ホストはACLですべてのリモートHITsを登録することによってHITを使用するかもしれないパートナーのすべての動向をおさえることができます。 単に応答者ホストを登録するのが必要であるべきです。 この情報で、ホストはHITへの変化に関して様々なホストに通知できます。 HIT取消し通知を発行する安全なメソッドを開発する試みが全くありませんでした。
HIP-aware NATs, however, are transparent to the HIP-aware systems by design. Thus, the host may find it difficult to notify any NAT that is using a HIT in an ACL. Since most systems will know of the NATs for their network, there should be a process by which they can notify these NATs of the change of the HIT. This is mandatory for systems that function as responders behind a NAT. In a similar vein, if a host is notified of a change in a HIT of an initiator, it should notify its NAT of the change. In this manner, NATs will get updated with the HIT change.
しかしながら、HIP意識しているNATsは故意にHIP意識しているシステムに透明です。 したがって、ホストは、ACLでHITを使用しているどんなNATにも通知するのが難しいのがわかるかもしれません。 ほとんどのシステムが彼らのネットワークでNATsを知るので、彼らがHITの変化についてこれらのNATsに通知できるプロセスがあるはずです。 これは応答者としてNATの後ろで機能するシステムに義務的です。 似たような仕方で、ホストが創始者のHITにおける変化について通知されるなら、それは変化のNATに通知するべきです。 この様に、HIT変化でNATsをアップデートするでしょう。
13.2. Non-security considerations
13.2. 非セキュリティ問題
The definition of the Host Identifier states that the HI need not be a public key. It implies that the HI could be any value; for example, an FQDN. This document does not describe how to support such a non-cryptographic HI. A non-cryptographic HI would still offer the services of the HIT or LSI for NAT traversal. It would be possible to carry HITs in HIP packets that had neither privacy nor authentication. Since such a mode would offer so little additional functionality for so much addition to the IP kernel, it has not been
Host Identifierの定義は、HIが公開鍵である必要はないと述べます。 それは、HIがどんな値であるかもしれないことも含意します。 例えば、FQDN。 このドキュメントはそのような非暗号のHIをサポートする方法を説明しません。 非暗号のHIはNAT縦断のためにまだHITかLSIのサービスを提供しているでしょう。 プライバシーも認証も持っていなかったHIPパケットでHITsを運ぶのは可能でしょう。 そのようなモードはとても多くの追加のためにとても少ない追加機能性をIPカーネルに提供するでしょう、したがって、それがなかったので
Moskowitz & Nikander Informational [Page 21] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[21ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
defined. Given how little public key cryptography HIP requires, HIP should only be implemented using public key Host Identities.
定義にされる。 HIPが必要とする公開鍵暗号、HIPがどのように少ししかそうするべきでないかを考えて、公開鍵Host Identitiesを使用することで単に実装されてください。
If it is desirable to use HIP in a low-security situation where public key computations are considered expensive, HIP can be used with very short Diffie-Hellman and Host Identity keys. Such use makes the participating hosts vulnerable to MitM and connection hijacking attacks. However, it does not cause flooding dangers, since the address check mechanism relies on the routing system and not on cryptographic strength.
低い治安状況における公開鍵計算が高価であると考えられるHIPを使用するのが望ましいなら、非常に背の低いディフィー-ヘルマンとHost Identityキーと共にHIPを使用できます。 そのような使用はMitMに被害を受け易い参加しているホストと接続ハイジャックを攻撃にします。 しかしながら、氾濫危険を引き起こしません、アドレス検査メカニズムがシステムとどんな暗号の強さでもルーティングを当てにしないので。
14. Acknowledgements
14. 承認
For the people historically involved in the early stages of HIP, see the Acknowledgements section in the Host Identity Protocol specification.
HIPの初期段階に歴史的にかかわる人々に関しては、Host Identityプロトコル仕様でAcknowledgements部を見てください。
During the later stages of this document, when the editing baton was transfered to Pekka Nikander, the comments from the early implementors and others, including Jari Arkko, Tom Henderson, Petri Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim Shepard, Jukka Ylitalo, and Jorma Wall, were invaluable. Finally, Lars Eggert, Spencer Dawkins, and Dave Crocker provided valuable input during the final stages of publication, most of which was incorporated but some of which the authors decided to ignore in order to get this document published in the first place.
このドキュメントの後期段階の間、ミカKomu、ミカ甲佐のヤリArkko、トム・ヘンダーソン、ペトリJokela、アンドリュー・マクレガー、ジャン・メレン、ティム・シェパード、ユッカYlitalo、およびヨルマWallを含む初期の作成者と他のものからのコメントは非常に貴重でした。(その時、編集警棒はペッカNikanderにtransferedされました)。 最終的に、ラース・エッゲルト、スペンサー・ダウキンズ、およびデーヴ・クロッカーは公表の最終段階の間、貴重な入力を提供しました。作者は、それの大部分は法人組織でしたが、第一にこのドキュメントを発表させるために無視するとそのいくつかを決めました。
15. Informative References
15. 有益な参照
[1] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
Vixie、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[1]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, March
2005.
[2]はArendsします、R.、Austein、R.、ラーソン、M.、マッシー、D.、S.ローズと、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005
Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月
[3] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[3]TsirtsisとG.とP.Srisuresh、「アドレス変換をネットワークでつないでください--翻訳(太平洋標準時のNAT)について議定書の中で述べてください」、RFC2766、2000年2月。
Moskowitz & Nikander Informational [Page 22] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[22ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
[4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001.
[4]SrisureshとP.とK.Egevang、「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」、RFC3022、2001年1月。
[5] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm
Specific IP: Framework", RFC 3102, October 2001.
[5]Borella、M.、最低気温、J.、Grabelsky、D.、およびG.モンテネグロ、「分野の特定のIP:」 「フレームワーク」、RFC3102、2001年10月。
[6] Richardson, M., "A Method for Storing IPsec Keying Material in
DNS", RFC 4025, March 2005.
[6] リチャードソン、M.、「DNSで材料を合わせるIPsecを保存するためのメソッド」、RFC4025、2005年3月。
[7] Lear, E. and R. Droms, "What's In A Name: Thoughts from the
NSRG", Work in Progress, September 2003.
[7] リア、E.、およびR.Droms、「名前には何がありますか?」 「NSRGからの考え」は進歩、2003年9月に働いています。
[8] Nikander, P., et al, "Mobile IP Version 6 Route Optimization
Security Design Background", RFC 4225, December 2005.
[8]Nikander、P.、他、「モバイルIPバージョン6経路最適化セキュリティデザインバックグラウンド」、RFC4225、2005年12月。
[9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[9] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[10] Chiappa, J., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture", URL
http://users.exis.net/~jnc/tech/endpoints.txt, 1999.
[10] Chiappa、J.、「終点と終点は以下を命名します」。 「インターネットアーキテクチャへの提案された増進」、URL http://users.exis.net/~jnc/tech/endpoints.txt 、1999。
[11] Nikander, P., "Denial-of-Service, Address Ownership, and Early
Authentication in the IPv6 World", in Security Protocols, 9th
International Workshop, Cambridge, UK, April 25-27 2001, LNCS
2467, pp. 12-26, Springer, 2002.
[11]Nikanderと、P.と、Securityプロトコル、国際Workshop、第9ケンブリッジイギリス、2001LNCS2467 4月25日〜27日、ページにおける「サービス妨害、アドレス所有権、およびIPv6世界での早めの認証」 12-26、追出石、2002。
[12] Bellovin, S., "EIDs, IPsec, and HostNAT", in Proceedings of the
41st IETF, Los Angeles, CA, March 1998.
第41IETF、ロサンゼルス(カリフォルニア)、1998年3月の議事における[12]Bellovinと、S.と、「EIDs、IPsec、およびHostNAT。」
Authors' Addresses
作者のアドレス
Robert Moskowitz ICSAlabs, a Division of Cybertrust Corporation 1000 Bent Creek Blvd, Suite 200 Mechanicsburg, PA USA
ロバートマスコウィッツICSAlabs、1000が曲げたCybertrust社の師団Blvd Suite200PAメカニクスバーグ(米国)クリーク
EMail: rgm@icsalabs.com
メール: rgm@icsalabs.com
Pekka Nikander Ericsson Research Nomadic Lab JORVAS FIN-02420 FINLAND
ペッカ・Nikanderのエリクソンの研究の遊牧民的な研究室JORVAS FIN-02420フィンランド
Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com
以下に電話をしてください。 +358 9 299 1 メール: pekka.nikander@nomadiclab.com
Moskowitz & Nikander Informational [Page 23] RFC 4423 Host Identity Protocol (HIP) Architecture May 2006
マスコウィッツとNikanderの情報[23ページ]のRFC4423ホストアイデンティティプロトコル(クールな)アーキテクチャ2006年5月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Moskowitz & Nikander Informational [Page 24]
マスコウィッツとNikander情報です。[24ページ]
一覧
スポンサーリンク
