RFC3971 日本語訳
3971 SEcure Neighbor Discovery (SEND). J. Arkko, Ed., J. Kempf, B.Zill, P. Nikander. March 2005. (Format: TXT=123372 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Arkko, Ed.
Request for Comments: 3971 Ericsson
Category: Standards Track J. Kempf
DoCoMo Communications Labs USA
B. Zill
Microsoft
P. Nikander
Ericsson
March 2005
ワーキンググループJ.Arkko、エドをネットワークでつないでください。コメントのために以下を要求してください。 3971年のエリクソンカテゴリ: 規格は2005年の米国のB.ZillマイクロソフトP.Nikanderエリクソンの行進のときにJ.ケンフDoCoMoコミュニケーション研究室を追跡します。
SEcure Neighbor Discovery (SEND)
安全な隣人発見(発信します)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec.
IPv6ノードは、リンクの上の他のノードを発見して、それらのリンクレイヤアドレスがルータを見つけて、経路の可到達性情報を活発な隣人に保守することを決定するのに、Neighborディスカバリープロトコル(NDP)を使用します。 機密保護されないなら、NDPは様々な攻撃に被害を受け易いです。 このドキュメントはNDPにセキュリティー対策を指定します。 当初のNDP仕様によるそれらと異なって、これらのメカニズムはIPsecを使用しません。
Arkko, et al. Standards Track [Page 1] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[1ページ]RFC3971
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Neighbor and Router Discovery Overview. . . . . . . . . . . . 6
4. Secure Neighbor Discovery Overview. . . . . . . . . . . . . . 8
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . . 9
5.1. CGA Option. . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Processing Rules for Senders. . . . . . . . . . 11
5.1.2. Processing Rules for Receivers. . . . . . . . . 12
5.1.3. Configuration . . . . . . . . . . . . . . . . . 13
5.2. RSA Signature Option. . . . . . . . . . . . . . . . . . 14
5.2.1. Processing Rules for Senders. . . . . . . . . . 16
5.2.2. Processing Rules for Receivers. . . . . . . . . 16
5.2.3. Configuration . . . . . . . . . . . . . . . . . 17
5.2.4. Performance Considerations. . . . . . . . . . . 18
5.3. Timestamp and Nonce Options . . . . . . . . . . . . . . 19
5.3.1. Timestamp Option. . . . . . . . . . . . . . . . 19
5.3.2. Nonce Option. . . . . . . . . . . . . . . . . . 20
5.3.3. Processing Rules for Senders. . . . . . . . . . 21
5.3.4. Processing Rules for Receivers. . . . . . . . . 21
6. Authorization Delegation Discovery. . . . . . . . . . . . . . 24
6.1. Authorization Model . . . . . . . . . . . . . . . . . . 24
6.2. Deployment Model. . . . . . . . . . . . . . . . . . . . 25
6.3. Certificate Format. . . . . . . . . . . . . . . . . . . 26
6.3.1. Router Authorization Certificate Profile. . . . 26
6.3.2. Suitability of Standard Identity Certificates . 29
6.4. Certificate Transport . . . . . . . . . . . . . . . . . 29
6.4.1. Certification Path Solicitation Message Format. 30
6.4.2. Certification Path Advertisement Message Format 32
6.4.3. Trust Anchor Option . . . . . . . . . . . . . . 34
6.4.4. Certificate Option. . . . . . . . . . . . . . . 36
6.4.5. Processing Rules for Routers. . . . . . . . . . 37
6.4.6. Processing Rules for Hosts. . . . . . . . . . . 38
6.5. Configuration . . . . . . . . . . . . . . . . . . . . . 39
7. Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. CGAs. . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2. Redirect Addresses. . . . . . . . . . . . . . . . . . . 40
7.3. Advertised Subnet Prefixes. . . . . . . . . . . . . . . 40
7.4. Limitations . . . . . . . . . . . . . . . . . . . . . . 41
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9.1. Threats to the Local Link Not Covered by SEND . . . . . 44
9.2. How SEND Counters Threats to NDP. . . . . . . . . . . . 45
9.2.1. Neighbor Solicitation/Advertisement Spoofing. . 45
9.2.2. Neighbor Unreachability Detection Failure . . . 46
9.2.3. Duplicate Address Detection DoS Attack. . . . . 46
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 要件. . . . . . . . . . . . . 4 2の仕様。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 隣人とルータ発見概要。 . . . . . . . . . . . 6 4. 隣人発見が概要であると機密保護してください。 . . . . . . . . . . . . . 8 5. 隣人ディスカバリーはオプション. . . . . . . . . . . . . 9 5.1について議定書の中で述べます。 CGAオプション。 . . . . . . . . . . . . . . . . . . . . . . 10 5.1.1. 処理はSendersのために統治されます。 . . . . . . . . . 11 5.1.2. 処理は受信機のために統治されます。 . . . . . . . . 12 5.1.3. 構成. . . . . . . . . . . . . . . . . 13 5.2。 RSA署名オプション。 . . . . . . . . . . . . . . . . . 14 5.2.1. 処理はSendersのために統治されます。 . . . . . . . . . 16 5.2.2. 処理は受信機のために統治されます。 . . . . . . . . 16 5.2.3. 構成. . . . . . . . . . . . . . . . . 17 5.2.4。 パフォーマンス問題。 . . . . . . . . . . 18 5.3. タイムスタンプと一回だけのオプション. . . . . . . . . . . . . . 19 5.3.1。 タイムスタンプオプション。 . . . . . . . . . . . . . . . 19 5.3.2. 一回だけのオプション。 . . . . . . . . . . . . . . . . . 20 5.3.3. 処理はSendersのために統治されます。 . . . . . . . . . 21 5.3.4. 処理は受信機のために統治されます。 . . . . . . . . 21 6. 承認委譲発見。 . . . . . . . . . . . . . 24 6.1. 承認モデル. . . . . . . . . . . . . . . . . . 24 6.2。 展開モデル。 . . . . . . . . . . . . . . . . . . . 25 6.3. 書式を証明してください。 . . . . . . . . . . . . . . . . . . 26 6.3.1. ルータ承認証明書プロフィール。 . . . 26 6.3.2. 標準のアイデンティティ証明書. 29 6.4の適合。 輸送. . . . . . . . . . . . . . . . . 29 6.4.1を証明してください。 証明経路懇願メッセージ・フォーマット。 30 6.4.2. 証明経路広告メッセージは6.4に.3に32をフォーマットします。 アンカーオプション. . . . . . . . . . . . . . 34 6.4.4を信じてください。 オプションを証明してください。 . . . . . . . . . . . . . . 36 6.4.5. 処理はルータのために統治されます。 . . . . . . . . . 37 6.4.6. 処理はホストのために統治されます。 . . . . . . . . . . 38 6.5. 構成. . . . . . . . . . . . . . . . . . . . . 39 7。 扱います。 . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.1. CGAs。 . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.2. アドレスを転送してください。 . . . . . . . . . . . . . . . . . . 40 7.3. サブネット接頭語の広告を出しました。 . . . . . . . . . . . . . . 40 7.4. 制限. . . . . . . . . . . . . . . . . . . . . . 41 8。 変遷は.429を発行します。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 44 9.1。 カバーされなかった地方のリンクへの脅威は.449.2を送ります。 どのようにがNDPへの脅威をカウンタに送るか。 . . . . . . . . . . . 45 9.2.1. 隣人懇願/広告スプーフィング。 . 45 9.2.2. 隣人Unreachability検出の故障. . . 46 9.2.3。 アドレス検出DoS攻撃をコピーしてください。 . . . . 46
Arkko, et al. Standards Track [Page 2] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[2ページ]RFC3971
9.2.4. Router Solicitation and Advertisement Attacks . 46
9.2.5. Replay Attacks. . . . . . . . . . . . . . . . . 47
9.2.6. Neighbor Discovery DoS Attack . . . . . . . . . 48
9.3. Attacks against SEND Itself . . . . . . . . . . . . . . 48
10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . . 49
10.1. Constants . . . . . . . . . . . . . . . . . . . . . . . 49
10.2. Variables . . . . . . . . . . . . . . . . . . . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 50
12.1. Normative References. . . . . . . . . . . . . . . . . . 50
12.2. Informative References. . . . . . . . . . . . . . . . . 51
Appendices. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A. Contributors and Acknowledgments. . . . . . . . . . . . 53
B. Cache Management. . . . . . . . . . . . . . . . . . . . 53
C. Message Size When Carrying Certificates . . . . . . . . 54
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statements . . . . . . . . . . . . . . . . . . . . 56
9.2.4. ルータ懇願と広告は.5に.469.2を攻撃します。 反射攻撃。 . . . . . . . . . . . . . . . . 47 9.2.6. 隣人発見DoSは.489.3を攻撃します。 攻撃は.48 10をそれ自体に送ります。 値. . . . . . . . . . . . . . . . . . . . . . . 49 10.1について議定書の中で述べてください。 定数. . . . . . . . . . . . . . . . . . . . . . . 49 10.2。 変数. . . . . . . . . . . . . . . . . . . . . . . 49 11。 IANA問題. . . . . . . . . . . . . . . . . . . . . 49 12。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 50 12.1. 引用規格。 . . . . . . . . . . . . . . . . . 50 12.2. 有益な参照。 . . . . . . . . . . . . . . . . 51個の付録。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 A.貢献者と承認。 . . . . . . . . . . . 53 B.キャッシュ管理。 . . . . . . . . . . . . . . . . . . . 携帯証明書. . . . . . . . 54作者のアドレスであることの53C.メッセージサイズ。 . . . . . . . . . . . . . . . . . . . . . . . 55 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . 56
1. Introduction
1. 序論
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [4] and 2462 [5]. Nodes on the same link use NDP to discover each other's presence and link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. NDP is used by both hosts and routers. Its functions include Neighbor Discovery (ND), Router Discovery (RD), Address Autoconfiguration, Address Resolution, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Redirection.
IPv6はRFCs2461[4]と2462[5]でNeighborディスカバリープロトコル(NDP)を定義します。 同じリンクの上のノードは、互いの存在とリンクレイヤアドレスを発見して、ルータを見つけて、経路の可到達性情報を活発な隣人に保守するのにNDPを使用します。 NDPはホストとルータの両方によって使用されます。 機能はNeighborディスカバリー(ノースダコタ)、Routerディスカバリー(RD)、Address Autoconfiguration、Address Resolution、Neighbor Unreachability Detection(NUD)、Duplicate Address Detection(DAD)、およびRedirectionを含んでいます。
The original NDP specifications called for the use of IPsec to protect NDP messages. However, the RFCs do not give detailed instructions for using IPsec to do this. In this particular application, IPsec can only be used with a manual configuration of security associations, due to bootstrapping problems in using IKE [19, 15]. Furthermore, the number of manually configured security associations needed for protecting NDP can be very large [20], making that approach impractical for most purposes.
当初のNDP仕様は、IPsecの使用がNDPメッセージを保護するように求めました。 しかしながら、RFCsはこれをするのにIPsecを使用するための細かい指示を与えません。 この特定用途では、セキュリティ協会の手動の構成と共にIPsecを使用できるだけです、IKE[19、15]を使用する際に問題を独力で進むため。 その上、NDPを保護するのに必要である手動で構成されたセキュリティ協会の数は非常に大きい[20]であることができます、そのアプローチをほとんどの目的のために非実用的にして。
The SEND protocol is designed to counter the threats to NDP. These threats are described in detail in [22]. SEND is applicable in environments where physical security on the link is not assured (such as over wireless) and attacks on NDP are a concern.
SENDプロトコルは、NDPへの脅威に対抗するように設計されています。 これらの脅威は[22]で詳細に説明されます。 SENDはリンクの上の物理的なセキュリティが保証されない環境(ワイヤレスなどの)で適切です、そして、NDPに対する攻撃は関心です。
This document is organized as follows. Sections 2 and 3 define some terminology and present a brief review of NDP, respectively. Section 4 describes the overall approach to securing NDP. This approach involves the use of new NDP options to carry public key - based signatures. A zero-configuration mechanism is used for showing
このドキュメントは以下の通りまとめられます。 セクション2と3 それぞれ何らかの用語を定義してください、そして、NDPの寸評を提示してください。 セクション4は総合的なアプローチをNDPを機密保護するのに説明します。 このアプローチは公開鍵を運ぶために新しいNDPオプションの使用にかかわります--署名を基礎づけます。 無構成メカニズムは表示に使用されます。
Arkko, et al. Standards Track [Page 3] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[3ページ]RFC3971
address ownership on individual nodes; routers are certified by a trust anchor [7]. The formats, procedures, and cryptographic mechanisms for the zero-configuration mechanism are described in a related specification [11].
個々のノードの上で所有権を扱ってください。 ルータは信頼アンカー[7]によって公認されます。 無構成メカニズムのための形式、手順、および暗号のメカニズムは関連する仕様[11]で説明されます。
The required new NDP options are discussed in Section 5. Section 6 describes the mechanism for distributing certification paths to establish an authorization delegation chain to a trust anchor.
セクション5で必要な新しいNDPオプションについて議論します。 セクション6は、承認委譲チェーンを信頼アンカーに証明するために証明経路を分配するためにメカニズムについて説明します。
Finally, Section 8 discusses the co-existence of secured and unsecured NDP on the same link, and Section 9 discusses security considerations for SEcure Neighbor Discovery (SEND).
最終的に、セクション8は同じリンクの上に機密保護していて非機密保護しているNDPの共存について議論します、そして、セクション9はSEcure Neighborディスカバリー(SEND)のためにセキュリティ問題について議論します。
The use of identity certificates provisioned on end hosts for authorizing address use is out of the scope for this document, as is the security of NDP when the entity defending an address is not the same as the entity claiming that address (also known as "proxy ND"). These are extensions of SEND that may be treated in separate documents, should the need arise.
このドキュメントのための範囲の外にアドレス使用を認可するために終わりのホストの上で食糧を供給されたアイデンティティ証明書の使用があって、アドレスを防御する実体であるときに、そのままで、NDPのセキュリティはそのアドレス(また、「プロキシノースダコタ」として、知られている)を要求する実体と同じではありません。 これらは必要性が起こるなら別々のドキュメントで扱われるかもしれないSENDの拡大です。
1.1. Specification of Requirements
1.1. 要件の仕様
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" are to be interpreted as described in [2].
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。 キーワード“MUST"、「必須NOT」“SHOULD"、「」、「推薦された」、および「5月」は[2]で説明されるように解釈されることになっているべきです。
2. Terms
2. 用語
Authorization Delegation Discovery (ADD)
承認委譲発見(加えます)
A process through which SEND nodes can acquire a certification
path from a peer node to a trust anchor.
プロセスはどのSENDノードを通して同輩ノードから信頼アンカーまで証明経路を取得できるか。
Certificate Revocation List (CRL)
証明書失効リスト(CRL)
In one method of certificate revocation, an authority periodically
issues a signed data structure called the Certificate Revocation
List. This is a time-stamped list identifying revoked
certificates, signed by the issuer, and made freely available in a
public repository.
証明書取消しの1つのメソッドで、権威はCertificate Revocation Listと呼ばれる署名しているデータ構造を定期的に発行します。 これは公共の倉庫で取り消された証明書を特定して、発行人によって署名されて、自由に利用可能にされた時間で押し込まれたリストです。
Certification Path Advertisement (CPA)
証明経路広告(CPA)
The advertisement message used in the ADD process.
ADDプロセスで使用される広告メッセージ。
Arkko, et al. Standards Track [Page 4] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[4ページ]RFC3971
Certification Path Solicitation (CPS)
証明経路懇願(CPS)
The solicitation message used in the ADD process.
ADDプロセスで使用される懇願メッセージ。
Cryptographically Generated Address (CGA)
アドレスであると暗号で生成されます。(CGA)
A technique [11] whereby an IPv6 address of a node is
cryptographically generated by using a one-way hash function from
the node's public key and some other parameters.
ノードのIPv6アドレスがノードの公開鍵とある他のパラメタから一方向ハッシュ関数を使用することによって暗号で作られるテクニック[11]。
Distinguished Encoding Rules (DER)
規則をコード化しながら、区別されます。(DER)
An encoding scheme for data values, defined in [12].
[12]で定義されたデータ値のコード化体系。
Duplicate Address Detection (DAD)
アドレス検出をコピーしてください。(おとうさん)
A mechanism assuring that two IPv6 nodes on the same link are not
using the same address.
同じリンクの上の2つのIPv6ノードが同じアドレスを使用していないことを保証するメカニズム。
Fully Qualified Domain Name (FQDN)
完全修飾ドメイン名(FQDN)
A fully qualified domain name consists of a host and domain name,
including the top-level domain.
完全修飾ドメイン名は最上位のドメインを含むホストとドメイン名から成ります。
Internationalized Domain Name (IDN)
国際化ドメイン名(IDN)
Internationalized Domain Names can be used to represent domain
names that contain characters outside the ASCII set. See RFC 3490
[9].
ASCIIセットの外にキャラクタを含むドメイン名を表すのに国際化しているDomain Namesを使用できます。 RFC3490[9]を見てください。
Neighbor Discovery (ND)
隣人発見(ノースダコタ)
The Neighbor Discovery function of the Neighbor Discovery Protocol
(NDP). NDP contains functions besides ND.
Neighborディスカバリープロトコル(NDP)のNeighborディスカバリー機能。 NDPはノースダコタ以外に機能を含みます。
Neighbor Discovery Protocol (NDP)
隣人発見プロトコル(NDP)
The IPv6 Neighbor Discovery Protocol [7, 8].
IPv6隣人発見プロトコル[7、8]。
The Neighbor Discovery Protocol is a part of ICMPv6 [6].
NeighborディスカバリープロトコルはICMPv6[6]の一部です。
Neighbor Unreachability Detection (NUD)
隣人Unreachability検出(NUD)
A mechanism used for tracking the reachability of neighbors.
隣人の可到達性を追跡するのに使用されるメカニズム。
Arkko, et al. Standards Track [Page 5] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[5ページ]RFC3971
Non-SEND node
非SENDノード
An IPv6 node that does not implement this specification but uses
only the Neighbor Discovery protocol defined in RFCs 2461 and
2462, as updated, without security.
この仕様を履行しませんが、RFCs2461と2462年にセキュリティなしでアップデートするように定義されたNeighborディスカバリープロトコルだけを使用するIPv6ノード。
Nonce
一回だけ
An unpredictable random or pseudo-random number generated by a
node and used exactly once. In SEND, nonces are used to assure
that a particular advertisement is linked to the solicitation that
triggered it.
予測できない、無作為である、または、ノードによって生成されて、まさに一度使用された擬似乱数。 SENDでは、一回だけは、特定の広告がそれの引き金となった懇願にリンクされることを保証するのに使用されます。
Router Authorization Certificate
ルータ承認証明書
An X.509v3 [7] public key certificate using the profile specified
in Section 6.3.1.
プロフィールを使用するX.509v3[7]公開鍵証明書はセクション6.3.1で指定しました。
SEND node
SENDノード
An IPv6 node that implements this specification.
この仕様を履行するIPv6ノード。
Router Discovery (RD)
ルータ発見(RD)
Router Discovery allows the hosts to discover what routers exist
on the link, and what subnet prefixes are available. Router
Discovery is a part of the Neighbor Discovery Protocol.
ルータディスカバリーで、ホストはどんなルータがリンクの上に存在しているか、そして、どんなサブネット接頭語が利用可能であるかを発見できます。 ルータディスカバリーはNeighborディスカバリープロトコルの一部です。
Trust Anchor
信頼アンカー
Hosts are configured with a set of trust anchors to protect Router
Discovery. A trust anchor is an entity that the host trusts to
authorize routers to act as routers. A trust anchor configuration
consists of a public key and some associated parameters (see
Section 6.5 for a detailed explanation of these parameters).
ホストは1セットの信頼アンカーに構成されて、Routerディスカバリーを保護します。 信頼アンカーはホストがルータがルータとして機能するのを認可すると信じる実体です。 信頼アンカー構成は公開鍵といくつかの関連パラメタから成ります(これらのパラメタの詳説に関してセクション6.5を見てください)。
3. Neighbor and Router Discovery Overview
3. 隣人とルータ発見概要
The Neighbor Discovery Protocol has several functions. Many of these are overloaded on a few central message types, such as the ICMPv6 Neighbor Advertisement message. In this section, we review some of these tasks and their effects in order to better understand how the messages should be treated. This section is not normative, and if this section and the original Neighbor Discovery RFCs are in conflict, the original RFCs, as updated, take precedence.
Neighborディスカバリープロトコルには、いくつかの機能があります。 これらの多くがICMPv6 Neighbor Advertisementメッセージなどのいくつかの主要なメッセージタイプで積みすぎられます。 このセクションで、私たちは、メッセージがどのように扱われるべきであるかを理解するほうがよいためにこれらのタスクとそれらの効果のいくつかを見直します。 このセクションは規範的ではありません、そして、このセクションとオリジナルのNeighborディスカバリーRFCsが闘争中であるなら、アップデートするオリジナルのRFCsは優先します。
Arkko, et al. Standards Track [Page 6] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[6ページ]RFC3971
The main functions of NDP are as follows:
NDPの主な機能は以下の通りです:
o The Router Discovery function allows IPv6 hosts to discover the
local routers on an attached link. Router Discovery is described
in Section 6 of RFC 2461 [4]. The main purpose of Router
Discovery is to find neighboring routers willing to forward
packets on behalf of hosts. Subnet prefix discovery involves
determining which destinations are directly on a link; this
information is necessary in order to know whether a packet should
be sent to a router or directly to the destination node.
o Routerディスカバリー機能で、IPv6ホストは付属リンクの上のローカルルータを発見できます。 ルータディスカバリーはRFC2461[4]のセクション6で説明されます。 Routerディスカバリーの主な目的は隣接しているルータが、ホストを代表してパケットを進めても構わないと思っているのがわかることです。 サブネット接頭語発見は、リンクの直接上にどの目的地があるかを決定することを伴います。 この情報が、パケットがルータ、または、直接目的地ノードに送られるべきであるかどうかを知るのに必要です。
o The Redirect function is used for automatically redirecting a host
to a better first-hop router, or to inform hosts that a
destination is in fact a neighbor (i.e., on-link). Redirect is
specified in Section 8 of RFC 2461 [4].
o Redirect機能は、自動的により良い最初に、ホップルータにホストを向け直すか、または事実上、目的地が隣人であることをホストに知らせるのに使用されます(すなわち、リンクの上に)。 再直接は、指定されたコネです。RFC2461[4]のセクション8。
o Address Autoconfiguration is used for automatically assigning
addresses to a host [5]. This allows hosts to operate without
explicit configuration related to IP connectivity. The default
autoconfiguration mechanism is stateless. To create IP addresses,
hosts use any prefix information delivered to them during Router
Discovery and then test the newly formed addresses for uniqueness.
A stateful mechanism, DHCPv6 [18], provides additional
autoconfiguration features.
o アドレスAutoconfigurationは、自動的にホスト[5]にアドレスを割り当てるのに使用されます。 これで、ホストはIPの接続性に関連する明白な構成なしで働くことができます。 デフォルト自動構成メカニズムは状態がないです。 ホストは、IPアドレスを作成するために、Routerディスカバリーの間、彼らに提供されたどんな接頭語情報も使用して、次に、ユニークさがないかどうか新たに形成されたアドレスをテストします。 statefulメカニズム(DHCPv6[18])は追加自動構成機能を提供します。
o Duplicate Address Detection (DAD) is used for preventing address
collisions [5]: for instance, during Address Autoconfiguration. A
node that intends to assign a new address to one of its interfaces
first runs the DAD procedure to verify that no other node is using
the same address. As the rules forbid the use of an address until
it has been found unique, no higher layer traffic is possible
until this procedure has been completed. Thus, preventing attacks
against DAD can help ensure the availability of communications for
the node in question.
o 写しAddress Detection(DAD)はアドレス衝突[5]を防ぐのに使用されます: 例えば、Address Autoconfigurationの間。 新しいアドレスをインタフェースの1つに割り当てるつもりであるノードは、最初に、他のどんなノードも同じアドレスを使用していないことを確かめるためにDAD手順を実行します。 それがユニークであることがわかるまで規則がアドレスの使用を禁じるとき、この手順が完了するまで、どんなより高い層のトラフィックも可能ではありません。 したがって、DADに対して攻撃を防ぐのは、問題のノードのためのコミュニケーションの有用性を確実にするのを助けることができます。
o The Address Resolution function allows a node on the link to
resolve another node's IPv6 address to the corresponding link-
layer address. Address Resolution is defined in Section 7.2 of
RFC 2461 [4], and it is used for hosts and routers alike. Again,
no higher level traffic can proceed until the sender knows the
link layer address of the destination node or the next hop router.
Note that the source link layer address on link layer frames is
not checked against the information learned through Address
Resolution. This allows for an easier addition of network
elements such as bridges and proxies and eases the stack
implementation requirements, as less information has to be passed
from layer to layer.
o Address Resolution機能で、リンクの上のノードは対応するリンク層のアドレスに別のノードのIPv6アドレスを決議できます。 アドレスResolutionはRFC2461[4]のセクション7.2で定義されます、そして、それはホストとルータに同じく使用されます。 一方、送付者が目的地ノードか次のホップルータのリンクレイヤアドレスを知るまで、どんなより高い平らなトラフィックも続くことができません。 リンクレイヤフレームに関するソースリンクレイヤアドレスがAddress Resolutionを通して学習された情報に対してチェックされないことに注意してください。 これは、ブリッジやプロキシなどのネットワーク要素の、より簡単な追加を考慮して、スタック実装要件を緩和します、より少ない情報が層から層まで通過されなければならないとき。
Arkko, et al. Standards Track [Page 7] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[7ページ]RFC3971
o Neighbor Unreachability Detection (NUD) is used for tracking the
reachability of neighboring nodes, both hosts and routers. NUD is
defined in Section 7.3 of RFC 2461 [4]. NUD is security
sensitive, because an attacker could claim that reachability
exists when in fact it does not.
o 隣人Unreachability Detection(NUD)は、隣接しているノードの可到達性、ホストとルータの両方を追跡するのに使用されます。 NUDはRFC2461[4]のセクション7.3で定義されます。 敏感でないときに、攻撃者が、可到達性が存在すると主張できたので、NUDはセキュリティ敏感です。
The NDP messages follow the ICMPv6 message format. All NDP functions are realized by using the Router Solicitation (RS), Router Advertisement (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and Redirect messages. An actual NDP message includes an NDP message header, consisting of an ICMPv6 header and ND message-specific data, and zero or more NDP options. The NDP message options are formatted in the Type-Length-Value format.
NDPメッセージはICMPv6メッセージ・フォーマットに続きます。 すべてのNDP機能が、Router Solicitation(RS)、Router Advertisement(RA)、Neighbor Solicitation(NS)、Neighbor Advertisement(NA)、およびRedirectメッセージを使用することによって、実現されます。 実際のNDPメッセージはNDPメッセージヘッダーを含んでいます、ICMPv6ヘッダーとノースダコタのメッセージ特有のデータと、ゼロか、より多くのNDPオプションから成って。 NDPメッセージオプションはType長さの価値の形式でフォーマットされます。
<------------NDP Message---------------->
*-------------------------------------------------------------*
| IPv6 Header | ICMPv6 | ND Message- | ND Message |
| Next Header = 58 | Header | specific | Options |
| (ICMPv6) | | data | |
*-------------------------------------------------------------*
<--NDP Message header-->
<。------------NDPメッセージ---------------->*-------------------------------------------------------------* | IPv6ヘッダー| ICMPv6| ノースダコタメッセージ| ノースダコタメッセージ| | 次のヘッダー=58| ヘッダー| 特定| オプション| | (ICMPv6) | | データ| | *-------------------------------------------------------------* <--NDP Messageヘッダー-->。
4. Secure Neighbor Discovery Overview
4. 安全な隣人発見概要
To secure the various functions in NDP, a set of new Neighbor Discovery options is introduced. They are used to protect NDP messages. This specification introduces these options, an authorization delegation discovery process, an address ownership proof mechanism, and requirements for the use of these components in NDP.
NDPで様々な機能を保証するために、1セットの新しいNeighborディスカバリーオプションは紹介されます。 それらは、NDPメッセージを保護するのに使用されます。 この仕様はこれらのオプション、承認委譲発見プロセス、アドレス所有権証拠メカニズム、およびNDPにおけるこれらのコンポーネントの使用のための要件を紹介します。
The components of the solution specified in this document are as follows:
本書では指定されたソリューションのコンポーネントは以下の通りです:
o Certification paths, anchored on trusted parties, are expected to
certify the authority of routers. A host must be configured with
a trust anchor to which the router has a certification path before
the host can adopt the router as its default router.
Certification Path Solicitation and Advertisement messages are
used to discover a certification path to the trust anchor without
requiring the actual Router Discovery messages to carry lengthy
certification paths. The receipt of a protected Router
Advertisement message for which no certification path is available
triggers the authorization delegation discovery process.
o 信じられたパーティーに据えつけられた証明経路がルータの権威を公認すると予想されます。 ホストがデフォルトルータとしてルータを採用できる前にルータが証明経路を持っている信頼アンカーでホストを構成しなければなりません。 証明Path SolicitationとAdvertisementメッセージは、長い証明経路を運ぶ実際のRouterディスカバリーメッセージを必要としないで信頼アンカーにとって証明経路を発見するのに使用されます。 証明経路がないのが利用可能である保護されたRouter Advertisementメッセージの領収書は承認委譲発見プロセスの引き金となります。
Arkko, et al. Standards Track [Page 8] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[8ページ]RFC3971
o Cryptographically Generated Addresses are used to make sure that
the sender of a Neighbor Discovery message is the "owner" of the
claimed address. A public-private key pair is generated by all
nodes before they can claim an address. A new NDP option, the CGA
option, is used to carry the public key and associated parameters.
o 暗号で、Generated Addressesは、Neighborディスカバリーメッセージの送付者が要求されたアドレスの「所有者」であると確実にするのに使用されます。 彼らがアドレスを要求できる前に公共の秘密鍵組はすべてのノードによって生成されます。 新しいNDPオプション(CGAオプション)は、公開鍵と関連パラメタを運ぶのに使用されます。
This specification also allows a node to use non-CGAs with
certificates that authorize their use. However, the details of
such use are beyond the scope of this specification and are left
for future work.
また、この仕様で、ノードは彼らの使用を認可する証明書がある非CGAsを使用できます。 しかしながら、そのような使用の詳細は、この仕様の範囲を超えていて、今後の活動に残されます。
o A new NDP option, the RSA Signature option, is used to protect all
messages relating to Neighbor and Router discovery.
o 新しいNDPオプション(RSA Signatureオプション)は、Neighborに関連するすべてのメッセージとRouter発見を保護するのに使用されます。
Public key signatures protect the integrity of the messages and
authenticate the identity of their sender. The authority of a
public key is established either with the authorization delegation
process, by using certificates, or through the address ownership
proof mechanism, by using CGAs, or with both, depending on
configuration and the type of the message protected.
公開鍵署名は、メッセージの保全を保護して、彼らの送付者のアイデンティティを認証します。 公開鍵の権威は、証明書を使用する近く、または、承認委譲プロセスか、CGAsを使用するのによるアドレス所有権証拠メカニズムを通して確立されるか、または両方、構成に依存して、およびメッセージのタイプで保護されます。
Note: RSA is mandated because having multiple signature algorithms
would break compatibility between implementations or increase
implementation complexity by forcing the implementation of
multiple algorithms and the mechanism to select among them. A
second signature algorithm is only necessary as a recovery
mechanism, in case a flaw is found in RSA. If this happens, a
stronger signature algorithm can be selected, and SEND can be
revised. The relationship between the new algorithm and the RSA-
based SEND described in this document would be similar to that
between the RSA-based SEND and Neighbor Discovery without SEND.
Information signed with the stronger algorithm has precedence over
that signed with RSA, in the same way that RSA-signed information
now takes precedence over unsigned information. Implementations
of the current and revised specs would still be compatible.
以下に注意してください。 複数の署名アルゴリズムを持っていると、それらの中で選択する複数のアルゴリズムとメカニズムの実装を強制することによって、実装の間の互換性が壊されるか、または実装の複雑さは増強されるでしょう、したがって、RSAが強制されます。 欠点がRSAで見つけられるといけないので、2番目の署名アルゴリズムが単に回収機構として必要です。 これが起こるなら、より強い署名アルゴリズムを選択できます、そして、SENDを改訂できます。 新しいアルゴリズムと本書では説明されたRSAのベースのSENDとの関係はRSAベースのSENDとNeighborディスカバリーの間でSENDなしでそれと同様でしょう。 より強いアルゴリズムを契約された情報はRSAを契約されたそれの上の先行を持っています、RSAによって署名された情報が現在未署名の情報に優先するのと同じように。 現在の、そして、改訂された仕様の実装はまだ互換性があるでしょう。
o In order to prevent replay attacks, two new Neighbor Discovery
options, Timestamp and Nonce, are introduced. Given that Neighbor
and Router Discovery messages are in some cases sent to multicast
addresses, the Timestamp option offers replay protection without
any previously established state or sequence numbers. When the
messages are used in solicitation-advertisement pairs, they are
protected with the Nonce option.
o 反射攻撃を防ぐために、2つの新しいNeighborディスカバリーオプション(TimestampとNonce)が、紹介されます。 いくつかの場合NeighborとRouterディスカバリーメッセージをマルチキャストアドレスに送るなら、Timestampオプション申し出は少しも以前に設立された状態や一連番号なしで保護を再演します。 メッセージが懇願広告組で使用されるとき、彼らはNonceオプションで保護されます。
5. Neighbor Discovery Protocol Options
5. 隣人発見プロトコルオプション
The options described in this section MUST be supported.
このセクションで説明されたオプションをサポートしなければなりません。
Arkko, et al. Standards Track [Page 9] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[9ページ]RFC3971
5.1. CGA Option
5.1. CGAオプション
The CGA option allows the verification of the sender's CGA. The format of the CGA option is described as follows:
CGAオプションは送付者のCGAの検証を許します。 CGAオプションの形式は以下の通り説明されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. CGA Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| パッドの長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . CGAパラメタ…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . そっと歩きます…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
11
11
Length
長さ
The length of the option (including the Type, Length, Pad Length,
Reserved, CGA Parameters, and Padding fields) in units of 8
octets.
8つの八重奏のユニットのオプション(Type、Length、Pad Length、Reserved、CGA Parameters、およびPadding分野を含んでいる)の長さ。
Pad Length
パッドの長さ
The number of padding octets beyond the end of the CGA Parameters
field but within the length specified by the Length field.
Padding octets MUST be set to zero by senders and ignored by
receivers.
しかしCGA Parametersの端の八重奏が長さの中でさばく詰め物の数はLength分野のそばで指定しました。 八重奏を水増しするのを送付者によってゼロに設定されて、受信機で無視しなければなりません。
Reserved
予約されます。
An 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.
今後の使用のために予約された8ビットの分野。 値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Arkko, et al. Standards Track [Page 10] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[10ページ]RFC3971
CGA Parameters
CGAパラメタ
A variable-length field containing the CGA Parameters data
structure described in Section 4 of [11].
[11]のセクション4で説明されたCGA Parametersデータ構造を含む可変長の分野。
This specification requires that if both the CGA option and the
RSA Signature option are present, then the public key found from
the CGA Parameters field in the CGA option MUST be that referred
by the Key Hash field in the RSA Signature option. Packets
received with two different keys MUST be silently discarded. Note
that a future extension may provide a mechanism allowing the owner
of an address and the signer to be different parties.
この仕様は、CGAオプションとRSA Signatureオプションの両方が存在しているならCGAオプションにおけるCGA Parameters分野から見つけられた公開鍵がRSA SignatureオプションにおけるKey Hash分野でそんなに参照していなければならないのを必要とします。 静かに2個の異なったキーで受け取られたパケットを捨てなければなりません。 今後の拡大がアドレスと署名者の所有者が異なったパーティーであることを許容するメカニズムを提供するかもしれないことに注意してください。
Padding
詰め物
A variable-length field making the option length a multiple of 8,
containing as many octets as specified in the Pad Length field.
Pad Length分野で指定されるのと同じくらい多くの八重奏を含んでいて、オプションの長さを8の倍数にする可変長の分野。
5.1.1. Processing Rules for Senders
5.1.1. Sendersのための処理規則
If the node has been configured to use SEND, the CGA option MUST be present in all Neighbor Solicitation and Advertisement messages and MUST be present in Router Solicitation messages unless they are sent with the unspecified source address. The CGA option MAY be present in other messages.
CGAオプションは、すべてのNeighbor SolicitationとAdvertisementメッセージに存在していなければならなくて、ノードがSENDを使用するために構成されて、それらが不特定のソースアドレスと共に送られない場合、Router Solicitationメッセージに存在していなければなりません。 CGAオプションは他のメッセージに存在しているかもしれません。
A node sending a message using the CGA option MUST construct the message as follows:
CGAオプションを使用することでメッセージを送るノードは以下のメッセージを構成しなければなりません:
The CGA Parameter field in the CGA option is filled according to
the rules presented above and in [11]. The public key in the
field is taken from the configuration used to generate the CGA,
typically from a data structure associated with the source
address. The address MUST be constructed as specified in Section
4 of [11]. Depending on the type of the message, this address
appears in different places, as follows:
[11]の上と、そして、[11]に提示された規則に従って、CGAオプションにおけるCGA Parameter分野はいっぱいにされます。 CGAを発生させるのに使用される構成からその分野の公開鍵を取ります、通常ソースアドレスに関連しているデータ構造から。 指定されるとして[11]のセクション4でアドレスを構成しなければなりません。 メッセージのタイプに頼っていて、このアドレスは以下の通り異なった場所に現れます:
Redirect
再直接
The address MUST be the source address of the message.
アドレスはメッセージのソースアドレスであるに違いありません。
Neighbor Solicitation
隣人懇願
The address MUST be the Target Address for solicitations sent for
Duplicate Address Detection; otherwise it MUST be the source
address of the message.
アドレスはDuplicate Address Detectionのために送られた懇願のためのTarget Addressでなければなりません。 さもなければ、それはメッセージのソースアドレスであるに違いありません。
Arkko, et al. Standards Track [Page 11] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[11ページ]RFC3971
Neighbor Advertisement
隣人広告
The address MUST be the source address of the message.
アドレスはメッセージのソースアドレスであるに違いありません。
Router Solicitation
ルータ懇願
The address MUST be the source address of the message. Note that
the CGA option is not used when the source address is the
unspecified address.
アドレスはメッセージのソースアドレスであるに違いありません。 ソースアドレスが不特定のアドレスであるときに、CGAオプションが使用されていないことに注意してください。
Router Advertisement
ルータ通知
The address MUST be the source address of the message.
アドレスはメッセージのソースアドレスであるに違いありません。
5.1.2. Processing Rules for Receivers
5.1.2. 受信機のための処理規則
Neighbor Solicitation and Advertisement messages without the CGA option MUST be treated as unsecured (i.e., processed in the same way as NDP messages sent by a non-SEND node). The processing of unsecured messages is specified in Section 8. Note that SEND nodes that do not attempt to interoperate with non-SEND nodes MAY simply discard the unsecured messages.
CGAオプションのないメッセージを扱わなければならない隣人SolicitationとAdvertisementは非安全にしました(すなわち、NDPメッセージが発信したのと同様に、非SENDノードで処理されます)。 非安全にされたメッセージの処理はセクション8で指定されます。 非SENDノードで共同利用するのを試みないSENDノードが単に非安全にされたメッセージを捨てるかもしれないことに注意してください。
Router Solicitation messages without the CGA option MUST also be treated as unsecured, unless the source address of the message is the unspecified address.
またオプションを扱わなければならないCGAのないルータSolicitationメッセージは非安全にされました、メッセージのソースアドレスが不特定のアドレスでないなら。
Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages containing a CGA option MUST be checked as follows:
再直接であり、以下の通りCGAオプションを含むNeighbor Solicitation、Neighbor Advertisement、Router Solicitation、およびRouter Advertisementメッセージをチェックしなければなりません:
If the interface has been configured to use CGA, the receiving
node MUST verify the source address of the packet by using the
algorithm described in Section 5 of [11]. The inputs to the
algorithm are the claimed address, as defined in the previous
section, and the CGA Parameters field.
インタフェースがCGAを使用するために構成されたなら、受信ノードは、[11]のセクション5で説明されたアルゴリズムを使用することによって、パケットのソースアドレスについて確かめなければなりません。 アルゴリズムへの入力は前項、およびCGA Parameters分野で定義されるように要求されたアドレスです。
If the CGA verification is successful, the recipient proceeds with
a more time-consuming cryptographic check of the signature. Note
that even if the CGA verification succeeds, no claims about the
validity of the use can be made until the signature has been
checked.
CGA検証がうまくいくなら、受取人は署名の、より手間がかかった暗号のチェックを続けます。 CGA検証が成功しても、署名がチェックされるまで使用の正当性に関するノークレームをすることができることに注意してください。
A receiver that does not support CGA or has not specified its use for a given interface can still verify packets by using trust anchors, even if a CGA is used on a packet. In such a case, the CGA property of the address is simply left unverified.
CGAを支持しないか、または与えられたインタフェースの使用を指定していない受信機は信用アンカーを使用することによって、まだパケットについて確かめることができます、CGAがパケットの上で使用されても。 このような場合には、アドレスのCGAの特性は非検証されるように単に残されます。
Arkko, et al. Standards Track [Page 12] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[12ページ]RFC3971
5.1.3. Configuration
5.1.3. 構成
All nodes that support the verification of the CGA option MUST record the following configuration information:
CGAオプションの検証を支えるすべてのノードが以下の設定情報を記録しなければなりません:
minbits
minbits
The minimum acceptable key length for public keys used in the
generation of CGAs. The default SHOULD be 1024 bits.
Implementations MAY also set an upper limit for the amount of
computation needed when verifying packets that use these security
associations. The upper limit SHOULD be at least 2048 bits. Any
implementation should follow prudent cryptographic practice in
determining the appropriate key lengths.
CGAsの世代に使用される公開鍵のための最小の許容できるキー長。 デフォルトSHOULD、1024ビットになってください。 また、実現はこれらのセキュリティ協会を使用するパケットについて確かめるとき必要である計算の量に上限を設定するかもしれません。 上限SHOULDは少なくともそうです。2048ビット。 どんな実現も適切なキー長を測定する際に慎重な暗号の習慣に続くべきです。
All nodes that support the sending of the CGA option MUST record the following configuration information:
CGAオプションの発信を支えるすべてのノードが以下の設定情報を記録しなければなりません:
CGA parameters
CGAパラメタ
Any information required to construct CGAs, as described in [11].
どんな情報も[11]で説明されるようにCGAsを組み立てるのが必要です。
Arkko, et al. Standards Track [Page 13] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[13ページ]RFC3971
5.2. RSA Signature Option
5.2. RSA署名オプション
The RSA Signature option allows public key-based signatures to be attached to NDP messages. The format of the RSA Signature option is described in the following diagram:
RSA Signatureオプションは、公開鍵ベースの署名がNDPメッセージに付けられているのを許容します。 RSA Signatureオプションの形式は以下のダイヤグラムで説明されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Hash |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Digital Signature .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 主要な細切れ肉料理| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Digital署名…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . そっと歩きます…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
12
12
Length
長さ
The length of the option (including the Type, Length, Reserved,
Key Hash, Digital Signature, and Padding fields) in units of 8
octets.
8つの八重奏のユニットのオプション(Type、Length、Reserved、Key Hash、Digital Signature、およびPadding分野を含んでいる)の長さ。
Reserved
予約されます。
A 16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
今後の使用のために予約された16ビットの分野。 値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Arkko, et al. Standards Track [Page 14] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[14ページ]RFC3971
Key Hash
主要な細切れ肉料理
A 128-bit field containing the most significant (leftmost) 128
bits of a SHA-1 [14] hash of the public key used for constructing
the signature. The SHA-1 hash is taken over the presentation used
in the Public Key field of the CGA Parameters data structure
carried in the CGA option. Its purpose is to associate the
signature to a particular key known by the receiver. Such a key
can either be stored in the certificate cache of the receiver or
be received in the CGA option in the same message.
含む中で署名を構成するのに使用される公開鍵のSHA-1[14]細切れ肉料理の128ビット最も重要である(一番左)128ビットの分野。 CGAオプションで運ばれたCGA Parametersデータ構造のPublic Key分野で使用されるプレゼンテーションの上にSHA-1細切れ肉料理を取ります。 目的は受信機によって知られていた特定のキーに署名を関連づけることです。そのようなキーを受信機の証明書キャッシュに収納するか、または同じメッセージにCGAオプションで受け取ることができます。
Digital Signature
デジタル署名
A variable-length field containing a PKCS#1 v1.5 signature,
constructed by using the sender's private key over the following
sequence of octets:
八重奏の以下の系列の上で送付者の秘密鍵を使用することによって構成されたPKCS#1v1.5署名を含む可変長の分野:
1. The 128-bit CGA Message Type tag [11] value for SEND, 0x086F
CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been
generated randomly by the editor of this specification.).
1. SEND、0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08のための128ビットのCGA Message Typeタグ[11]値。 (タグ値はこの仕様のエディタによって手当たりしだいに発生しました。)
2. The 128-bit Source Address field from the IP header.
2. IPヘッダーからの128ビットのSource Address分野。
3. The 128-bit Destination Address field from the IP header.
3. IPヘッダーからの128ビットのDestination Address分野。
4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the
ICMP header.
4. ICMPヘッダーからの8ビットのType、8ビットのCode、および16ビットのChecksum分野。
5. The NDP message header, starting from the octet after the ICMP
Checksum field and continuing up to but not including NDP
options.
5. NDPメッセージヘッダー、ICMP Checksumの後に八重奏から始めるのは、NDPオプションを含んでいるだけではないまでさばいて、続きます。
6. All NDP options preceding the RSA Signature option.
6. RSA Signatureオプションに先行するすべてのNDPオプション。
The signature value is computed with the RSASSA-PKCS1-v1_5
algorithm and SHA-1 hash, as defined in [13].
署名値は[13]で定義されるようにRSASSA-PKCS1-v1_5アルゴリズムとSHA-1細切れ肉料理で計算されます。
This field starts after the Key Hash field. The length of the
Digital Signature field is determined by the length of the RSA
Signature option minus the length of the other fields (including
the variable length Pad field).
この野原はKey Hash分野の後に始まります。 RSA Signatureオプションの長さに従って、Digital Signature分野の長さは他の分野(可変長Pad分野を含んでいる)の長さを引いて決定しています。
Padding
詰め物
This variable-length field contains padding, as many bytes long as
remain after the end of the signature.
この可変長の分野は署名の終わりの長い残っているのと同じくらい多くのバイト後に詰め物を含みます。
Arkko, et al. Standards Track [Page 15] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[15ページ]RFC3971
5.2.1. Processing Rules for Senders
5.2.1. Sendersのための処理規則
If the node has been configured to use SEND, Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, and Redirect messages MUST contain the RSA Signature option. Router Solicitation messages not sent with the unspecified source address MUST contain the RSA Signature option.
ノードがSENDを使用するために構成されたなら、Neighbor Solicitation、Neighbor Advertisement、Router Advertisement、およびRedirectメッセージはRSA Signatureオプションを含まなければなりません。 不特定のソースアドレスと共に送られなかったルータSolicitationメッセージはRSA Signatureオプションを含まなければなりません。
A node sending a message with the RSA Signature option MUST construct the message as follows:
RSA Signatureオプションと共にメッセージを送るノードは以下のメッセージを構成しなければなりません:
o The message is constructed in its entirety, without the RSA
Signature option.
o メッセージはRSA Signatureオプションなしで全体として構成されます。
o The RSA Signature option is added as the last option in the
message.
o RSA Signatureオプションはメッセージにおける最後のオプションとして加えられます。
o The data to be signed is constructed as explained in Section 5.2,
under the description of the Digital Signature field.
o サインされるべきデータはセクション5.2でDigital Signature分野の記述で説明されるように構成されます。
o The message, in the form defined above, is signed by using the
configured private key, and the resulting PKCS#1 v1.5 signature is
put in the Digital Signature field.
o 上で定義された書式では、構成された秘密鍵を使用することによって、メッセージはサインされます、そして、結果として起こるPKCS#1v1.5署名はDigital Signature分野に置かれます。
5.2.2. Processing Rules for Receivers
5.2.2. 受信機のための処理規則
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, and Redirect messages without the RSA Signature option MUST be treated as unsecured (i.e., processed in the same way as NDP messages sent by a non-SEND node). See Section 8.
RSA Signatureオプションのないメッセージを扱わなければならない隣人Solicitation、Neighbor Advertisement、Router Advertisement、およびRedirectは非安全にしました(すなわち、NDPメッセージが発信したのと同様に、非SENDノードで処理されます)。 セクション8を見てください。
Router Solicitation messages without the RSA Signature option MUST also be treated as unsecured, unless the source address of the message is the unspecified address.
またオプションを扱わなければならないRSA SignatureのないルータSolicitationメッセージは非安全にされました、メッセージのソースアドレスが不特定のアドレスでないなら。
Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages containing an RSA Signature option MUST be checked as follows:
再直接です、以下の通りRSA Signatureオプションを含むNeighbor Solicitation、Neighbor Advertisement、Router Solicitation、およびRouter Advertisementメッセージをチェックしなければなりません:
o The receiver MUST ignore any options that come after the first RSA
Signature option. (The options are ignored for both signature
verification and NDP processing purposes.)
o 受信機は最初のRSA Signatureオプションに続くどんなオプションも無視しなければなりません。 (オプションは署名照合とNDP処理目的の両方のために無視されます。)
o The Key Hash field MUST indicate the use of a known public key,
either one learned from a preceding CGA option in the same
message, or one known by other means.
o Key Hash分野は知られている公開鍵の使用を示さなければなりません、とどちらかが、同じメッセージにおける前のCGAオプション、または他の手段によって知られていたものから学びました。
Arkko, et al. Standards Track [Page 16] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[16ページ]RFC3971
o The Digital Signature field MUST have correct encoding and MUST
not exceed the length of the RSA Signature option minus the
Padding.
o Digital Signature分野は、正しいコード化を持たなければならなくて、Paddingを引いてRSA Signatureオプションの長さを超えてはいけません。
o The Digital Signature verification MUST show that the signature
has been calculated as specified in the previous section.
o Digital Signature検証は、前項で指定されるように署名について計算してあるのを示さなければなりません。
o If the use of a trust anchor has been configured, a valid
certification path (see Section 6.3) between the receiver's trust
anchor and the sender's public key MUST be known.
o 信用アンカーの使用が構成されたなら、受信機の信用アンカーと送付者の公開鍵の間の有効な証明経路(セクション6.3を見る)を知っていなければなりません。
Note that the receiver may verify just the CGA property of a
packet, even if, in addition to CGA, the sender has used a trust
anchor.
受信機がまさしくパケットのCGAの特性について確かめるかもしれないことに注意してください、送付者がCGAに加えて信用アンカーを使用したとしても。
Messages that do not pass all the above tests MUST be silently discarded if the host has been configured to accept only secured ND messages. The messages MAY be accepted if the host has been configured to accept both secured and unsecured messages but MUST be treated as an unsecured message. The receiver MAY also otherwise silently discard packets (e.g., as a response to an apparent CPU exhausting DoS attack).
ホストが安全にされたノースダコタメッセージだけを受け入れるために構成されたなら、静かにすべての上のテストに合格するというわけではないメッセージを捨てなければなりません。 メッセージをともに安全にして、ホストが受け入れるために構成されたなら受け入れられるかもしれなくて、メッセージを非安全にしましたが、非安全にされたメッセージとして扱わなければなりません。 また、そうでなければ、受信機は静かに、パケット(例えば、DoS攻撃がくたくたになる見かけのCPUへの応答としての)を捨てるかもしれません。
5.2.3. Configuration
5.2.3. 構成
All nodes that support the reception of the RSA Signature options MUST allow the following information to be configured for each separate NDP message type:
RSA Signatureオプションのレセプションを支えるすべてのノードが、以下の情報がそれぞれの別々のNDPメッセージタイプのために構成されるのを許容しなければなりません:
authorization method
認可方法
This parameter determines the method through which the authority
of the sender is determined. It can have four values:
このパラメタは送付者の権威が決定している方法を決定します。 それは4つの値を持つことができます:
trust anchor
信用アンカー
The authority of the sender is verified as described in
Section 6.3. The sender may claim additional authorization
through the use of CGAs, but this is neither required nor
verified.
送付者の権威はセクション6.3で説明されるように確かめられます。 送付者がCGAsの使用で追加認可を要求するかもしれませんが、これは、必要でなく、また確かめられません。
CGA
CGA
The CGA property of the sender's address is verified as
described in [11]. The sender may claim additional
authority through a trust anchor, but this is neither
required nor verified.
送付者のアドレスのCGAの特性は[11]で説明されるように確かめられます。 送付者が信用アンカーを通して追加権威を要求するかもしれませんが、これは、必要でなく、また確かめられません。
Arkko, et al. Standards Track [Page 17] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[17ページ]RFC3971
trust anchor and CGA
信用アンカーとCGA
Both the trust anchor and the CGA verification is required.
ともに、信用アンカーとCGA検証が必要です。
trust anchor or CGA
信用アンカーかCGA
Either the trust anchor or the CGA verification is required.
信用アンカーかCGA検証のどちらかが必要です。
anchor
アンカー
The allowed trust anchor(s), if the authorization method is not
set to CGA.
許容信用アンカーであり、方法は認可であるならCGAに設定されません。
All nodes that support sending RSA Signature options MUST record the following configuration information:
オプションをRSA Signatureに送るのを支えるすべてのノードが以下の設定情報を記録しなければなりません:
keypair
keypair
A public-private key pair. If authorization delegation is in
use, a certification path from a trust anchor to this key pair
must exist.
公共の秘密鍵組。 認可代表団が使用中であるなら、信用アンカーから主要なこの組までの証明経路は存在しなければなりません。
CGA flag
CGA旗
A flag that indicates whether CGA is used or not. This flag
may be per interface or per node. (Note that in future
extensions of the SEND protocol, this flag may also be per
subnet prefix.)
CGAが使用されているかどうかを示す旗。 この旗はインタフェースかノード単位であるかもしれません。 (また、SENDプロトコルの今後の拡大この旗もサブネット接頭語単位で中であるかもしれないことに注意してください。)
5.2.4. Performance Considerations
5.2.4. パフォーマンス問題
The construction and verification of the RSA Signature option is computationally expensive. In the NDP context, however, hosts typically only have to perform a few signature operations as they enter a link, a few operations as they find a new on-link peer with which to communicate, or Neighbor Unreachability Detection with existing neighbors.
RSA Signatureオプションの工事と検証は計算上高価です。 しかしながら、NDP文脈では、リンク(彼らが既存の隣人と共にリンクの上の交信する新しい同輩、またはNeighbor Unreachability Detectionを見つけるようないくつかの操作)に入るとき、ホストはいくつかの署名操作を通常実行するだけでよいです。
Routers are required to perform a larger number of operations, particularly when the frequency of router advertisements is high due to mobility requirements. Still, the number of required signature operations is on the order of a few dozen per second, some of which can be precomputed as explained below. A large number of router solicitations may cause a higher demand for performing asymmetric operations, although the base NDP protocol limits the rate at which multicast responses to solicitations can be sent.
ルータが、より多くの操作を実行するのに必要です、特にルータ通知の頻度が移動性要件のために高いときに。 それでも、必要な署名操作の数が1秒あたりのダースにいくつかの注文にはあります。以下で説明されるようにその或るものを前計算できます。 多くのルータ懇願が非対称の操作を実行するより高い要求を引き起こすかもしれなくて、ベースNDPは限界について議定書の中で述べますが、懇願へのどのマルチキャスト応答のときにレートを送ることができるか。
Arkko, et al. Standards Track [Page 18] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[18ページ]RFC3971
Signatures can be precomputed for unsolicited (multicast) Neighbor and Router Advertisements if the timing of the future advertisements is known. Typically, solicited neighbor advertisements are sent to the unicast address from which the solicitation was sent. Given that the IPv6 header is covered by the signature, it is not possible to precompute solicited advertisements.
将来の広告のタイミングが知られているなら、求められていない(マルチキャスト)隣人とRouter Advertisementsのために署名を前計算できます。 通常、懇願が送られたユニキャストアドレスに請求された隣人広告を送ります。 IPv6ヘッダーが署名で覆われているなら、precomputeに、広告が請求していたのは、可能ではありません。
5.3. Timestamp and Nonce Options
5.3. タイムスタンプと一回だけのオプション
5.3.1. Timestamp Option
5.3.1. タイムスタンプオプション
The purpose of the Timestamp option is to make sure that unsolicited advertisements and redirects have not been replayed. The format of this option is described in the following:
オプションが確実にその未承諾広告をすることになっているTimestampを目標として、向け直す、再演されないでください。 このオプションの形式は以下で説明されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + タイムスタンプ+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
13
13
Length
長さ
The length of the option (including the Type, Length, Reserved,
and Timestamp fields) in units of 8 octets; i.e., 2.
8つの八重奏のユニットのオプション(Type、Length、Reserved、およびTimestamp分野を含んでいる)の長さ。 すなわち、2。
Reserved
予約されます。
A 48-bit field reserved for future use. The value MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.
今後の使用のために予約された48ビットの分野。 値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Arkko, et al. Standards Track [Page 19] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[19ページ]RFC3971
Timestamp
タイムスタンプ
A 64-bit unsigned integer field containing a timestamp. The value
indicates the number of seconds since January 1, 1970, 00:00 UTC,
by using a fixed point format. In this format, the integer number
of seconds is contained in the first 48 bits of the field, and the
remaining 16 bits indicate the number of 1/64K fractions of a
second.
タイムスタンプを含む64ビットの符号のない整数分野。 値は、定点形式を使用することによって、1970年1月1日、協定世界時0時0分以来の秒数を示します。 この形式では、整数秒数は分野の最初の48ビットに含まれています、そして、残っている16ビットは1秒の1/64Kの何分の一の数を示します。
Implementation note: This format is compatible with the usual
representation of time under UNIX, although the number of bits
available for the integer and fraction parts may vary.
実現注意: この形式はUNIXの下において時間の普通の表現と互換性があります、整数と小数部に有効なビットの数は異なるかもしれませんが。
5.3.2. Nonce Option
5.3.2. 一回だけのオプション
The purpose of the Nonce option is to make sure that an advertisement is a fresh response to a solicitation sent earlier by the node. The format of this option is described in the following:
Nonceオプションの目的は広告が、より早くノードによって送られた懇願への新鮮な応答であることを確実にすることです。 このオプションの形式は以下で説明されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Nonce ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 一回だけ… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
14
14
Length
長さ
The length of the option (including the Type, Length, and Nonce
fields) in units of 8 octets.
8つの八重奏のユニットのオプション(Type、Length、およびNonce分野を含んでいる)の長さ。
Nonce
一回だけ
A field containing a random number selected by the sender of the
solicitation message. The length of the random number MUST be at
least 6 bytes. The length of the random number MUST be selected
so that the length of the nonce option is a multiple of 8 octets.
懇願メッセージの送付者によって選択された乱数を含む分野。 乱数の長さは少なくとも6バイトでなければなりません。 乱数の長さを選択しなければならないので、一回だけのオプションの長さは8つの八重奏の倍数です。
Arkko, et al. Standards Track [Page 20] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[20ページ]RFC3971
5.3.3. Processing Rules for Senders
5.3.3. Sendersのための処理規則
If the node has been configured to use SEND, all solicitation messages MUST include a Nonce. When sending a solicitation, the sender MUST store the nonce internally so that it can recognize any replies containing that particular nonce.
ノードがSENDを使用するために構成されたなら、すべての懇願メッセージがNonceを含まなければなりません。 懇願を送るとき、送付者は、その特定の一回だけを含むどんな回答も認識できるように、内部的に一回だけを格納しなければなりません。
If the node has been configured to use SEND, all advertisements sent in reply to a solicitation MUST include a Nonce, copied from the received solicitation. Note that routers may decide to send a multicast advertisement to all nodes instead of a response to a specific host. In such a case, the router MAY still include the nonce value for the host that triggered the multicast advertisement. (Omitting the nonce value may cause the host to ignore the router's advertisement, unless the clocks in these nodes are sufficiently synchronized so that timestamps function properly.)
ノードがSENDを使用するために構成されたなら、懇願に対して送られたすべての広告が容認された懇願からコピーされたNonceを含まなければなりません。 ルータが、応答の代わりに特定のホストへのすべてのノードにマルチキャスト広告を送ると決めるかもしれないことに注意してください。 このような場合には、ルータはまだマルチキャスト広告の引き金となったホストにとっての一回だけの値を含んでいるかもしれません。 (ホストは一回だけの値を省略するのにルータの広告を無視するかもしれません、これらのノードの時計が十分連動するのでタイムスタンプが適切に機能しない場合。)
If the node has been configured to use SEND, all solicitation, advertisement, and redirect messages MUST include a Timestamp. Senders SHOULD set the Timestamp field to the current time, according to their real time clocks.
ノードがSENDを使用するために構成されたなら、すべての懇願、広告、および再直接のメッセージはTimestampを含まなければなりません。 彼らのリアルタイムクロックに従って、送付者SHOULDは現在の時間にTimestamp分野を設定します。
5.3.4. Processing Rules for Receivers
5.3.4. 受信機のための処理規則
The processing of the Nonce and Timestamp options depends on whether a packet is a solicited advertisement. A system may implement the distinction in various ways. Section 5.3.4.1 defines the processing rules for solicited advertisements. Section 5.3.4.2 defines the processing rules for all other messages.
NonceとTimestampオプションの処理はパケットが請求された広告であるかどうかによります。 システムはいろいろ区別を実行するかもしれません。 セクション5.3 .4 .1 請求された広告のための処理規則を定義します。 セクション5.3 .4 .2 他のすべてのメッセージのために処理規則を定義します。
In addition, the following rules apply in all cases:
さらに、以下の規則はすべての場合で適用されます:
o Messages received without at least one of the Timestamp and Nonce
options MUST be treated as unsecured (i.e., processed in the same
way as NDP messages sent by a non-SEND node).
o メッセージは少なくともTimestampの1つなしで受信されました、そして、オプションを扱わなければならないNonceは非安全にしました(すなわち、NDPメッセージが発信したのと同様に、非SENDノードで処理されます)。
o Messages received with the RSA Signature option but without the
Timestamp option MUST be silently discarded.
o 静かにRSA Signatureオプションにもかかわらず、Timestampオプションなしで受け取られたメッセージを捨てなければなりません。
o Solicitation messages received with the RSA Signature option but
without the Nonce option MUST be silently discarded.
o 静かにRSA Signatureオプションにもかかわらず、Nonceオプションなしで受け取られた懇願メッセージを捨てなければなりません。
o Advertisements sent to a unicast destination address with the RSA
Signature option but without a Nonce option SHOULD be processed as
unsolicited advertisements.
o 広告はRSA Signatureオプションと共にユニキャスト送付先アドレスに発信しましたが、未承諾広告としてNonceオプションSHOULDなしで処理されてください。
Arkko, et al. Standards Track [Page 21] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[21ページ]RFC3971
o An implementation MAY use some mechanism such as a timestamp cache
to strengthen resistance to replay attacks. When there is a very
large number of nodes on the same link, or when a cache filling
attack is in progress, it is possible that the cache holding the
most recent timestamp per sender will become full. In this case,
the node MUST remove some entries from the cache or refuse some
new requested entries. The specific policy as to which entries
are preferred over others is left as an implementation decision.
However, typical policies may prefer existing entries to new ones,
CGAs with a large Sec value to smaller Sec values, and so on. The
issue is briefly discussed in Appendix B.
o 実現は、反射攻撃への抵抗を強化するのにタイムスタンプキャッシュなどの何らかのメカニズムを使用するかもしれません。 同じリンクの上に非常に多くのノードがあるか、または攻撃をいっぱいにするキャッシュが進行しているとき、1送付者あたりの最新のタイムスタンプを保持するキャッシュが完全になるのは、可能です。 この場合、ノードは、キャッシュからいくつかのエントリーを取り除かなければならないか、またはいくつかの新しい要求されたエントリーを拒否しなければなりません。 エントリーが他のものより好まれる特定保険証券は実現決定として残されます。 しかしながら、典型的な方針は新しいもの、より小さいSec値への大きいSec値があるCGAsなどより既存のエントリーを好むかもしれません。 Appendix Bで簡潔に問題について議論します。
o The receiver MUST be prepared to receive the Timestamp and Nonce
options in any order, as per RFC 2461 [4], Section 9.
o 順不同なTimestampとNonceオプションを受け取るように受信機を準備しなければなりません、RFC2461[4]に従って、セクション9。
5.3.4.1. Processing Solicited Advertisements
5.3.4.1. 処理は広告を勧誘しました。
The receiver MUST verify that it has recently sent a matching solicitation, and that the received advertisement contains a copy of the Nonce sent in the solicitation.
受信機は、最近、合っている懇願を送って、受け取られていている広告が懇願で送られたNonceのコピーを含むことを確かめなければなりません。
If the message contains a Nonce option but the Nonce value is not recognized, the message MUST be silently discarded.
メッセージがNonceオプションを含んでいますが、Nonce値が認識されないなら、静かにメッセージを捨てなければなりません。
Otherwise, if the message does not contain a Nonce option, it MAY be considered an unsolicited advertisement and processed according to Section 5.3.4.2.
さもなければ、メッセージがNonceオプションを含んでいないなら、それは、.2に求められていない広告であると考えられて、セクション5.3.4に従って、処理されるかもしれません。
If the message is accepted, the receiver SHOULD store the receive time of the message and the timestamp time in the message, as specified in Section 5.3.4.2.
メッセージを受け入れます、SHOULDが格納する受信機、メッセージでメッセージの時間とタイムスタンプ時間を得てください、セクション5.3.4で.2に指定されるように
5.3.4.2. Processing All Other Messages
5.3.4.2. 他のすべてのメッセージを処理します。
Receivers SHOULD be configured with an allowed timestamp Delta value, a "fuzz factor" for comparisons, and an allowed clock drift parameter. The recommended default value for the allowed Delta is TIMESTAMP_DELTA; for fuzz factor TIMESTAMP_FUZZ; and for clock drift, TIMESTAMP_DRIFT (see Section 10.2).
受信機SHOULDが許容タイムスタンプデルタ価値によって構成されて、比較、および許容時計のための「むく毛要素」はパラメタに流されます。 許容デルタにおけるお勧めのデフォルト値はTIMESTAMP_デルタです。 むく毛に関しては、TIMESTAMP_FUZZを因数分解してください。 TIMESTAMP_DRIFT、そして、時計に関して、漂流してください(セクション10.2を見てください)。
To facilitate timestamp checking, each node SHOULD store the following information for each peer:
タイムスタンプの照合を容易にするために、各ノードSHOULDは各同輩のために以下の情報を格納します:
o The receive time of the last received and accepted SEND message.
This is called RDlast.
o 最後の受け取られていていて受け入れられたSENDメッセージの時間を得てください。 これはRDlastと呼ばれます。
o The time stamp in the last received and accepted SEND message.
This is called TSlast.
o 最終のタイムスタンプは、SENDメッセージを受け取って、受け入れました。 これはTSlastと呼ばれます。
Arkko, et al. Standards Track [Page 22] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[22ページ]RFC3971
An accepted SEND message is any successfully verified Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, or Redirect message from the given peer. The RSA Signature option MUST be used in such a message before it can update the above variables.
受け入れられたSENDメッセージは、与えられた同輩からのどんな首尾よく確かめられたNeighbor Solicitation、Neighbor Advertisement、Router Solicitation、Router Advertisement、またはRedirectメッセージです。 上の変数をアップデートできる前にそのようなメッセージでRSA Signatureオプションを使用しなければなりません。
Receivers SHOULD then check the Timestamp field as follows:
次に、受信機SHOULDは以下のTimestamp分野をチェックします:
o When a message is received from a new peer (i.e., one that is not
stored in the cache), the received timestamp, TSnew, is checked,
and the packet is accepted if the timestamp is recent enough to
the reception time of the packet, RDnew:
o 新しい同輩(すなわち、キャッシュに格納されないもの)からメッセージを受け取るとき、受信されたタイムスタンプ(TSnew)をチェックします、そして、タイムスタンプがパケットのレセプション時間に十分最近なら、パケットを受け入れます、RDnew:
-Delta < (RDnew - TSnew) < +Delta
-デルタ<(RDnew--TSnew)<+デルタ
The RDnew and TSnew values SHOULD be stored in the cache as RDlast
and TSlast.
RDnewとTSnewは格納されたコネがRDlastとTSlastとしてキャッシュであったならSHOULDを評価します。
o If the timestamp is NOT within the boundaries but the message is a
Neighbor Solicitation message that the receiver should answer, the
receiver SHOULD respond to the message. However, even if it does
respond to the message, it MUST NOT create a Neighbor Cache entry.
This allows nodes that have large differences in their clocks to
continue communicating with each other by exchanging NS/NA pairs.
o タイムスタンプが境界の中のそうではありませんが、メッセージが受信機に答えるはずであるというNeighbor Solicitationメッセージであるなら、受信機SHOULDはメッセージに応じます。 しかしながら、メッセージに応じても、それはNeighbor Cacheエントリーを作成してはいけません。 これで、それらの時計に大きな違いを持っているノードは、NS/NA組を交換することによって互いにコミュニケートし続けることができます。
o When a message is received from a known peer (i.e., one that
already has an entry in the cache), the timestamp is checked
against the previously received SEND message:
o 知られている同輩(すなわち、既にキャッシュにおけるエントリーを持っているもの)からメッセージを受け取るとき、以前に受信されたSENDメッセージに対してタイムスタンプをチェックします:
TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz
TSnew+むく毛>TSlast+(RDnew--RDlast)x(1--ドリフト)--むく毛
If this inequality does not hold, the receiver SHOULD silently
discard the message. If, on the other hand, the inequality holds,
the receiver SHOULD process the message.
この不平等が成立しないなら、受信機SHOULDは静かにメッセージを捨てます。 他方では、不平等が成立するなら、受信機SHOULDはメッセージを処理します。
Moreover, if the above inequality holds and TSnew > TSlast, the
receiver SHOULD update RDlast and TSlast. Otherwise, the receiver
MUST NOT update RDlast or TSlast.
上の不平等が成立するか、そして、TSnew>TSlast、そのうえ、受信機SHOULDはRDlastとTSlastをアップデートします。 さもなければ、受信機はRDlastかTSlastをアップデートしてはいけません。
As unsolicited messages may be used in a Denial-of-Service attack to make the receiver verify computationally expensive signatures, all nodes SHOULD apply a mechanism to prevent excessive use of resources for processing such messages.
受信機に計算上高価な署名について確かめさせるのにお節介なメッセージがサービス不能攻撃に使用されるとき、すべてのノードSHOULDが、リソースのそのようなメッセージを処理する過用を防ぐためにメカニズムを適用します。
Arkko, et al. Standards Track [Page 23] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[23ページ]RFC3971
6. Authorization Delegation Discovery
6. 承認委譲発見
NDP allows a node to configure itself automatically based on information learned shortly after connecting to a new link. It is particularly easy to configure "rogue" routers on an unsecured link, and it is particularly difficult for a node to distinguish between valid and invalid sources of router information, because the node needs this information before communicating with nodes outside of the link.
NDPで、ノードは新しいリンクに接続したすぐ後に学習された情報に基づいて自動的にそれ自体を構成できます。 非機密保護しているリンクの上に「凶暴な」ルータを構成するのが特に簡単であり、ノードがルータ情報の有効で無効の源を見分けるのは、特に難しいです、ノードがリンクの外でノードとコミュニケートする前にこの情報を必要とするので。
As the newly-connected node cannot communicate off-link, it cannot be responsible for searching information to help validate the router(s). However, given a certification path, the node can check someone else's search results and conclude that a particular message comes from an authorized source. In the typical case, a router already connected beyond the link can communicate if necessary with off-link nodes and construct a certification path.
新たに接続されたノードがオフリンクを伝えることができないので、探す情報が、ルータを有効にするのを助けるのは、責任があるはずがありません。 しかしながら、証明経路を考えて、ノードは、他の誰かの検索結果をチェックして、特定のメッセージが認可されたソースから来ると結論を下すことができます。 典型的な場合では、既にリンクを超えて接続されたルータは、必要ならオフリンクノードとコミュニケートして、証明経路を構成できます。
The Secure Neighbor Discovery Protocol mandates a certificate format and introduces two new ICMPv6 messages used between hosts and routers to allow the host to learn a certification path with the assistance of the router.
Secure Neighborディスカバリープロトコルは、証明書形式を強制して、ルータの支援でホストが証明経路を学ぶのを許容するのにホストとルータの間で使用される2つの新しいICMPv6メッセージを紹介します。
6.1. Authorization Model
6.1. 承認モデル
To protect Router Discovery, SEND requires that routers be authorized to act as routers. This authorization is provisioned in both routers and hosts. Routers are given certificates from a trust anchor, and the hosts are configured with the trust anchor(s) to authorize routers. This provisioning is specific to SEND and does not assume that certificates already deployed for some other purpose can be used.
Routerディスカバリーを保護するために、SENDは、ルータがルータとして機能するのが認可されるのを必要とします。 この承認はルータとホストの両方で食糧を供給されます。 信頼アンカーからの証明書をルータに与えます、そして、信頼アンカーでホストを構成して、ルータを認可します。 この食糧を供給するのは、SENDに特定であり、ある他の目的のために既に配布された証明書は使用できると仮定しません。
The authorization for routers in SEND is twofold:
SENDのルータのための承認は二つです:
o Routers are authorized to act as routers. The router belongs to
the set of routers trusted by the trust anchor. All routers in
this set have the same authorization.
o ルータがルータとして機能するのが認可されます。 ルータは信頼アンカーによって信じられたルータのセットに属します。 このセットにおけるすべてのルータには、同じ承認があります。
o Optionally, routers may also be authorized to advertise a certain
set of subnet prefixes. A specific router is given a specific set
of subnet prefixes to advertise; other routers have an
authorization to advertise other subnet prefixes. Trust anchors
may also delegate a certain set of subnet prefixes to someone
(such as an ISP) who, in turn, delegates parts of this set to
individual routers.
o また、任意に、ルータが、あるセットのサブネット接頭語の広告を出すのが認可されるかもしれません。 広告を出す特定のセットのサブネット接頭語を特定のルータに与えます。 他のルータには、他のサブネット接頭語の広告を出す承認があります。 また、信頼アンカーはこのセットの確信しているサブネットのセットが順番にだれか(ISPなどの)へだれを前に置くかを代表部分を個々のルータへ代表として派遣するかもしれません。
Arkko, et al. Standards Track [Page 24] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[24ページ]RFC3971
Note that while communicating with hosts, routers typically also present a number of other parameters beyond the above. For instance, routers have their own IP addresses, subnet prefixes have lifetimes, and routers control the use of stateless and stateful address autoconfiguration. However, the ability to be a router and the subnet prefixes are the most fundamental parameters to authorize. This is because the host needs to choose a router that it uses as its default router, and because the advertised subnet prefixes have an impact on the addresses the host uses. The subnet prefixes also represent a claim about the topological location of the router in the network.
また、ルータがホストとコミュニケートしている間上記を超えた他の多くのパラメタを通常提示することに注意してください。 例えば、ルータはそれら自身のIP住所を知っています、そして、サブネット接頭語には、寿命があります、そして、ルータは状態がなくてstatefulなアドレス自動構成の使用を制御します。 しかしながら、ルータである能力とサブネット接頭語は認可する中で最も基本的なパラメタです。 これはホストが、それがデフォルトルータとして使用するルータを選ぶ必要があって、広告を出しているサブネット接頭語がホストが使用するアドレスに影響を与えるからです。 また、サブネット接頭語はネットワークでルータの位相的な位置に関するクレームを表します。
Care should be taken if the certificates used in SEND are also used to provide authorization in other circumstances; for example, with routing protocols. It is necessary to ensure that the authorization information is appropriate for all applications. SEND certificates may authorize a larger set of subnet prefixes than the router is authorized to advertise on a given interface. For instance, SEND allows the use of the null prefix, which might cause verification or routing problems in other applications. It is RECOMMENDED that SEND certificates containing the null prefix are only used for SEND.
また、SENDで使用される証明書が他の事情に承認を提供するのに使用されるなら、注意するべきです。 例えばルーティング・プロトコルで。 承認情報が確実にすべてのアプリケーションに適切になるようにするのが必要です。 SEND証明書はルータが与えられたインタフェースに広告を出すのが認可されるより大きいセットのサブネット接頭語を認可するかもしれません。 例えば、SENDはヌル接頭語の使用を許します。(接頭語は他のアプリケーションにおける検証かルーティング問題を引き起こすかもしれません)。 ヌル接頭語を含むSEND証明書がSENDに使用されるだけであるのは、RECOMMENDEDです。
Note that end hosts need not be provisioned with their own certified public keys, just as Web clients today do not require end host provisioning with certified keys. Public keys for CGA generation do not need to be certified, as these keys derive their ability to authorize operations on the CGA by the tie to the address.
それら自身のが公開鍵であることが公認されている状態で終わりのホストが食糧を供給される必要はないことに注意してください、今日のウェブクライアントが公認されたキーによる終わりのホストの食糧を供給することを必要とするだけではないように。 CGA世代公開鍵は公認される必要はありません、これらのキーがCGAでアドレスへの繋がりで操作を認可する彼らの能力を引き出すとき。
6.2. Deployment Model
6.2. 展開モデル
The deployment model for trust anchors can be either a globally rooted public key infrastructure or a more local, decentralized deployment model similar to that currently used for TLS in Web servers. The centralized model assumes a global root capable of authorizing routers and, optionally, the address space they advertise. The end hosts are configured with the public keys of the global root. The global root could operate, for instance, under the Internet Assigned Numbers Authority (IANA) or as a co-operative among Regional Internet Registries (RIRs). However, no such global root currently exists.
信頼アンカーのための展開モデルは、ウェブサーバにおいて現在TLSに使用されているそれと同様のグローバルに根づいている公開鍵認証基盤か、より地方の、そして、分散している展開モデルのどちらかであるかもしれません。 集結されたモデルは、広告を出すとルータと任意にアドレス空間を認可できるグローバルな根に仮定します。 終わりのホストはグローバルな根の公開鍵によって構成されます。 例えば、グローバルな根はインターネットAssigned民数記Authority(IANA)か協同組合としてRegionalインターネットRegistries(RIRs)の中で作動できました。 しかしながら、そのようなどんなグローバルな根も現在、存在しません。
In the decentralized model, end hosts are configured with a collection of trusted public keys. The public keys could be issued from various places; for example, a) a public key for the end host's own organization, b) a public key for the end host's home ISP and for ISPs with which the home ISP has a roaming agreement, or c) public keys for roaming brokers acting as intermediaries for ISPs that don't want to run their own certification authority.
分散モデルでは、終わりのホストは信じられた公開鍵の収集によって構成されます。 様々な場所から公開鍵を発行できました。 例えば、a) 終わりのホストの自身の組織のための公開鍵、b) 終わりのホストのホームISPとISPのためのホームISPにはローミング協定、またはc)公開鍵がローミングのためにある公開鍵はそれら自身の証明権威を実行したがっていないISPのための仲介者として芝居を仲介します。
Arkko, et al. Standards Track [Page 25] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[25ページ]RFC3971
This decentralized model works even when a SEND node is used both in networks that have certified routers and in networks that do not. As discussed in Section 8, a SEND node can fall back to the use of a non-SEND router. This makes it possible to start with a local trust anchor even if there is no trust anchor for all possible networks.
SENDノードがルータを公認したネットワークとそうしないネットワークに使用さえされるとき、これはモデル作品を分散しました。 セクション8で議論するように、SENDノードは非SENDルータの使用へ後ろへ下がることができます。 これで、すべての可能なネットワークのための信頼アンカーが全くいないでも、地元の信頼アンカーから始めるのは可能になります。
6.3. Certificate Format
6.3. 証明書形式
The certification path of a router terminates in a Router Authorization Certificate that authorizes a specific IPv6 node to act as a router. Because authorization paths are not a common practice in the Internet at the time of this writing, the path MUST consist of standard Public Key Certificates (PKC, in the sense of [8]). The certification path MUST start from the identity of a trust anchor shared by the host and the router. This allows the host to anchor trust for the router's public key in the trust anchor. Note that there MAY be multiple certificates issued by a single trust anchor.
ルータの証明経路は特定のIPv6ノードがルータとして機能するのを認可するRouter Authorization Certificateで終わります。 承認経路がこの書くこと時点のインターネットの一般的な習慣でないので、経路は標準のPublic Key Certificatesから成らなければなりません。([8])の意味におけるPKC。 証明経路はホストとルータによって共有された信頼アンカーのアイデンティティから始めなければなりません。 これで、ホストはルータの公開鍵のために信頼アンカーに信頼を据えつけることができます。 独身の信頼アンカーによって発行された複数の証明書があるかもしれないことに注意してください。
6.3.1. Router Authorization Certificate Profile
6.3.1. ルータ承認証明書プロフィール
Router Authorization Certificates are X.509v3 certificates, as defined in RFC 3280 [7], and SHOULD contain at least one instance of the X.509 extension for IP addresses, as defined in [10]. The parent certificates in the certification path SHOULD contain one or more X.509 IP address extensions, back up to a trusted party (such as the user's ISP) that configured the original IP address block for the router in question, or that delegated the right to do so. The certificates for the intermediate delegating authorities SHOULD contain X.509 IP address extension(s) for subdelegations. The router's certificate is signed by the delegating authority for the subnet prefixes the router is authorized to advertise.
ルータAuthorization CertificatesはRFC3280[7]で定義されるようにX.509v3証明書です、そして、SHOULDはIPアドレスのためのX.509拡張子の少なくとも1つのインスタンスを含んでいます、[10]で定義されるように。 証明経路SHOULDの親証明書は1つ以上のX.509 IPアドレス拡張子を問題のルータのための元のIPあて先ブロックを構成したか、またはそうする権利を代表として派遣した信じられたパーティー(ユーザのISPなどの)まで含んでいます。 SHOULD当局を代表として派遣する中間介在物のための証明書は「副-委譲」のためのX.509 IPアドレス拡張子を含んでいます。 ルータの証明書はサブネット接頭語のために権限を委ねることで署名されて、ルータが広告を出すのが認可されるということです。
The X.509 IP address extension MUST contain at least one addressesOrRanges element. This element MUST contain an addressPrefix element containing an IPv6 address prefix for a prefix that the router or the intermediate entity is authorized to route. If the entity is allowed to route any prefix, the IPv6 address prefix used is the null prefix, ::/0. The addressFamily element of the IPAddrBlocks sequence element MUST contain the IPv6 Address Family Identifier (0002), as specified in [10], for IPv6 subnet prefixes. Instead of an addressPrefix element, the addressesOrRange element MAY contain an addressRange element for a range of subnet prefixes, if more than one prefix is authorized. The X.509 IP address extension MAY contain additional IPv6 subnet prefixes, expressed as either an addressPrefix or an addressRange.
X.509 IPアドレス拡張子は少なくとも1つのaddressesOrRanges要素を含まなければなりません。 この要素はルータか中間的実体が発送するのが認可される接頭語のためのIPv6アドレス接頭語を含むaddressPrefix要素を含まなければなりません。 実体が何か接頭語を発送できるなら、アドレス接頭語が使用したIPv6がヌル接頭語である、:、:/0. IPAddrBlocks系列要素のaddressFamily要素はIPv6 Address Family Identifier(0002)を含まなければなりません、[10]で指定されるように、IPv6サブネット接頭語のために。 addressPrefix要素の代わりに、addressesOrRange要素はさまざまなサブネット接頭語のためのaddressRange要素を含むかもしれません、1つ以上の接頭語が認可されているなら。 X.509 IPアドレス拡張子はaddressPrefixかaddressRangeのどちらかとして表された追加IPv6サブネット接頭語を含むかもしれません。
Arkko, et al. Standards Track [Page 26] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[26ページ]RFC3971
A node receiving a Router Authorization Certificate MUST first check whether the certificate's signature was generated by the delegating authority. Then the client SHOULD check whether all the addressPrefix or addressRange entries in the router's certificate are contained within the address ranges in the delegating authority's certificate, and whether the addressPrefix entries match any addressPrefix entries in the delegating authority's certificate. If an addressPrefix or addressRange is not contained within the delegating authority's subnet prefixes or ranges, the client MAY attempt to take an intersection of the ranges/subnet prefixes and to use that intersection. If the resulting intersection is empty, the client MUST NOT accept the certificate. If the addressPrefix in the certificate is missing or is the null prefix, ::/0, the parent prefix or range SHOULD be used. If there is no parent prefix or range, the subnet prefixes that the router advertises are said to be unconstrained (see Section 7.3). That is, the router is allowed to advertise any prefix.
Router Authorization Certificateを受けるノードは、最初に、証明書の署名が権限を委ねることで生成されたかどうかチェックしなければなりません。 そして、クライアントSHOULDは、ルータの証明書におけるすべてのaddressPrefixかaddressRangeエントリーが代表として派遣する権威の証明書のアドレスの範囲の中に保管されているかどうかと、addressPrefixエントリーが何か代表として派遣する権威の証明書におけるaddressPrefixエントリーに合っているかどうかチェックします。 addressPrefixかaddressRangeが権限を委ねることのサブネットが前に置く中に含まれていないか、または及ぶなら、クライアントは、範囲/サブネット接頭語の交差点を取って、その交差点を使用するのを試みるかもしれません。 結果として起こる交差点が人影がないなら、クライアントは証明書を受け入れてはいけません。 証明書のaddressPrefixがなくなるか、ヌル接頭語であるなら:、:親の/0、接頭語または範囲SHOULD、使用されてください。 どんな親接頭語も範囲もなければ、ルータが広告を出すサブネット接頭語は自由であると言われます(セクション7.3を見てください)。 すなわち、ルータはどんな接頭語も広告を出すことができます。
The above checks SHOULD be done for all certificates in the path. If any of the checks fail, the client MUST NOT accept the certificate. The client also has to perform validation of advertised subnet prefixes as discussed in Section 7.3.
上記はSHOULDをチェックします。経路のすべての証明書には、してください。 チェックのどれかが失敗するなら、クライアントは証明書を受け入れてはいけません。 クライアントもセクション7.3で議論するように広告を出しているサブネット接頭語の合法化を実行しなければなりません。
Hosts MUST check the subjectPublicKeyInfo field within the last certificate in the certificate path to ensure that only RSA public keys are used to attempt validation of router signatures. Hosts MUST disregard the certificate for SEND if it does not contain an RSA key.
ホストはRSA公開鍵だけがルータ署名の合法化を試みるのに使用されるのを保証する証明書経路における最後の証明書の中にsubjectPublicKeyInfo分野をチェックしなければなりません。 RSAキーを含まないなら、ホストはSENDのための証明書を無視しなければなりません。
As it is possible that some public key certificates used with SEND do not immediately contain the X.509 IP address extension element, an implementation MAY contain facilities that allow the prefix and range checks to be relaxed. However, any such configuration options SHOULD be switched off by default. The system SHOULD have a default configuration that requires rigorous prefix and range checks.
SENDと共に使用されるいくつかの公開鍵証明書がすぐにX.509 IPアドレス拡大要素を含まないのが、可能であるときに、実装は接頭語と範囲検査がリラックスする施設を含むかもしれません。 しかしながら、どんなそのような構成もSHOULDにゆだねます。デフォルトで消されます。 システムSHOULDには、厳密な接頭語と範囲検査を必要とするデフォルト設定があります。
The following is an example of a certification path. Suppose that isp_group_example.net is the trust anchor. The host has this certificate:
↓これは証明経路に関する例です。 isp_グループ_example.netが信頼アンカーであると仮定してください。 ホストには、この証明書があります:
Certificate 1:
Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_group_example.net
Extensions:
IP address delegation extension:
Prefixes: P1, ..., Pk
... possibly other extensions ...
... other certificate parameters ...
証明書1: 発行人: isp_グループ_example.net Validity: 2004年1月1日から2004年12月31日Subject: isp_グループ_example.net Extensions: IPアドレス委譲拡大: 接頭語: P1…, Pk… ことによると他の拡大… 他の…証明書パラメタ…
Arkko, et al. Standards Track [Page 27] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[27ページ]RFC3971
When the host attaches to a link served by router_x.isp_foo_example.net, it receives the following certification path:
ホストがルータ_x.isp_foo_example.netによって役立たれたリンクに付くと、以下の証明経路を受けます:
Certificate 2:
Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_foo_example.net
Extensions:
IP address delegation extension:
Prefixes: Q1, ..., Qk
... possibly other extensions ...
... other certificate parameters ...
証明書2: 発行人: isp_グループ_example.net Validity: 2004年1月1日から2004年12月31日Subject: isp_foo_example.net Extensions: IPアドレス委譲拡大: 接頭語: Q1…, Qk… ことによると他の拡大… 他の…証明書パラメタ…
Certificate 3:
Issuer: isp_foo_example.net
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: router_x.isp_foo_example.net
Extensions:
IP address delegation extension:
Prefixes R1, ..., Rk
... possibly other extensions ...
証明書3: 発行人: isp_foo_example.net Validity: 2004年1月1日から2004年12月31日Subject: ルータ_x.isp_foo_example.net Extensions: IPアドレス委譲拡大: R1を前に置きます…, Rk… ことによると他の拡大…
... other certificate parameters ...
他の…証明書パラメタ…
When the three certificates are processed, the usual RFC 3280 [7] certificate path validation is performed. Note, however, that when a node checks certificates received from a router, it typically does not have a connection to the Internet yet, and so it is not possible to perform an on-line Certificate Revocation List (CRL) check, if necessary. Until this check is performed, acceptance of the certificate MUST be considered provisional, and the node MUST perform a check as soon as it has established a connection with the Internet through the router. If the router has been compromised, it could interfere with the CRL check. Should performance of the CRL check be disrupted or should the check fail, the node SHOULD immediately stop using the router as a default and use another router on the link instead.
3通の証明書が処理されるとき、普通のRFC3280[7]証明書経路合法化は実行されます。 しかしながら、ノードがルータから受け取られた証明書をチェックするとき、インターネットには接続が必要なら、オンラインCertificate Revocation List(CRL)チェックを実行するのが可能でないようにまだ通常ないことに注意してください。 このチェックが実行されるまで、暫定的であると証明書の承認を考えなければなりません、そして、ルータを通してインターネットで取引関係を築くとすぐに、ノードはチェックを実行しなければなりません。 ルータが感染されたなら、それはCRLチェックを妨げるかもしれません。 CRLチェックの性能が中断するべきであるか、またはチェックが失敗するなら、ノードSHOULDはすぐに、デフォルトとしてルータを使用するのを止めて、代わりにリンクの上に別のルータを使用します。
In addition, the IP addresses in the delegation extension MUST be a subset of the IP addresses in the delegation extension of the issuer's certificate. So in this example, R1, ..., Rs must be a subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If the certification path is valid, then router_foo.isp_foo_example.com is authorized to route the prefixes R1,...,Rs.
さらに、委譲拡大におけるIPアドレスは発行人の証明書の委譲拡大におけるIPアドレスの部分集合であるに違いありません。 したがって、この例、R1、…で, RsはQ1の部分集合であるに違いありません…Qr、およびQ1…QrはP1、…の部分集合であるに違いありません。Pk。 証明経路が有効であるなら、ルータ_foo.isp_foo_example.comが接頭語R1、…を発送するのが認可されます。Rs。
Arkko, et al. Standards Track [Page 28] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[28ページ]RFC3971
6.3.2. Suitability of Standard Identity Certificates
6.3.2. 標準のアイデンティティ証明書の適合
As deployment of the IP address extension is, itself, not common, a network service provider MAY choose to deploy standard identity certificates on the router to supply the router's public key for signed Router Advertisements.
IPアドレス拡大の展開があるので、コモン、配布するサービスプロバイダーが標準のアイデンティティ証明書を選ぶかもしれないネットワークではなく、ルータの公開鍵を署名しているRouter Advertisementsに供給するルータでそれ自体です。
If there is no prefix information further up in the certification path, a host interprets a standard identity certificate as allowing unconstrained prefix advertisements.
証明経路でさらに上がっているどんな接頭語情報もなければ、ホストは自由な接頭語広告を許すと標準のアイデンティティ証明書を解釈します。
If the other certificates contain prefix information, a standard identity certificate is interpreted as allowing those subnet prefixes.
他の証明書が接頭語情報を含んでいるなら、標準のアイデンティティ証明書は、それらのサブネット接頭語を許容しながら、解釈されます。
6.4. Certificate Transport
6.4. 証明書輸送
The Certification Path Solicitation (CPS) message is sent by a host when it wishes to request a certification path between a router and one of the host's trust anchors. The Certification Path Advertisement (CPA) message is sent in reply to the CPS message. These messages are kept separate from the rest of Neighbor and Router Discovery to reduce the effect of the potentially voluminous certification path information on other messages.
それがホストの信頼アンカーのルータとひとりの間の証明経路を要求したがっているとき、Certification Path Solicitation(CPS)メッセージはホストによって送られます。 CPSメッセージに対してCertification Path Advertisement(CPA)メッセージを送ります。 これらのメッセージは、潜在的に多量の証明経路情報の他のメッセージへの効果を減少させるためにNeighborとRouterディスカバリーの残りから別々に保たれます。
The Authorization Delegation Discovery (ADD) process does not exclude other forms of discovering certification paths. For instance, during fast movements, mobile nodes may learn information (including the certification paths) about the next router from a previous router, or nodes may be preconfigured with certification paths from roaming partners.
ディスカバリー(ADD)プロセスが証明経路を発見しながら他のフォームを遮断しないAuthorization Delegation。 例えば、速い運動の間、モバイルノードが次のルータに関して前のルータから情報を学ぶかもしれませんか(証明経路を含んでいます)、またはノードは証明経路でローミングパートナーからあらかじめ設定されるかもしれません。
Where hosts themselves are certified by a trust anchor, these messages MAY also optionally be used between hosts to acquire the peer's certification path. However, the details of such usage are beyond the scope of this specification.
また、ホスト自身が信頼アンカーによって公認されるところでは、これらのメッセージは、同輩の証明経路を取得するのにホストの間で任意に使用されるかもしれません。 しかしながら、そのような用法の詳細はこの仕様の範囲を超えています。
Arkko, et al. Standards Track [Page 29] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[29ページ]RFC3971
6.4.1. Certification Path Solicitation Message Format
6.4.1. 証明経路懇願メッセージ・フォーマット
Hosts send Certification Path Solicitations in order to prompt routers to generate Certification Path Advertisements.
ホストは、ルータがCertification Path Advertisementsを生成するようにうながすためにCertification Path Solicitationsを送ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| コンポーネント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IP分野:
Source Address
ソースアドレス
A link-local unicast address assigned to the sending interface,
or to the unspecified address if no address is assigned to the
sending interface.
アドレスがアドレスでないなら送付インタフェース、または、不特定のアドレスに割り当てたリンク地方のユニキャストは送付インタフェースに割り当てられます。
Destination Address
送付先アドレス
Typically the All-Routers multicast address, the Solicited-Node
multicast address, or the address of the host's default router.
通常All-ルータマルチキャストアドレス、Solicited-ノードマルチキャストアドレス、またはホストのデフォルトルータのアドレス。
Hop Limit
ホップ限界
255
255
ICMP Fields:
ICMP分野:
Type
タイプ
148
148
Code
コード
0
0
Checksum
チェックサム
The ICMP checksum [6].
ICMPチェックサム[6]。
Arkko, et al. Standards Track [Page 30] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[30ページ]RFC3971
Identifier
識別子
A 16-bit unsigned integer field, acting as an identifier to
help match advertisements to solicitations. The Identifier
field MUST NOT be zero, and its value SHOULD be randomly
generated. This randomness does not have to be
cryptographically hard, as its purpose is only to avoid
collisions.
広告を懇願に合わせるのを助けるために識別子として機能する16ビットの符号のない整数分野。 Identifier分野はゼロであるはずがありません、そして、値のSHOULDは手当たりしだいにゼロです。生成されます。 この偶発性が暗号でそうである必要はない、困難である、単に衝突を避けるように目的がことである。
Component
コンポーネント
This 16-bit unsigned integer field is set to 65,535 if the
sender seeks to retrieve all certificates. Otherwise, it is
set to the component identifier corresponding to the
certificate that the receiver wants to retrieve (see Sections
6.4.2 and 6.4.6).
送付者がすべての証明書を検索しようとするなら、この16ビットの符号のない整数分野は6万5535に設定されます。 セクション6.4.2と6.4を見てください。さもなければ、それが受信機が検索したがっている証明書に対応するコンポーネント識別子に設定される、(.6)。
Valid Options:
妥当な選択肢:
Trust Anchor
信頼アンカー
One or more trust anchors that the client is willing to accept.
The first (or only) Trust Anchor option MUST contain a DER
Encoded X.501 Name; see Section 6.4.3. If there is more than
one Trust Anchor option, the options beyond the first may
contain any type of trust anchor.
ものか以上がクライアントが受け入れても構わないと思っているアンカーを信じます。 最初(単に)の信頼AnchorオプションはDER Encoded X.501 Nameを含まなければなりません。 セクション6.4.3を見てください。 1つ以上のTrust Anchorオプションがあれば、1番目を超えたオプションはどんなタイプの信頼アンカーも含むかもしれません。
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize
and continue processing the message. All included options MUST
have a length greater than zero.
このプロトコルの将来のバージョンは新しいオプションタイプを定義するかもしれません。 受信機は、静かに彼らが認識しない少しのオプションも無視して、メッセージを処理し続けなければなりません。 すべての含まれているオプションには、ゼロ以上の長さがなければなりません。
ICMP length (derived from the IP length) MUST be 8 or more octets.
ICMPの長さ(IPの長さから、派生する)は8つ以上の八重奏であるに違いありません。
Arkko, et al. Standards Track [Page 31] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[31ページ]RFC3971
6.4.2. Certification Path Advertisement Message Format
6.4.2. 証明経路広告メッセージ・フォーマット
Routers send out Certification Path Advertisement messages in response to a Certification Path Solicitation.
ルータはCertification Path Solicitationに対応してCertification Path Advertisementメッセージを出します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | All Components |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| すべてのコンポーネント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コンポーネント| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IP分野:
Source Address
ソースアドレス
A link-local unicast address assigned to the interface from
which this message is sent. Note that routers may use multiple
addresses, and therefore this address is not sufficient for the
unique identification of routers.
このメッセージが送られるインタフェースに割り当てられたリンクローカルのユニキャストアドレス。 ルータが複数のアドレスを使用するかもしれなくて、したがって、このアドレスがルータのユニークな識別に十分でないことに注意してください。
Destination Address
送付先アドレス
Either the Solicited-Node multicast address of the receiver or
the link-scoped All-Nodes multicast address.
受信機のSolicited-ノードマルチキャストアドレスかリンクで見られたAll-ノードマルチキャストアドレスのどちらか。
Hop Limit
ホップ限界
255
255
ICMP Fields:
ICMP分野:
Type
タイプ
149
149
Code
コード
0
0
Checksum
チェックサム
The ICMP checksum [6].
ICMPチェックサム[6]。
Arkko, et al. Standards Track [Page 32] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[32ページ]RFC3971
Identifier
識別子
A 16-bit unsigned integer field, acting as an identifier to
help match advertisements to solicitations. The Identifier
field MUST be zero for advertisements sent to the All-Nodes
multicast address and MUST NOT be zero for others.
広告を懇願に合わせるのを助けるために識別子として機能する16ビットの符号のない整数分野。 Identifier分野は、All-ノードマルチキャストアドレスに送られた広告のためのゼロでなければならなく、他のもののためのゼロであるはずがありません。
All Components
すべてのコンポーネント
A 16-bit unsigned integer field, used to inform the receiver of
the number of certificates in the entire path.
全体の経路の証明書の数の受信機を知らせるのにおいて中古の16ビットの符号のない整数分野。
A single advertisement SHOULD be broken into separately sent
components if there is more than one certificate in the path,
in order to avoid excessive fragmentation at the IP layer.
1通以上の証明書が経路にあれば別々に送られたコンポーネントがただ一つの広告SHOULDに細かく分けられて、IPで過度の断片化を避けるために層にしてください。
Individual certificates in a path MAY be stored and used as
received before all the certificates have arrived; this makes
the protocol slightly more reliable and less prone to Denial-
of-Service attacks.
経路の個々の証明書は、すべての証明書が届く前に受け取るように保存されていて使用されているかもしれません。 これで、サービスのDenial攻撃にわずかに信頼できてそれほどプロトコルを傾向がありません。
Examples of packet lengths of Certification Path Advertisement
messages for typical certification paths are listed in Appendix
C.
典型的な証明経路へのCertification Path Advertisementメッセージのパケット長に関する例はAppendix Cにリストアップされています。
Component
コンポーネント
A 16-bit unsigned integer field, used to inform the receiver
which certificate is being sent.
どの証明書が送られるかを受信機に知らせるのに使用される16ビットの符号のない整数分野。
The first message in an N-component advertisement has the
Component field set to N-1, the second set to N-2, and so on.
A zero indicates that there are no more components coming in
this advertisement.
N-コンポーネント広告における最初のメッセージで、N-1、N-2への2番目のセットなどにComponent分野を設定します。 ゼロは、この広告に入るそれ以上のコンポーネントが全くないのを示します。
The sending of path components SHOULD be ordered so that the
certificate after the trust anchor is sent first. Each
certificate sent after the first can be verified with the
previously sent certificates. The certificate of the sender
comes last. The trust anchor certificate SHOULD NOT be sent.
経路コンポーネントSHOULDを発信させて、信頼が投錨された後に最初に証明書を送るように注文してください。 以前に送られた証明書で1番目について確かめられたことができた後に各証明書は発信しました。 送付者の証明書は最後に来ます。 信頼アンカーはSHOULD NOTを証明します。送ります。
Reserved
予約されます。
An unused field. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver.
未使用の分野。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Arkko, et al. Standards Track [Page 33] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[33ページ]RFC3971
Valid Options:
妥当な選択肢:
Certificate
証明書
One certificate is provided in each Certificate option to
establish part of a certification path to a trust anchor.
証明経路の一部を信頼アンカーに証明するためにそれぞれのCertificateオプションに1通の証明書を提供します。
The certificate of the trust anchor itself SHOULD NOT be sent.
信頼の証明書自体はSHOULD NOTを据えつけます。送ります。
Trust Anchor
信頼アンカー
Zero or more Trust Anchor options may be included to help
receivers decide which advertisements are useful for them. If
present, these options MUST appear in the first component of a
multi-component advertisement.
ゼロか、より多くのTrust Anchorオプションが、受信機が、どの広告がそれらの役に立つかを決めるのを助けるために含まれるかもしれません。 存在しているなら、これらのオプションは多成分系の広告の最初のコンポーネントに現れなければなりません。
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize
and continue processing the message. All included options MUST
have a length that is greater than zero.
このプロトコルの将来のバージョンは新しいオプションタイプを定義するかもしれません。 受信機は、静かに彼らが認識しない少しのオプションも無視して、メッセージを処理し続けなければなりません。 すべての含まれているオプションには、ゼロ以上である長さがなければなりません。
The ICMP length (derived from the IP length) MUST be 8 or more
octets.
ICMPの長さ(IPの長さから、派生する)は8つ以上の八重奏であるに違いありません。
6.4.3. Trust Anchor Option
6.4.3. 信頼アンカーオプション
The format of the Trust Anchor option is described in the following:
Trust Anchorオプションの形式は以下で説明されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 名前タイプ| パッドの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 命名します。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
15
15
Length
長さ
The length of the option (including the Type, Length, Name Type,
Pad Length, and Name fields), in units of 8 octets.
8つの八重奏のユニットのオプション(Type、Length、Name Type、Pad Length、およびName分野を含んでいる)の長さ。
Arkko, et al. Standards Track [Page 34] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[34ページ]RFC3971
Name Type
名前タイプ
The type of the name included in the Name field. This
specification defines two legal values for this field:
Name分野に名前のタイプを含んでいます。 この仕様は2つの正当な値をこの分野と定義します:
1 DER Encoded X.501 Name
2 FQDN
1 DERはX.501名2のFQDNをコード化しました。
Pad Length
パッドの長さ
The number of padding octets beyond the end of the Name field but
within the length specified by the Length field. Padding octets
MUST be set to zero by senders and ignored by receivers.
しかしNameの端の八重奏が長さの中でさばく詰め物の数はLength分野のそばで指定しました。 八重奏を水増しするのを送付者によってゼロに設定されて、受信機で無視しなければなりません。
Name
名前
When the Name Type field is set to 1, the Name field contains a
DER encoded X.501 Name identifying the trust anchor. The value is
encoded as defined in [12] and [7].
いつName Type分野が1へのセット、Name分野がDERを含んでいるということであるかは信頼アンカーを特定するX.501 Nameをコード化しました。 値は[12]と[7]で定義されるようにコード化されます。
When the Name Type field is set to 2, the Name field contains a
Fully Qualified Domain Name of the trust anchor; for example,
"trustanchor.example.com". The name is stored as a string, in the
DNS wire format, as specified in RFC 1034 [1]. Additionally, the
restrictions discussed in RFC 3280 [7], Section 4.2.1.7 apply.
Name Type分野が2に設定されるとき、Name分野は信頼アンカーのFully Qualified Domain Nameを含んでいます。 例えば、"trustanchor.example.com"。 名前はRFC1034[1]の指定されるとしてのDNSワイヤ形式でストリングとして保存されます。 さらに、制限はRFCで3280[7]、.7が適用するセクション4.2.1について議論しました。
In the FQDN case, the Name field is an "IDN-unaware domain name
slot", as defined in [9]. That is, it can contain only ASCII
characters. An implementation MAY support internationalized
domain names (IDNs) using the ToASCII operation; see [9] for more
information.
FQDN場合では、Name分野は[9]で定義されるように「IDN気づかないドメイン名スロット」です。 すなわち、それはASCII文字しか含むことができません。 ToASCII操作を使用して、実装は、国際化ドメイン名が(IDNs)であるとサポートするかもしれません。 詳しい情報のための[9]を見てください。
All systems MUST support the DER Encoded X.501 Name.
Implementations MAY support the FQDN name type.
すべてのシステムがDER Encoded X.501 Nameをサポートしなければなりません。 実装はタイプというFQDN名をサポートするかもしれません。
Padding
詰め物
A variable-length field making the option length a multiple of 8,
beginning after the previous field ends and continuing to the end
of the option, as specified by the Length field.
オプションの長さをLength分野のそばの8と前の分野が終わった後に始まって、指定されるとしてオプションの終わりまで続く倍数にする可変長の分野。
Arkko, et al. Standards Track [Page 35] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[35ページ]RFC3971
6.4.4. Certificate Option
6.4.4. 証明書オプション
The format of the certificate option is described in the following:
証明書オプションの形式は以下で説明されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Cert Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 本命タイプ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 証明します。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
16
16
Length
長さ
The length of the option (including the Type, Length, Cert Type,
Pad Length, and Certificate fields), in units of 8 octets.
8つの八重奏のユニットのオプション(Type、Length、Cert Type、Pad Length、およびCertificate分野を含んでいる)の長さ。
Cert Type
本命タイプ
The type of the certificate included in the Certificate field.
This specification defines only one legal value for this field:
Certificate分野に証明書のタイプを含んでいます。 この仕様は1つの正当な値だけをこの分野と定義します:
1 X.509v3 Certificate, as specified below
1 以下で指定されるとしてのX.509v3 Certificate
Reserved
予約されます。
An 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.
今後の使用のために予約された8ビットの分野。 値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Certificate
証明書
When the Cert Type field is set to 1, the Certificate field
contains an X.509v3 certificate [7], as described in Section
6.3.1.
Cert Type分野が1に設定されるとき、Certificate分野はX.509v3証明書[7]を含んでいます、セクション6.3.1で説明されるように。
Padding
詰め物
A variable length field making the option length a multiple of 8,
beginning after the ASN.1 encoding of the previous field [7, 15]
ends and continuing to the end of the option, as specified by the
Length field.
オプションの長さをLength分野のそばの8と前の分野[7、15]のASN.1コード化が終わった後に始まって、指定されるとしてオプションの終わりまで続く倍数にする可変長フィールド。
Arkko, et al. Standards Track [Page 36] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[36ページ]RFC3971
6.4.5. Processing Rules for Routers
6.4.5. ルータのための処理規則
A router MUST silently discard any received Certification Path Solicitation messages that do not conform to the message format defined in Section 6.4.1. The contents of the Reserved field and of any unrecognized options MUST be ignored. Future, backward- compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values. The contents of any defined options that are not specified to be used with Router Solicitation messages MUST be ignored, and the packet processed in the normal manner. The only defined option that may appear is the Trust Anchor option. A solicitation that passes the validity checks is called a "valid solicitation".
ルータは静かにセクション6.4.1で定義されたメッセージ・フォーマットに従わないどんな受信されたCertification Path Solicitationメッセージも捨てなければなりません。 Reserved分野とどんな認識されていないオプションのコンテンツも無視しなければなりません。 プロトコルへの将来的で、後方のコンパチブル変化は、Reserved分野のコンテンツを指定するか、または新しいオプションを加えるかもしれません。 後方の非互換な変化は異なったCode値を使用するかもしれません。 Router Solicitationメッセージと共に使用されるために指定されない少しの定義されたオプションのコンテンツも無視しなければなりませんでした、そして、パケットは正常な方法で処理されました。 現れるかもしれない唯一の定義されたオプションがTrust Anchorオプションです。 バリディティチェックを通過する懇願は「有効な懇願」と呼ばれます。
Routers SHOULD send advertisements in response to valid solicitations received on an advertising interface. If the source address in the solicitation was the unspecified address, the router MUST send the response to the link-scoped All-Nodes multicast address. If the source address was a unicast address, the router MUST send the response to the Solicited-Node multicast address corresponding to the source address, except when under load, as specified below. Routers SHOULD NOT send Certification Path Advertisements more than MAX_CPA_RATE times within a second. When there are more solicitations, the router SHOULD send the response to the All-Nodes multicast address regardless of the source address that appeared in the solicitation.
ルータSHOULDは広告インタフェースで受けられた有効な懇願に対応して広告を送ります。 懇願におけるソースアドレスが不特定のアドレスであったなら、ルータはリンクで見られたAll-ノードマルチキャストアドレスに応答を送らなければなりません。 ソースアドレスがユニキャストアドレスであったなら、ルータはいつを除いて、負荷の下でソースアドレスに対応するSolicited-ノードマルチキャストアドレスへの応答を送らなければならないか、以下で指定されるとして。 ルータSHOULD NOTは1秒以内にマックス_CPA_RATE回数よりCertification Path Advertisementsを送ります。 より多くの懇願があるとき、ルータSHOULDは懇願に現れたソースアドレスにかかわらずAll-ノードマルチキャストアドレスに応答を送ります。
In an advertisement, the router SHOULD include suitable Certificate options so that a certification path can be established to the solicited trust anchor (or a part of it, if the Component field in the solicitation is not equal to 65,535). Note also that a single advertisement is broken into separately sent components and ordered in a particular way (see Section 6.4.2) when there is more than one certificate in the path.
広告では、ルータSHOULDは、請求された信頼アンカーに証明経路を確立できる(それの一部であり、懇願における分野はComponentであるなら6万5535と等しくない)ように適当なCertificateオプションを含んでいます。 また、1通以上の証明書が経路にあるとき、ただ一つの広告が特定の方法(セクション6.4.2を見る)で別々に送られたコンポーネントが細かく分けられて、命令されることに注意してください。
The anchor is identified by the Trust Anchor option. If the Trust Anchor option is represented as a DER Encoded X.501 Name, then the Name must be equal to the Subject field in the anchor's certificate. If the Trust Anchor option is represented as an FQDN, the FQDN must be equal to an FQDN in the subjectAltName field of the anchor's certificate. The router SHOULD include the Trust Anchor option(s) in the advertisement for which the certification path was found.
アンカーはTrust Anchorオプションで特定されます。 Trust AnchorオプションがDER Encoded X.501 Nameとして表されるなら、Nameはアンカーの証明書のSubject分野と等しいに違いありません。 Trust AnchorオプションがFQDNとして表されるなら、FQDNはアンカーの証明書のsubjectAltName分野のFQDNと等しいに違いありません。 ルータSHOULDは証明経路が見つけられた広告におけるTrust Anchorオプションを含んでいます。
If the router is unable to find a path to the requested anchor, it SHOULD send an advertisement without any certificates. In this case, the router SHOULD include the Trust Anchor options that were solicited.
ルータは要求されたアンカーにとって経路を見つけることができません、それ。SHOULDは少しも証明書なしで広告を送ります。 この場合、ルータSHOULDは請求されたTrust Anchorオプションを含んでいます。
Arkko, et al. Standards Track [Page 37] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[37ページ]RFC3971
6.4.6. Processing Rules for Hosts
6.4.6. ホストのための処理規則
A host MUST silently discard any received Certification Path Advertisement messages that do not conform to the message format defined in Section 6.4.2. The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward- compatible changes to the protocol MAY specify the contents of the Reserved field or add new options; backward-incompatible changes MUST use different Code values. The contents of any defined options not specified to be used with Certification Path Advertisement messages MUST be ignored, and the packet processed in the normal manner. The only defined options that may appear are the Certificate and Trust Anchor options. An advertisement that passes the validity checks is called a "valid advertisement".
ホストは静かにセクション6.4.2で定義されたメッセージ・フォーマットに従わないどんな受信されたCertification Path Advertisementメッセージも捨てなければなりません。 Reserved分野、およびどんな認識されていないオプションのコンテンツも無視しなければなりません。 プロトコルへの将来的で、後方のコンパチブル変化は、Reserved分野のコンテンツを指定するか、または新しいオプションを加えるかもしれません。 後方の非互換な変化は異なったCode値を使用しなければなりません。 Certification Path Advertisementメッセージと共に使用されるために指定されなかった少しの定義されたオプションのコンテンツも無視しなければなりませんでした、そして、パケットは正常な方法で処理されました。 現れるかもしれない唯一の定義されたオプションが、CertificateとTrust Anchorオプションです。 バリディティチェックを通過する広告は「有効な広告」と呼ばれます。
Hosts SHOULD store certification paths retrieved in Certification Path Discovery messages if they start from an anchor trusted by the host. The certification paths MUST be verified, as defined in Section 6.3, before storing them. Routers send the certificates one by one, starting from the trust anchor end of the path.
SHOULD店証明経路がそれらであるならCertification Pathディスカバリーメッセージで救済したホストはホストによって信じられたアンカーから始めます。 セクション6.3で定義されるそれらを保存する前に、証明経路について確かめなければなりません。 経路の信頼アンカー端から始めて、ルータは証明書をひとつずつ送ります。
Note: Except to allow for message loss and reordering for temporary purposes, hosts might not store certificates received in a Certification Path Advertisement unless they contain a certificate that can be immediately verified either to the trust anchor or to a certificate that has been verified earlier. This measure is intended to prevent Denial-of-Service attacks, whereby an attacker floods a host with certificates that the host cannot validate and overwhelms memory for certificate storage.
以下に注意してください。 メッセージの損失と一時的な目的のために再命令すると考慮する以外に、ホストは、より早くすぐに信頼アンカー、または、確かめられた証明書に確かめることができる証明書を含んでいないならCertification Path Advertisementに受け取られた証明書を保存しないかもしれません。 この測定はサービス不能攻撃を防ぐつもりです。(攻撃者は、ホストが有効にすることができない証明書でホストをあふれさせて、証明書ストレージのためにサービス不能攻撃でメモリを圧倒します)。
Note that caching this information, and the implied verification results between network attachments for use over multiple attachments to the network, can help improve performance. But periodic certificate revocation checks are still needed, even with cached results, to make sure that the certificates are still valid.
この情報、およびネットワークへの複数の付属の上の使用に関するネットワーク付属の間の暗示している検証結果をキャッシュするのが、性能を向上させるのを助けることができることに注意してください。 しかし、周期的な証明書取消しチェックがまだ必要です、念のため、証明書がまだ有効であるというキャッシュされた結果があっても。
The host SHOULD retrieve a certification path when a Router Advertisement has been received with a public key that is not available from a certificate in the hosts' cache, or when there is no certification path to one of the host's trust anchors. In these situations, the host MAY send a Certification Path Solicitation message to retrieve the path. If there is no response within CPS_RETRY seconds, the message should be retried. The wait interval for each subsequent retransmission MUST exponentially increase, doubling each time. If there is no response after CPS_RETRY_MAX seconds, the host abandons the certification path retrieval process. If the host receives only a part of a certification path within CPS_RETRY_FRAGMENTS seconds of receiving the first part, it MAY in
ホストのキャッシュにおける証明書から利用可能でない公開鍵でRouter Advertisementを受け取ったか、またはホストの信頼アンカーのひとりには証明経路が全くないとき、ホストSHOULDは証明経路を検索します。 これらの状況で、ホストは経路を検索するCertification Path Solicitationメッセージを送るかもしれません。 応答が全くCPS_RETRY秒以内になければ、メッセージは再試行されるべきです。 その都度倍増する場合、それぞれのその後の「再-トランスミッション」のための待ち間隔は指数関数的に増加しなければなりません。 応答が全くCPS_RETRY_MAX秒以降なければ、ホストは証明経路検索過程を捨てます。 ホストがCPS_RETRY_FRAGMENTS秒以内の最初の部分を受け取る証明経路の一部だけを受け取るなら、それは中に受け取ります。
Arkko, et al. Standards Track [Page 38] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[38ページ]RFC3971
addition transmit a Certification Path Solicitation message with the Component field set to a value not equal to 65,535. This message can be retransmitted by using the same process as for the initial message. If there are multiple missing certificates, additional CPS messages can be sent after getting a response to first one. However, the complete retrieval process may last at most CPS_RETRY_MAX seconds.
追加はComponent分野セットで6万5535と等しくない値にCertification Path Solicitationメッセージを送ります。 初期のメッセージのように同じプロセスを使用することによって、このメッセージを再送できます。 複数のなくなった証明書があれば、最初に、1つへの応答を得た後に、追加CPSメッセージを送ることができます。 しかしながら、完全な検索過程はCPS_RETRY_MAX秒高々続くかもしれません。
Certification Path Solicitations SHOULD NOT be sent if the host has a currently valid certification path from a reachable router to a trust anchor.
証明Path Solicitations SHOULD、ホストに届いているルータから信頼アンカーまで現在有効な証明経路があるなら、送られないでください。
When soliciting certificates for a router, a host MUST send Certification Path Solicitations either to the All-Routers multicast address, if it has not selected a default router yet, or to the default router's IP address, if a default router has already been selected.
ルータのための証明書に請求するとき、ホストはAll-ルータマルチキャストアドレスにCertification Path Solicitationsを送らなければなりません、まだかデフォルトルータのIPアドレスへのデフォルトルータを選択していないなら、デフォルトルータが既に選択されたなら。
If two hosts want to establish trust with the CPS and CPA messages, the CPS message SHOULD be sent to the Solicited-Node multicast address of the receiver. The advertisements SHOULD be sent as specified above for routers. However, the exact details are outside the scope of this specification.
2人のホストが信頼を確立したいなら、CPSとCPAメッセージ、CPSメッセージSHOULDと共に. 広告がマルチキャストが受信機を扱うSolicited-ノードSHOULDに送ってください。指定されるとして、ルータのために上に送ってください。 しかしながら、この仕様の範囲の外に正確な詳細があります。
When processing possible advertisements sent as responses to a solicitation, the host MAY prefer to process those advertisements with the same Identifier field value as that of the solicitation first. This makes Denial-of-Service attacks against the mechanism harder (see Section 9.3).
懇願への応答として送られた可能な広告を処理するとき、ホストは、最初に懇願のものと同じIdentifier分野価値でそれらの広告を処理するのを好むかもしれません。 これで、メカニズムに対するサービス不能攻撃は、より困難になります(セクション9.3を見てください)。
6.5. Configuration
6.5. 構成
End hosts are configured with a set of trust anchors in order to protect Router Discovery. A trust anchor configuration consists of the following items:
終わりのホストは、Routerディスカバリーを保護するために1セットの信頼アンカーに構成されます。 信頼アンカー構成は以下の項目から成ります:
o A public key signature algorithm and associated public key, which
may optionally include parameters.
o 公開鍵署名アルゴリズムと関連公開鍵。(その公開鍵は任意にパラメタを含むかもしれません)。
o A name as described in Section 6.4.3.
o セクション6.4.3で説明される名前。
o An optional public key identifier.
o 任意の公開鍵識別子。
o An optional list of address ranges for which the trust anchor is
authorized.
o 信頼が投錨されるアドレスの範囲の任意のリストは認可されています。
If the host has been configured to use SEND, it SHOULD possess the above information for at least one trust anchor.
ホストはSENDを使用するのが構成されました、それ。SHOULDには、少なくとも1人の信頼アンカーへの上記の情報があります。
Arkko, et al. Standards Track [Page 39] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[39ページ]RFC3971
Routers are configured with a collection of certification paths and a collection of certificates containing certified keys, down to the key and certificate for the router itself. Certified keys are required for routers so that a certification path can be established between the router's certificate and the public key of a trust anchor.
ルータは公認されたキーを含んでいる証明経路の収集と証明書の収集によって構成されます、ルータ自体のためのキーと証明書まで。 ルータの証明書と信頼アンカーの公開鍵の間で証明経路を確立できて、公認されたキーがルータに必要です。
If the router has been configured to use SEND, it should be configured with its own key pair and certificate, and with at least one certification path.
ルータがSENDを使用するために構成されたなら、それはそれ自身の主要な組と証明書、および少なくとも1つの証明経路によって構成されるべきです。
7. Addressing
7. アドレシング
7.1. CGAs
7.1. CGAs
By default, a SEND-enabled node SHOULD use only CGAs for its own addresses. Other types of addresses MAY be used in testing, in diagnostics, or for other purposes. However, this document does not describe how to choose between different types of addresses for different communications. A dynamic selection can be provided by an API, such as the one defined in [21].
デフォルトで、SENDによって可能にされたノードSHOULDはそれ自身のアドレスにCGAsだけを使用します。 他のタイプのアドレスは病気の特徴でテストするか、他の目的に使用されるかもしれません。 しかしながら、このドキュメントは異なったコミュニケーションのための異なったタイプのアドレスを選ぶ方法を説明しません。 [21]で定義されたものなどのAPIはダイナミックな選択を提供できます。
7.2. Redirect Addresses
7.2. アドレスを転送してください。
If the Target Address and Destination Address fields in the ICMP Redirect message are equal, then this message is used to inform hosts that a destination is, in fact, a neighbor. In this case, the receiver MUST verify that the given address falls within the range defined by the router's certificate. Redirect messages failing this check MUST be treated as unsecured, as described in Section 7.3.
ICMP RedirectメッセージのTarget AddressとDestination Address分野が等しいなら、このメッセージは、事実上、目的地が隣人であることをホストに知らせるのに使用されます。 この場合、受信機は、与えられたアドレスがルータの証明書によって定義された範囲の中に下がることを確かめなければなりません。 このチェックに失敗するのを扱わなければならない再直接のメッセージはセクション7.3で説明されるように非機密保護しました。
Note that base NDP rules prevent a host from accepting a Redirect message from a router that the host is not using to reach the destination mentioned in the redirect. This prevents an attacker from tricking a node into redirecting traffic when the attacker is not the default router.
ホストがベースNDP規則によってホストが再直接で言及された目的地に達するのに使用していないルータからRedirectメッセージを受け入れることができないことに注意してください。 これによって、攻撃者は、攻撃者がデフォルトルータでないときに、ノードがトラフィックを向け直すようにだますことができません。
7.3. Advertised Subnet Prefixes
7.3. 広告を出しているサブネット接頭語
The router's certificate defines the address range(s) that it is allowed to advertise securely. A router MAY, however, advertise a combination of certified and uncertified subnet prefixes. Uncertified subnet prefixes are treated as unsecured (i.e., processed in the same way as unsecured router advertisements sent by non-SEND routers). The processing of unsecured messages is specified in Section 8. Note that SEND nodes that do not attempt to interoperate with non-SEND nodes MAY simply discard the unsecured information.
ルータの証明書はそれがしっかりと広告を出すことができるアドレスの範囲を定義します。 しかしながら、ルータは公認されて非公認されたサブネット接頭語の組み合わせの広告を出すかもしれません。 Uncertifiedサブネット接頭語は非機密保護されるように(すなわち、非機密保護されるのと同様に、非SENDルータによって送られたルータ通知を処理します)扱われます。 非機密保護しているメッセージの処理はセクション8で指定されます。 非SENDノードで共同利用するのを試みないSENDノードが単に非機密保護している情報を捨てるかもしれないことに注意してください。
Arkko, et al. Standards Track [Page 40] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[40ページ]RFC3971
Certified subnet prefixes fall into the following two categories:
公認されたサブネット接頭語は以下の2つのカテゴリになります:
Constrained
抑制されます。
If the network operator wants to constrain which routers are
allowed to route particular subnet prefixes, routers should be
configured with certificates having subnet prefixes listed in the
prefix extension. These routers SHOULD advertise the subnet
prefixes that they are certified to route, or a subset thereof.
どのルータを抑制するかネットワーク・オペレータ必需品が特定のサブネット接頭語を発送できるなら、ルータは接頭語拡大で記載されたサブネット接頭語を持っている証明書によって構成されるべきです。 それらがサブネット接頭語ですが、それのルート、または部分集合に公認されて、SHOULDが広告を出すこれらのルータ。
Unconstrained
自由
Network operators that do not want to constrain routers this way
should configure routers with certificates containing either the
null prefix or no prefix extension at all.
このようにルータを抑制したがっていないネットワーク・オペレータはどんなヌル接頭語も接頭語拡大もどちらかの全く含んでいない証明書でルータを構成するべきです。
Upon processing a Prefix Information option within a Router Advertisement, nodes SHOULD verify that the prefix specified in this option falls within the range defined by the certificate, if the certificate contains a prefix extension. Options failing this check are treated as containing uncertified subnet prefixes.
Router Advertisementの中でPrefix情報オプションを処理すると、ノードSHOULDは、このオプションで指定された接頭語が証明書によって定義された範囲の中に下がることを確かめます、証明書が接頭語拡大を含んでいるなら。 このチェックに失敗するオプションが非公認されたサブネット接頭語を含むとして扱われます。
Nodes SHOULD use one of the certified subnet prefixes for stateless autoconfiguration. If none of the advertised subnet prefixes match, the host SHOULD use a different advertising router as its default router, if one is available. If the node is performing stateful autoconfiguration, it SHOULD check the address provided by the DHCP server against the certified subnet prefixes and SHOULD NOT use the address if the prefix is not certified.
ノードSHOULDは状態がない自動構成に公認されたサブネット接頭語の1つを使用します。 広告を出しているサブネット接頭語のいずれも合っていないなら、ホストSHOULDはデフォルトルータとして異なった広告ルータを使用します、1つが利用可能であるなら。 接頭語が公認されないなら、ノードが実行が自動構成をstatefulして、それがアドレスがDHCPサーバで公認されたサブネット接頭語に対して提供したSHOULDチェックであるということであるか、そして、SHOULD NOTはアドレスを使用します。
7.4. Limitations
7.4. 制限
This specification does not address the protection of NDP packets for nodes configured with a static address (e.g., PREFIX::1). Future certification path-based authorization specifications are needed for these nodes. This specification also does not apply to addresses generated by the IPv6 stateless address autoconfiguration from a fixed interface identifiers (such as EUI-64).
この仕様は静的なアドレス(例えば、PREFIX: : 1)によって構成されたノードのためにNDPパケットの保護を扱いません。 将来の証明経路ベースの承認仕様がこれらのノードに必要です。 この仕様もIPv6の状態がないアドレス自動構成によって固定インタフェース識別子(EUI-64などの)から作られたアドレスに適用されません。
It is outside the scope of this specification to describe the use of trust anchor authorization between nodes with dynamically changing addresses. These addresses may be the result of stateful or stateless address autoconfiguration, or may have resulted from the use of RFC 3041 [17] addresses. If the CGA method is not used, nodes are required to exchange certification paths that terminate in a certificate authorizing a node to use an IP address having a particular interface identifier. This specification does not specify the format of these certificates, as there are currently only a few
ダイナミックにアドレスを変えるのにノードの間の信頼アンカー承認の使用について説明するために、この仕様の範囲の外にそれはあります。 これらのアドレスは、statefulであるか状態がないアドレス自動構成の結果であったかもしれない、またはRFC3041[17]アドレスの使用から生じたかもしれません。 CGAメソッドが使用されていないなら、ノードはノードが特定のインタフェース識別子を持っているIPアドレスを使用するのを認可しながら証明書で終わる証明経路を交換しなければなりません。 現在、ほんのいくつかがあるとき、この仕様はこれらの証明書の形式を指定しません。
Arkko, et al. Standards Track [Page 41] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[41ページ]RFC3971
cases where they are provided by the link layer, and it is up to the link layer to provide certification for the interface identifier. This may be the subject of a future specification. It is also outside the scope of this specification to describe how stateful address autoconfiguration works with the CGA method.
リンクレイヤのそばでそれらを提供して、それがリンク次第であるケースは、インタフェース識別子のための証明を提供するために層にされます。 これは将来の仕様の対象であるかもしれません。 statefulアドレス自動構成がCGAメソッドでどう働いているかを説明するために、この仕様の範囲の外にもそれはあります。
The Target Address in Neighbor Advertisement is required to be equal to the source address of the packet, except in proxy Neighbor Discovery, which is not supported by this specification.
Neighbor AdvertisementのTarget Addressがパケットのソースアドレスと等しいのが必要です、プロキシNeighborディスカバリーを除いて。(それは、この仕様でサポートされません)。
8. Transition Issues
8. 変遷問題
During the transition to secured links, or as a policy consideration, network operators may want to run a particular link with a mixture of nodes accepting secured and unsecured messages. Nodes that support SEND SHOULD support the use of secured and unsecured NDP messages at the same time.
機密保護しているリンクへの変遷、または、方針の考慮、オペレータが経営したがっているかもしれないネットワークとして、受け入れるノードの混合物との特定のリンクは、メッセージを機密保護して、非機密保護しました。 SEND SHOULDを支えるノードが同時に、機密保護していて非機密保護しているNDPメッセージの使用を支えます。
In a mixed environment, SEND nodes receive both secured and unsecured messages but give priority to secured ones. Here, the "secured" messages are those that contain a valid signature option, as specified above, and "unsecured" messages are those that contain no signature option.
複雑な環境で、SENDノードは、機密保護しているものと同様に非機密保護しているメッセージを受け取りますが、機密保護しているものを最優先させます。 ここで、「機密保護している」メッセージは上で指定されるとして有効な署名オプションを含むものです、そして、"非機密保護する"のメッセージは署名オプションを全く含まないものです。
A SEND node SHOULD have a configuration option that causes it to ignore all unsecured Neighbor Solicitation and Advertisement, Router Solicitation and Advertisement, and Redirect messages. This can be used to enforce SEND-only networks. The default for this configuration option SHOULD be that both secured and unsecured messages are allowed.
SENDノードSHOULDには、それがすべてのunsecured Neighbor Solicitation、Advertisement、Router Solicitation、Advertisement、およびRedirectメッセージを無視する設定オプションがあります。 SENDだけネットワークを実施するのにこれを使用できます。 この設定オプションSHOULDがそんなに機密保護されて、メッセージを非機密保護したので、デフォルトは許容されています。
A SEND node MAY also have a configuration option whereby it disables the use of SEND completely, even for the messages it sends itself. This configuration option SHOULD be switched off by default; that is, SEND is used. Plain (non-SEND) NDP nodes will obviously send only unsecured messages. Per RFC 2461 [4], such nodes will ignore the unknown options and will treat secured messages in the same way that they treat unsecured ones. Secured and unsecured nodes share the same network resources, such as subnet prefixes and address spaces.
また、SENDノードには、それがSENDの使用を完全に無効にする設定オプションがあるかもしれません、それがそれ自体を送るメッセージのためにさえ。 この構成はSHOULDにゆだねます。デフォルトで消されてください。 すなわち、SENDは使用されています。 ノードが明らかに送る明瞭な(非SENDの)NDPはメッセージを非機密保護しただけです。 そのようなノードは、未知のオプションを無視して、RFC2461[4]単位で非機密保護しているものを扱うという同じように機密保護しているメッセージを扱うでしょう。 機密保護していて非機密保護しているノードはサブネット接頭語やアドレス空間などの同じネットワーク資源を共有します。
SEND nodes configured to use SEND at least in their own messages behave in a mixed environment as explained below.
少なくともそれら自身のメッセージでSENDを使用するために構成されたSENDノードは以下で説明されるように複雑な環境で振る舞います。
SEND adheres to the rules defined for the base NDP protocol, with the following exceptions:
SENDはベースNDPプロトコルのために以下の例外で定義された規則を固く守ります:
o All solicitations sent by a SEND node MUST be secured.
o SENDノードによって送られたすべての懇願を保証しなければなりません。
Arkko, et al. Standards Track [Page 42] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[42ページ]RFC3971
o Unsolicited advertisements sent by a SEND node MUST be secured.
o SENDノードによって送られた未承諾広告を保証しなければなりません。
o A SEND node MUST send a secured advertisement in response to a
secured solicitation. Advertisements sent in response to an
unsecured solicitation MUST be secured as well, but MUST NOT
contain the Nonce option.
o SENDノードは機密保護している懇願に対応して機密保護している広告を送らなければなりません。 非機密保護している懇願に対応して送られた広告は、また、機密保護しなければなりませんが、Nonceオプションを含んではいけません。
o A SEND node that uses the CGA authorization method to protect
Neighbor Solicitations SHOULD perform Duplicate Address Detection
as follows. If Duplicate Address Detection indicates that the
tentative address is already in use, the node generates a new
tentative CGA. If after three consecutive attempts no non-unique
address is generated, it logs a system error and gives up
attempting to generate an address for that interface.
o Neighbor Solicitations SHOULDを保護するCGA承認メソッドを使用するSENDノードは以下のDuplicate Address Detectionを実行します。 Duplicate Address Detectionが、一時的なアドレスが既に使用中であることを示すなら、ノードは新しい一時的なCGAを生成します。 どんな非ユニークなアドレスも3つの連続した試みの後に発生していないなら、それは、そのインタフェースにシステム・エラーを登録して、アドレスを作るのを試みるのをやめます。
When performing Duplicate Address Detection for the first
tentative address, the node accepts both secured and unsecured
Neighbor Advertisements and Solicitations received in response to
the Neighbor Solicitations. When performing Duplicate Address
Detection for the second or third tentative address, it ignores
unsecured Neighbor Advertisements and Solicitations. (The
security implications of this are discussed in Section 9.2.3 and
in [11].)
最初の一時的なアドレスのためにDuplicate Address Detectionを実行するとき、ノードは、両方が機密保護されると受け入れます、そして、unsecured Neighbor AdvertisementsとSolicitationsはNeighbor Solicitationsに対応して受信しました。 2番目か3番目の一時的なアドレスのためにDuplicate Address Detectionを実行するとき、それはunsecured Neighbor AdvertisementsとSolicitationsを無視します。 (セクション9.2.3と[11]でこのセキュリティ含意について議論します。)
o The node MAY have a configuration option whereby it ignores
unsecured advertisements, even when performing Duplicate Address
Detection for the first tentative address. This configuration
option SHOULD be disabled by default. This is a recovery
mechanism for cases in which attacks against the first address
become common.
o ノードには、最初の一時的なアドレスのためにDuplicate Address Detectionを実行さえするときそれが非機密保護している広告を無視する設定オプションがあるかもしれません。 この構成はSHOULDにゆだねます。デフォルトで障害があってください。 これは最初のアドレスに対する攻撃が一般的になる場合のための回収機構です。
o The Neighbor Cache, Prefix List, and Default Router list entries
MUST have a secured/unsecured flag that indicates whether the
message that caused the creation or last update of the entry was
secured or unsecured. Received unsecured messages MUST NOT cause
changes to existing secured entries in the Neighbor Cache, Prefix
List, or Default Router List. Received secured messages MUST
cause an update of the matching entries, which MUST be flagged as
secured.
o Neighbor Cache、Prefix List、およびDefault Routerリストエントリーには、エントリーの作成かアップデートを引き起こしたメッセージが機密保護されたか、または非機密保護されたかを示す機密保護しているか非機密保護している旗がなければなりません。 受信された非機密保護しているメッセージはNeighbor Cache、Prefix List、またはDefault Router Listでエントリーであると機密保護された存在への変化を引き起こしてはいけません。 受信された機密保護しているメッセージは合っているエントリーのアップデートを引き起こさなければなりません。(機密保護されるとしてエントリーに旗を揚げさせなければなりません)。
o Neighbor Solicitations for the purpose of Neighbor Unreachability
Detection (NUD) MUST be sent to that neighbor's solicited-nodes
multicast address if the entry is not secured with SEND.
o SENDと共にエントリーを確保しないなら、Neighbor Unreachability Detection(NUD)の目的のための隣人Solicitationsをその隣人の請求されたノードマルチキャストアドレスに送らなければなりません。
Upper layer confirmations on unsecured neighbor cache entries
SHOULD NOT update neighbor cache state from STALE to REACHABLE on
a SEND node if the neighbor cache entry has never previously been
REACHABLE. This ensures that if an entry spoofing a valid SEND
非機密保護している隣人キャッシュエントリーSHOULD NOTにおける上側の層の確認は以前に隣人キャッシュエントリーが一度もREACHABLEであったことがないならSENDノードでSTALEからREACHABLEまで隣人キャッシュ状態をアップデートします。 これは有効なSENDを偽造するエントリーであるならそれを確実にします。
Arkko, et al. Standards Track [Page 43] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[43ページ]RFC3971
host is created by a non-SEND attacker without being solicited,
NUD will be done with the entry for data transmission within five
seconds of use.
請求されないで、非SEND攻撃者はホストを創造して、データ伝送のためのエントリーで5秒以内に役に立った状態でNUDをするでしょう。
As a result, in mixed mode, attackers can take over a Neighbor
Cache entry of a SEND node for a longer time only if (a) the SEND
node was not communicating with the victim node, so that there is
no secure entry for it, and (b) the SEND node is not currently on
the link (or is unable to respond).
攻撃者がNeighbor Cacheエントリーの上でミックスト・モードで取ることができる結果として、より長い時間のSENDノードは(a) SENDノードである場合にだけ犠牲者ノードとコミュニケートしていませんでした、(b) それのためのどんな安全なエントリーもなくて、また現在、リンク(または、応じることができない)の上にSENDノードがないように。
o The conceptual sending algorithm is modified so that an unsecured
router is selected only if there is no reachable SEND router for
the prefix. That is, the algorithm for selecting a default router
favors reachable SEND routers over reachable non-SEND ones.
o 概念的な送付アルゴリズムが変更されているので、接頭語のためのどんな届いているSENDルータもない場合にだけ、非機密保護しているルータは選択されます。 すなわち、デフォルトルータを選択するためのアルゴリズムは届いている非SENDものより届いているSENDルータを好みます。
o A node MAY adopt a router sending unsecured messages, or a router
for which secured messages have been received but for which full
security checks have not yet been completed, while security
checking is underway. Security checks in this case include
certification path solicitation, certificate verification, CRL
checks, and RA signature checks. A node MAY also adopt a router
sending unsecured messages if a router known to be secured becomes
unreachable, but because the unreachability may be the result of
an attack it SHOULD attempt to find a router known to be secured
as soon as possible. Note that although this can speed up
attachment to a new network, accepting a router that is sending
unsecured messages or for which security checks are not complete
opens the node to possible attacks. Nodes that choose to accept
such routers do so at their own risk. The node SHOULD, in any
case, prefer a router known to be secure as soon as one is made
available with completed security checks.
o ノードは非機密保護しているメッセージを送るルータ、または機密保護しているメッセージが受け取られましたが、完全なセキュリティチェックがまだ終了していないルータを採用するかもしれません、セキュリティー検査は進行中ですが。 セキュリティチェックはこの場合証明経路懇願、証明書検証、CRLチェック、およびRA署名チェックを含んでいます。 また、機密保護されるのが知られているルータが手が届かなくなるなら、ノードは非機密保護しているメッセージを送るルータを採用するかもしれませんが、「非-可到達性」が攻撃の結果がそれであったなら試みるかもしれないので、SHOULDは、できるだけ早く機密保護されるのが知られているルータを見つけるのを試みます。 発信するルータを受け入れると、可能な攻撃にこれが新しいネットワークへの付属を早くできますが、メッセージが非機密保護したか、またはどのセキュリティチェックが完全でないかにノードが開くことに注意してください。 そのようなルータを受け入れるのを選ぶノードがそう自分の責任でします。 どのような場合でも、ノードSHOULDは1つを完成したセキュリティチェックで利用可能にするとすぐに、安全であることが知られているルータを好みます。
9. Security Considerations
9. セキュリティ問題
9.1. Threats to the Local Link Not Covered by SEND
9.1. カバーされなかった地方のリンクへの脅威は発信します。
SEND does not provide confidentiality for NDP communications.
SENDはNDPコミュニケーションに秘密性を提供しません。
SEND does not compensate for an unsecured link layer. For instance, there is no assurance that payload packets actually come from the same peer against which the NDP was run.
SENDは非機密保護しているリンクレイヤを補いません。 例えば、ペイロードパケットが実際にNDPが経営されていたのと同じ同輩から来るという保証が全くありません。
There may not be cryptographic binding in SEND between the link layer frame address and the IPv6 address. An unsecured link layer could allow nodes to spoof the link layer address of other nodes. An attacker could disrupt IP service by sending out a Neighbor Advertisement on an unsecured link layer, with the link layer source address on the frame set as the source address of a victim, a valid
リンクレイヤフレームアドレスとIPv6アドレスの間には、暗号の結合がSENDにないかもしれません。 非機密保護しているリンクレイヤで、ノードは、リンクレイヤが他のノードのアドレスであると偽造することができるかもしれません。 攻撃者は非機密保護しているリンクレイヤにNeighbor Advertisementを出すことによって、IPサービスを中断できるでしょう、犠牲者のソースアドレスとして設定されたフレームに関するリンクレイヤソースアドレスで、a有効です。
Arkko, et al. Standards Track [Page 44] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[44ページ]RFC3971
CGA address and a valid signature corresponding to itself, and a Target Link-layer Address extension corresponding to the victim. The attacker could then make a traffic stream bombard the victim in a DoS attack. This cannot be prevented just by securing the link layer.
CGAアドレス、それ自体に対応する有効な署名、および犠牲者にとって、対応するTarget Link-層のAddress拡張子。 そして、攻撃者はトラフィックストリームにDoS攻撃で犠牲者を砲撃させることができました。 リンクレイヤを固定するだけでこれを防ぐことができません。
Even on a secured link layer, SEND does not require that the addresses on the link layer and Neighbor Advertisements correspond. However, performing these checks is RECOMMENDED if the link layer technology permits.
機密保護しているリンクレイヤでさえ、SENDは、リンクレイヤとNeighbor Advertisementsに関するアドレスが一致しているのを必要としません。 しかしながら、リンクレイヤ技術が可能にするなら、これらのチェックを実行するのは、RECOMMENDEDです。
Prior to participating in Neighbor Discovery and Duplicate Address Detection, nodes must subscribe to the link-scoped All-Nodes Multicast Group and the Solicited-Node Multicast Group for the address that they are claiming as their addresses; RFC 2461 [4]. Subscribing to a multicast group requires that the nodes use MLD [16]. MLD contains no provision for security. An attacker could send an MLD Done message to unsubscribe a victim from the Solicited- Node Multicast address. However, the victim should be able to detect this attack because the router sends a Multicast-Address-Specific Query to determine whether any listeners are still on the address, at which point the victim can respond to avoid being dropped from the group. This technique will work if the router on the link has not been compromised. Other attacks using MLD are possible, but they primarily lead to extraneous (but not necessarily overwhelming) traffic.
NeighborディスカバリーとDuplicate Address Detectionに参加する前に、ノードは彼らが自分達のアドレスとして要求しているアドレスのためにリンクで見られたAll-ノードMulticast GroupとSolicited-ノードMulticast Groupに加入しなければなりません。 RFC2461[4]。 マルチキャストグループに加入するのは、ノードがMLD[16]を使用するのを必要とします。 MLDはセキュリティへの支給を全く含んでいません。 攻撃者はSolicitedノードMulticastアドレスから犠牲者を外すMLD Doneメッセージを送ることができました。 しかしながら、ルータが犠牲者がグループから下げられるのを避けるためにどのポイントを反応させることができるかでまだアドレスで何かリスナーがそうかどうか決定するためにMulticastアドレス詳細Queryを送るので、犠牲者はこの攻撃を検出できるべきです。 リンクの上のルータが感染されていないと、このテクニックは利くでしょう。 MLDを使用する他の攻撃は可能ですが、それらは主として異質で(必ず圧倒的であるというわけではない)のトラフィックに通じます。
9.2. How SEND Counters Threats to NDP
9.2. どのようにがNDPへの脅威をカウンタに送るか。
The SEND protocol is designed to counter the threats to NDP, as outlined in [22]. The following subsections contain a regression of the SEND protocol against the threats, to illustrate which aspects of the protocol counter each threat.
SENDプロトコルは、NDPへの脅威に対抗するように[22]に概説されているように設計されています。 以下の小区分は、プロトコルカウンタのそれの局面を例証するために脅威に対してSENDプロトコルの復帰を含んでいます。各脅威。
9.2.1. Neighbor Solicitation/Advertisement Spoofing
9.2.1. 隣人懇願/広告スプーフィング
This threat is defined in Section 4.1.1 of [22]. The threat is that a spoofed message may cause a false entry in a node's Neighbor Cache. There are two cases:
この脅威は[22]についてセクション4.1.1で定義されます。 脅威は偽造しているメッセージがノードのNeighbor Cacheで偽造記録を引き起こすかもしれないということです。 2つのケースがあります:
1. Entries made as a side effect of a Neighbor Solicitation or Router
Solicitation. A router receiving a Router Solicitation with a
Target Link-Layer Address extension and the IPv6 source address
unequal to the unspecified address inserts an entry for the IPv6
address into its Neighbor Cache. Also, a node performing
Duplicate Address Detection (DAD) that receives a Neighbor
Solicitation for the same address regards the situation as a
collision and ceases to solicit for the address.
1. Neighbor SolicitationかRouter Solicitationの副作用としてされたエントリー。 Target Link-層のAddress拡張子と不特定のアドレスに不平等なIPv6ソースアドレスでRouter Solicitationを受けるルータはIPv6アドレスのためのエントリーをNeighbor Cacheに挿入します。 また、同じアドレスのためにNeighbor Solicitationを受けるDuplicate Address Detection(DAD)を実行するノードは、状況を衝突と見なして、アドレスを請うのをやめます。
Arkko, et al. Standards Track [Page 45] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[45ページ]RFC3971
In either case, SEND counters these threats by requiring that the
RSA Signature and CGA options be present in these solicitations.
どちらの場合ではも、RSA SignatureとCGAオプションがこれらの懇願で存在しているのを必要とすることによって、SENDはこれらの脅威に対抗します。
SEND nodes can send Router Solicitation messages with a CGA source
address and a CGA option, which the router can verify, so that the
Neighbor Cache binding is correct. If a SEND node must send a
Router Solicitation with the unspecified address, the router will
not update its Neighbor Cache, as per base NDP.
SENDノードはCGAソースアドレスとCGAオプションと共にメッセージをRouter Solicitationに送ることができます、Neighbor Cache結合が正しいように。(ルータはオプションについて確かめることができます)。 SENDノードが不特定のアドレスがあるRouter Solicitationを送らなければならないと、ルータはNeighbor Cacheをアップデートしないでしょう、ベースNDPに従って。
2. Entries made as a result of a Neighbor Advertisement message.
SEND counters this threat by requiring that the RSA Signature and
CGA options be present in these advertisements.
2. Neighbor Advertisementメッセージの結果、されたエントリー。 RSA SignatureとCGAオプションがこれらの広告に存在しているのを必要とすることによって、SENDはこの脅威に対抗します。
Also see Section 9.2.5, below, for discussion about replay protection and timestamps.
また、以下で反復操作による保護とタイムスタンプについての議論に関してセクション9.2.5を見てください。
9.2.2. Neighbor Unreachability Detection Failure
9.2.2. 隣人Unreachability検出の故障
This attack is described in Section 4.1.2 of [22]. SEND counters it by requiring that a node responding to Neighbor Solicitations sent as NUD probes include an RSA Signature option and proof of authorization to use the interface identifier in the address being probed. If these prerequisites are not met, the node performing NUD discards the responses.
この攻撃は[22]についてセクション4.1.2で説明されます。 NUD徹底的調査が調べられるアドレスでインタフェース識別子を使用するためにRSA Signatureオプションと承認の証拠を含んでいるのでNeighbor Solicitationsに応じるノードが発信したのを必要とすることによって、SENDはそれを打ち返します。 これらの前提条件が満たされないなら、NUDを実行するノードは応答を捨てます。
9.2.3. Duplicate Address Detection DoS Attack
9.2.3. アドレス検出DoS攻撃をコピーしてください。
This attack is described in Section 4.1.3 of [22]. SEND counters this attack by requiring that the Neighbor Advertisements sent as responses to DAD include an RSA Signature option and proof of authorization to use the interface identifier in the address being tested. If these prerequisites are not met, the node performing DAD discards the responses.
この攻撃は[22]についてセクション4.1.3で説明されます。 DADへの応答がテストされるアドレスでインタフェース識別子を使用するためにRSA Signatureオプションと承認の証拠を含んでいるのでNeighbor Advertisementsが発信したのを必要とすることによって、SENDはこの攻撃に対抗します。 これらの前提条件が満たされないなら、DADを実行するノードは応答を捨てます。
When a SEND node performs DAD, it may listen for address collisions from non-SEND nodes for the first address it generates, but not for new attempts. This protects the SEND node from DAD DoS attacks by non-SEND nodes or attackers simulating non-SEND nodes, at the cost of a potential address collision between a SEND node and a non-SEND node. The probability and effects of such an address collision are discussed in [11].
SENDノードがDADを実行するとき、それは、それが作る最初のアドレスのための非SENDノードからアドレス衝突の聞こうとしますが、新しい試みのために聞こうとするかもしれないというわけではありません。 これは非SENDノードか非SENDノードをシミュレートする攻撃者によるDAD DoS攻撃からSENDノードと非SENDノードとの潜在的アドレス衝突の費用でSENDノードを保護します。 そのようなアドレス衝突の確率と効果は[11]で検討されます。
9.2.4. Router Solicitation and Advertisement Attacks
9.2.4. ルータ懇願と広告攻撃
These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6, and 4.2.7 of [22]. SEND counters them by requiring that Router Advertisements contain an RSA Signature option, and that the signature is calculated by using the public key of a node that can
そして、これらの攻撃が説明される、セクション4.2 .1 4.2 .4 4.2 .5 4.2 .6、4.2 .7 [22]について。 Router AdvertisementsがRSA Signatureオプションを含んでいて、署名がそうすることができるノードの公開鍵を使用することによって計算されるのを必要とすることによって、SENDはそれらを打ち返します。
Arkko, et al. Standards Track [Page 46] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[46ページ]RFC3971
prove its authorization to route the subnet prefixes contained in any Prefix Information Options. The router proves its authorization by showing a certificate containing the specific prefix or an indication that the router is allowed to route any prefix. A Router Advertisement without these protections is discarded.
承認がどんなPrefix情報Optionsにも含まれたサブネット接頭語を発送すると立証してください。 ルータがどんな接頭語も発送できるのを特定の接頭語か指示を含む証明書に示すことによって、ルータは承認を立証します。 これらの保護のないRouter Advertisementは捨てられます。
SEND does not protect against brute force attacks on the router, such as DoS attacks, or against compromise of the router, as described in Sections 4.4.2 and 4.4.3 of [22].
SENDはルータの上、または、DoS攻撃などか、ルータの感染に対してブルートフォースアタックから守りません、[22]についてセクション4.4.2と4.4で.3について説明するので。
9.2.5. Replay Attacks
9.2.5. 反射攻撃
This attack is described in Section 4.3.1 of [22]. SEND protects against attacks in Router Solicitation/Router Advertisement and Neighbor Solicitation/Neighbor Advertisement transactions by including a Nonce option in the solicitation and requiring that the advertisement include a matching option. Together with the signatures, this forms a challenge-response protocol.
この攻撃は[22]についてセクション4.3.1で説明されます。 懇願におけるNonceオプションを含んで、広告が合っているオプションを含んでいるのを必要とすることによって、SENDはRouter Solicitation/ルータAdvertisementでの攻撃とNeighbor Solicitation/隣人Advertisementトランザクションから守ります。 署名と共に、これはチャレンジレスポンスプロトコルを形成します。
SEND protects against attacks from unsolicited messages such as Neighbor Advertisements, Router Advertisements, and Redirects by including a Timestamp option. The following security issues are relevant only for unsolicited messages:
SENDは、Neighbor Advertisementsや、Router Advertisementsや、Redirectsなどのお節介なメッセージからTimestampオプションを含んでいることによって、攻撃から守ります。 お節介なメッセージだけにおいて、以下の安全保障問題は関連しています:
o A window of vulnerability for replay attacks exists until the
timestamp expires.
o タイムスタンプが期限が切れるまで、反射攻撃のための脆弱性の窓は存在しています。
However, such vulnerabilities are only useful for attackers if the
advertised parameters change during the window. Although some
parameters (such as the remaining lifetime of a prefix) change
often, radical changes typically happen only in the context of
some special case, such as switching to a new link layer address
due to a broken interface adapter.
しかしながら、広告を出しているパラメタが窓の間、変化するなら、そのような脆弱性は単に攻撃者の役に立ちます。 いくつかのパラメタ(接頭語の残っている生涯などの)がしばしば変化しますが、根本的な変更は何らかの特別なケースの文脈だけで通常起こります、壊れているインタフェースアダプターのため新しいリンクレイヤアドレスに切り替わるのなどように。
SEND nodes are also protected against replay attacks as long as
they cache the state created by the message containing the
timestamp. The cached state allows the node to protect itself
against replayed messages. However, once the node flushes the
state for whatever reason, an attacker can re-create the state by
replaying an old message while the timestamp is still valid.
Because most SEND nodes are likely to use fairly coarse-grained
timestamps, as explained in Section 5.3.1, this may affect some
nodes.
また、SENDノードは反射攻撃に対してタイムスタンプを含むメッセージによって創設された状態をキャッシュする限り、保護されます。 キャッシュされた州で、ノードは再演されたメッセージに対して我が身をかばうことができます。 しかしながら、ノードがいかなる理由でもいったん状態を洗い流すと、攻撃者は、タイムスタンプがまだ有効である間、古いメッセージを再演することによって、状態を作り直すことができます。 ほとんどのSENDノードがセクション5.3.1で説明されるように下品なタイムスタンプを公正に使用しそうであるので、これはいくつかのノードに影響するかもしれません。
o Attacks against time synchronization protocols such as NTP [23]
may cause SEND nodes to have an incorrect timestamp value. This
can be used to launch replay attacks, even outside the normal
window of vulnerability. To protect against these attacks, it is
o NTP[23]などの時間同期化プロトコルに対する攻撃で、SENDノードには、不正確なタイムスタンプ値があるかもしれません。 脆弱性の正常な窓の外でさえ反射攻撃を始めるのにこれを使用できます。 これらの攻撃から守るために、それはそうです。
Arkko, et al. Standards Track [Page 47] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[47ページ]RFC3971
recommended that SEND nodes keep independently maintained clocks
or apply suitable security measures for the time synchronization
protocols.
SENDノードが独自に維持された時計を保つか、または時間同期化プロトコルのために適当な安全策を当てはまることを勧めました。
9.2.6. Neighbor Discovery DoS Attack
9.2.6. 隣人発見DoS攻撃
This attack is described in Section 4.3.2 of [22]. In it, the attacker bombards the router with packets for fictitious addresses on the link, causing the router to busy itself by performing Neighbor Solicitations for addresses that do not exist. SEND does not address this threat because it can be addressed by techniques such as rate limiting Neighbor Solicitations, restricting the amount of state reserved for unresolved solicitations, and clever cache management. These are all techniques involved in implementing Neighbor Discovery on the router.
この攻撃は[22]についてセクション4.3.2で説明されます。 それでは、攻撃者はリンクに関する架空のアドレスのためにルータにパケットを砲撃します、ルータが存在しないアドレスのためにNeighbor Solicitationsを実行することによってそれ自体と忙しくすることを引き起こして。 SENDはNeighbor Solicitationsを制限するレートなどのテクニックでそれを扱うことができるので、この脅威を扱いません、未定の懇願、および賢明なキャッシュ管理のために予約された状態の量を制限して。 これらはすべてルータでNeighborがディスカバリーであると実装するのにかかわるテクニックです。
9.3. Attacks against SEND Itself
9.3. 攻撃はそれ自体を送ります。
The CGAs have a 59-bit hash value. The security of the CGA mechanism has been discussed in [11].
CGAsには、59ビットのハッシュ値があります。 [11]でCGAメカニズムのセキュリティについて議論しました。
Some Denial-of-Service attacks remain against NDP and SEND itself. For instance, an attacker may try to produce a very high number of packets that a victim host or router has to verify by using asymmetric methods. Although safeguards are required to prevent an excessive use of resources, this can still render SEND non- operational.
いくつかのサービス不能攻撃がNDPとSEND自身に対して残っています。 例えば、攻撃者は犠牲者ホストかルータが非対称のメソッドを使用することによって確かめなければならない非常に大きい数のパケットを作り出そうとするかもしれません。 安全装置はリソースの過用を防がなければなりませんが、これはまだSENDを非操作上にすることができます。
When CGA protection is used, SEND deals with the DoS attacks by using the verification process described in Section 5.2.2. In this process, a simple hash verification of the CGA property of the address is performed before the more expensive signature verification. However, even if the CGA verification succeeds, no claims about the validity of the message can be made until the signature has been checked.
CGA保護が使用されているとき、セクション5.2.2で説明された検証プロセスを使用することによって、SENDはDoS攻撃に対処します。 このプロセスでは、アドレスのCGAの特性の簡単なハッシュ検証は、より高価な署名照合の前に実行されます。 しかしながら、CGA検証が成功しても、署名がチェックされるまでメッセージの正当性に関するノークレームをすることができます。
When trust anchors and certificates are used for address validation in SEND, the defenses are not quite as effective. Implementations SHOULD track the resources devoted to the processing of packets received with the RSA Signature option and start selectively discarding packets if too many resources are spent. Implementations MAY also first discard packets that are not protected with CGA.
信頼アンカーと証明書がSENDでのアドレス合法化に使用されるとき、ディフェンスは全く同じくらい有効ではありません。 実装SHOULDはRSA Signatureオプションで受け取られたパケットの処理にささげられたリソースを追跡して、あまりに多くのリソースが費やされるなら、選択的にパケットを捨て始めます。 また、実装は最初に、CGAと共に保護されないパケットを捨てるかもしれません。
The Authorization Delegation Discovery process may also be vulnerable to Denial-of-Service attacks. An attack may target a router by requesting that a large number of certification paths be discovered for different trust anchors. Routers SHOULD defend against such attacks by caching discovered information (including negative
また、Authorization Delegationディスカバリープロセスもサービス不能攻撃に被害を受け易いかもしれません。 多くの証明経路が異なった信頼アンカーのために発見されるよう要求することによって、攻撃はルータを狙うかもしれません。 ルータSHOULDが発見された情報をキャッシュすることによってそのような攻撃に対して防御する、(包含否定的
Arkko, et al. Standards Track [Page 48] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[48ページ]RFC3971
responses) and by limiting the number of different discovery processes in which they engage.
応答) そして、制限するのによるそれらが従事する異なった発見プロセスの数。
Attackers may also target hosts by sending a large number of unnecessary certification paths, forcing hosts to spend useless memory and verification resources on them. Hosts can defend against such attacks by limiting the amount of resources devoted to the certification paths and their verification. Hosts SHOULD also prioritize advertisements sent as a response to solicitations the hosts have sent about unsolicited advertisements.
また、攻撃者は多くの不要な証明経路を送ることによって、ホストを狙うかもしれません、ホストに役に立たないメモリと検証リソースをそれらに費やさせて。 ホストは、証明経路と彼らの検証にささげられたリソースの量を制限することによって、そのような攻撃に対して防御できます。 また、ホストSHOULDはホストが未承諾広告に関して送った懇願への応答として送られた広告を最優先させます。
10. Protocol Values
10. プロトコル値
10.1. Constants
10.1. 定数
Host constants:
定数を接待してください:
CPS_RETRY 1 second
CPS_RETRY_FRAGMENTS 2 seconds
CPS_RETRY_MAX 15 seconds
15秒のCPS_RETRY1第2CPS_RETRY_FRAGMENTS2秒のCPS_RETRY_MAX
Router constants:
ルータ定数:
MAX_CPA_RATE 10 times per second
1秒に回のマックス_CPA_RATE10
10.2. Variables
10.2. 変数
TIMESTAMP_DELTA 300 seconds (5 minutes)
TIMESTAMP_FUZZ 1 second
TIMESTAMP_DRIFT 1 % (0.01)
TIMESTAMP_デルタ300秒(5分)TIMESTAMP_FUZZ1秒のTIMESTAMP_DRIFT1%(0.01)
11. IANA Considerations
11. IANA問題
This document defines two new ICMP message types, used in Authorization Delegation Discovery. These messages must be assigned ICMPv6 type numbers from the informational message range:
このドキュメントはAuthorization Delegationディスカバリーで使用される2つの新しいICMPメッセージタイプを定義します。 ICMPv6形式数を通報メッセージ範囲からこれらのメッセージに割り当てなければなりません:
o The Certification Path Solicitation message (148), described in
Section 6.4.1.
o セクション6.4.1で説明されたCertification Path Solicitationメッセージ(148)。
o The Certification Path Advertisement message (149), described in
Section 6.4.2.
o セクション6.4.2で説明されたCertification Path Advertisementメッセージ(149)。
This document defines six new Neighbor Discovery Protocol [4] options, which must be assigned Option Type values within the option numbering space for Neighbor Discovery Protocol messages:
このドキュメントは6つの新しいNeighborディスカバリープロトコル[4]オプションを定義します:(Neighborディスカバリープロトコルメッセージのためにスペースに付番しながら、オプションの中でOption Type値をオプションに割り当てなければなりません)。
o The CGA option (11), described in Section 5.1.
o セクション5.1で説明されたCGAオプション(11)。
Arkko, et al. Standards Track [Page 49] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[49ページ]RFC3971
o The RSA Signature option (12), described in Section 5.2.
o セクション5.2で説明されたRSA Signatureオプション(12)。
o The Timestamp option (13), described in Section 5.3.1.
o セクション5.3.1で説明されたTimestampオプション(13)。
o The Nonce option (14), described in Section 5.3.2.
o セクション5.3.2で説明されたNonceオプション(14)。
o The Trust Anchor option (15), described in Section 6.4.3.
o セクション6.4.3で説明されたTrust Anchorオプション(15)。
o The Certificate option (16), described in Section 6.4.4.
o セクション6.4.4で説明されたCertificateオプション(16)。
This document defines a new 128-bit value under the CGA Message Type [11] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.
このドキュメントはCGA Message Type[11]名前空間(0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08)の下で新しい128ビットの値を定義します。
This document defines a new name space for the Name Type field in the Trust Anchor option. Future values of this field can be allocated by using Standards Action [3]. The current values for this field are
このドキュメントはTrust Anchorオプションで新しい名前スペースをName Type分野と定義します。 Standards Action[3]を使用することによって、この分野の将来価値を割り当てることができます。 この分野への現行価値はそうです。
1 DER Encoded X.501 Name
1 DERはX.501名をコード化しました。
2 FQDN
2 FQDN
Another new name space is allocated for the Cert Type field in the Certificate option. Future values of this field can be allocated by using Standards Action [3]. The current values for this field are
別の新しい名前スペースをCertificateオプションにおけるCert Type分野に割り当てます。 Standards Action[3]を使用することによって、この分野の将来価値を割り当てることができます。 この分野への現行価値はそうです。
1 X.509v3 Certificate
1通のX.509v3証明書
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[1]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[3]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4]NartenとT.とNordmarkとE.とW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[5] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
Arkko, et al. Standards Track [Page 50] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[50ページ]RFC3971
[6] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[6] コンタ、A.、およびS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC2463、1998年12月。
[7] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[7]HousleyとR.とポークとW.とフォードとW.と一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280、2002年4月。
[8] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.
[8] ファレルとS.とR.Housley、「承認のためのインターネット属性証明書プロフィール」、RFC3281、2002年4月。
[9] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[9]FaltstromとP.とホフマンとP.とA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[10] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
[10] リンとC.とケントとS.とK.Seo、「IPアドレスと識別子としてのX.509拡張子」、RFC3779、2004年6月。
[11] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC
3972, March 2005.
[11] 香気、T.、「アドレス(CGA)であると暗号で生成された」RFC3972、2005年3月。
[12] International Telecommunications Union, "Information Technology
- ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.
[12] 国際Telecommunications Union、「情報Technology--ASN.1コード化は以下を統治します」。 「基本的な符号化規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)の仕様」、ITU-T推薦X.690、2002年7月。
[13] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
1, November 2002.
[13] RSA研究所、「RSA暗号化規格、バージョン2.1インチ、PKCS1、2002年11月。」
[14] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[14]米国商務省標準技術局、「安全なハッシュ規格」、FIPSパブ180-1、1995年4月、<http://www.itl.nist.gov/fipspubs/fip180-1.htm>。
12.2. Informative References
12.2. 有益な参照
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[15] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[16] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[16] デアリングとS.とフェナーとW.とB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[17] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[17]NartenとT.とR.Draves、「IPv6"での状態がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[18] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[18] Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、T.、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、2003年7月。
Arkko, et al. Standards Track [Page 51] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[51ページ]RFC3971
[19] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", Work
in Progress, March 2003.
[19] J.、「IKEとIPsec方針へのICMPv6の効果」というArkkoは進歩、2003年3月に働いています。
[20] Arkko, J., "Manual SA Configuration for IPv6 Link Local
Messages", Work in Progress, June 2002.
[20] J.、「IPv6のリンクのローカルのメッセージのための手動のSA構成」というArkkoは進歩、2002年6月に働いています。
[21] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API
for Address Selection", Work in Progress, October 2003.
[21] 「アドレス選択のためのIPv6ソケットAPI」というNordmark、E.、Chakrabarti、S.、およびJ.Laganierは進歩、2003年10月に働いています。
[22] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[22] Nikander、P.、ケンフ、J.、およびE.Nordmark、「IPv6隣人発見(ノースダコタ)信頼モデルと脅威」(RFC3756)は2004がそうするかもしれません。
[23] Bishop, M., "A Security Analysis of the NTP Protocol", Sixth
Annual Computer Security Conference Proceedings, December 1990.
1990年12月の第6[23] 司教、M.、「NTPプロトコルの証券分析」例年のコンピュータセキュリティ会議の議事録。
Arkko, et al. Standards Track [Page 52] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[52ページ]RFC3971
Appendix A. Contributors and Acknowledgments
付録A.貢献者と承認
Tuomas Aura contributed the transition mechanism specification in Section 8. Jonathan Trostle contributed the certification path example in Section 6.3.1. Bill Sommerfeld was involved with much of the early design work.
Tuomas Auraはセクション8の変遷メカニズム仕様を寄付しました。 ジョナサンTrostleはセクション6.3.1における証明経路の例を寄付しました。 ビル・ゾンマーフェルトは早めのデザインワークの多くにかかわりました。
The authors would also like to thank Tuomas Aura, Bill Sommerfeld, Erik Nordmark, Gabriel Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Laganier, Francis Dupont, Pekka Savola, Wenxiao He, Valtteri Niemi, Mike Roe, Russ Housley, Thomas Narten, and Steven Bellovin for interesting discussions in this problem space and for feedback regarding the SEND protocol.
また、作者は、この問題スペースでの興味深い議論とSENDに関するフィードバックのための彼、Valtteri Niemi、マイクRoe、ラスHousley、トーマスNarten、およびスティーブンBellovinが議定書を作るのをTuomas Aura、ビル・ゾンマーフェルト、エリックNordmark、ガブリエル・モンテネグロパシEronen、グレッグ・デイリー、ジョンWood、ジュリアンLaganier、フランシス・デュポン、ペッカSavola、Wenxiaoに感謝したがっています。
Appendix B. Cache Management
付録B.キャッシュ管理
In this section, we outline a cache management algorithm that allows a node to remain partially functional even under a cache-filling DoS attack. This appendix is informational, and real implementations SHOULD use different algorithms in order to avoid the dangers of a mono-cultural code.
このセクションで、私たちはノードがキャッシュをいっぱいにするDoS攻撃でさえ部分的に機能的に残ることができるキャッシュ管理アルゴリズムを概説します。 この付録は情報です、そして、本当の実装SHOULDはモノタイプ文化的なコードという危険を避けるのに異なったアルゴリズムを使用します。
There are at least two distinct cache-related attack scenarios:
少なくとも2つの異なったキャッシュ関連の攻撃シナリオがあります:
1. There are a number of nodes on a link, and someone launches a
cache filling attack. The goal here is to make sure that the
nodes can continue to communicate even if the attack is going on.
1. リンクの上に多くのノードがあります、そして、だれかが攻撃をいっぱいにしながら、キャッシュを始めます。 ここの目標は攻撃が先へ進んでもノードが、交信し続けることができるのを確実にすることです。
2. There is already a cache-filling attack going on, and a new node
arrives to the link. The goal here is to make it possible for the
new node to become attached to the network, in spite of the
attack.
2. 先へ進むキャッシュをいっぱいにする攻撃が既にあります、そして、新しいノードはリンクまで到着します。 ここの目標はそれをネットワークに付けられていて、新しいノードがなるのにおいて可能にすることです、攻撃にもかかわらず。
As the intent is to limit the damage to existing, valid cache entries, it is clearly better to be very selective in throwing out entries. Reducing the timestamp Delta value is very discriminatory against nodes with a large clock difference, as an attacker can reduce its clock difference arbitrarily. Throwing out old entries just because their clock difference is large therefore seems like a bad approach.
意図が損害を既存の、そして、有効なキャッシュエントリーに制限することであるので、エントリーを放り出す際に非常に選択しているのは明確に良いです。 タイムスタンプデルタ価値を減少させるのは大きい時計差でノードに対して非常に差別しています、攻撃者が時計差を任意に減少させることができるのに従って。 したがって、まさしくそれらの時計差が大きいので古いエントリーを放り出すのは悪いアプローチのように見えます。
It is reasonable to have separate cache spaces for new and old entries, where when under attack, the newly cached entries would be more readily dropped. One could track traffic and only allow reasonable new entries that receive genuine traffic to be converted into old cache entries. Although such a scheme can make attacks harder, it will not fully prevent them. For example, an attacker could send a little traffic (i.e., a ping or TCP syn) after each NS
攻撃で新たにキャッシュされたエントリーが、より容易に下げられるだろう新しくて古いエントリーへの別々のキャッシュ空間を持っているのは妥当です。 1つは、トラフィックを追跡して、本物のトラフィックを受ける合理的な新しいエントリーが古いキャッシュエントリーに変換されるのを許容するだけであるかもしれません。 攻撃はそのような体系で、より困難になる場合がありますが、それは完全にそれらを防ぐというわけではないでしょう。 例えば、攻撃者は少しのトラフィック(すなわち、ピングかTCP syn)を各NSの後に送ることができました。
Arkko, et al. Standards Track [Page 53] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[53ページ]RFC3971
to trick the victim into promoting its cache entry to the old cache. To counter this, the node can be more intelligent in keeping its cache entries than it would be just by having a black/white old/new boundary.
犠牲者がキャッシュエントリーを古いキャッシュに促進するようにだますために。 これを打ち返すために、キャッシュがエントリーであることを保つことではノードはそれであるだろうより黒いか白い古いか新しい境界を持っているだけによって、知的である場合があります。
Distinction of the Sec parameter from the CGA Parameters when forcing cache entries out -- by keeping entries with larger Sec parameters preferentially -- also appears to be a possible approach, as CGAs with higher Sec parameters are harder to spoof.
また、キャッシュエントリーを追い出すときの、より大きいSecパラメタで優先的にエントリーを保つのによるCGA ParametersからのSecパラメタの区別は可能なアプローチであるように見えます、より高いSecパラメタがあるCGAsはより偽造しにくいとき。
Appendix C. Message Size When Carrying Certificates
証明書を運ぶとき、付録C.はサイズを通信させます。
In one example scenario using SEND, an Authorization Delegation Discovery test run was made with a certification path length of 4. Three certificates are sent by using Certification Path Advertisement messages, as the trust anchor's certificate is already known by both parties. With a key length of 1024 bits, the certificate lengths in the test run ranged from 864 to 888 bytes; the variation is due to the differences in the certificate issuer names and address prefix extensions. The different certificates had between 1 and 4 address prefix extensions.
SENDを使用する1つの例のシナリオでは、4の証明経路の長さでAuthorization Delegationディスカバリー試運転をしました。 Certification Path Advertisementメッセージを使用することによって、3通の証明書を送ります、信頼アンカーの証明書が双方によって既に知られているように。 1024ビットのキー長で、試運転における証明書の長さは864〜888バイトに及びました。 変化は証明書発行人名とアドレス接頭語拡大の違いのためです。 異なった証明書には、1〜4つのアドレス接頭語拡張子がありました。
The three Certification Path Advertisement messages ranged from 1050 to 1,066 bytes on an Ethernet link layer. The certificate itself accounts for the bulk of the packet. The rest is the trust anchor option, ICMP header, IPv6 header, and link layer header.
3つのCertification Path Advertisementメッセージがイーサネットリンクレイヤの1050〜1,066バイトまで変化しました。 証明書自体はパケットの嵩を占めます。 残りは、信頼アンカーオプションと、ICMPヘッダーと、IPv6ヘッダーと、リンクレイヤヘッダーです。
Arkko, et al. Standards Track [Page 54] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[54ページ]RFC3971
Authors' Addresses
作者のアドレス
Jari Arkko Ericsson Jorvas 02420 Finland
ヤリArkkoエリクソンJorvas02420フィンランド
EMail: jari.arkko@ericsson.com
メール: jari.arkko@ericsson.com
James Kempf DoCoMo Communications Labs USA 181 Metro Drive San Jose, CA 94043 USA
ジェームスケンフDoCoMoコミュニケーション研究室米国181地下鉄Driveカリフォルニア94043サンノゼ(米国)
EMail: kempf@docomolabs-usa.com
メール: kempf@docomolabs-usa.com
Brian Zill Microsoft Research One Microsoft Way Redmond, WA 98052 USA
ブライアンZillマイクロソフトは1つのマイクロソフト方法でワシントン98052レッドモンド(米国)について研究します。
EMail: bzill@microsoft.com
メール: bzill@microsoft.com
Pekka Nikander Ericsson Jorvas 02420 Finland
ペッカNikanderエリクソンJorvas02420フィンランド
EMail: Pekka.Nikander@nomadiclab.com
メール: Pekka.Nikander@nomadiclab.com
Arkko, et al. Standards Track [Page 55] RFC 3971 SEcure Neighbor Discovery March 2005
Arkko、他 2005年の隣人発見行進のときに安全な標準化過程[55ページ]RFC3971
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Arkko, et al. Standards Track [Page 56]
Arkko、他 標準化過程[56ページ]
一覧
スポンサーリンク
