[要約] RFC 3971は、SEcure Neighbor Discovery (SEND) プロトコルに関する仕様を提供しています。SENDの目的は、IPv6ネットワークでの隣接ノードの発見を安全に行うことです。
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
SEcure Neighbor Discovery (SEND)
安全な近隣探索 (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.
この文書は、インターネット コミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めます。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1) を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権 (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 ノードは、近隣探索プロトコル (NDP) を使用して、リンク上の他のノードを検出し、リンク層アドレスを決定してルーターを見つけ、アクティブな近隣ノードへのパスに関する到達可能性情報を維持します。NDP が保護されていない場合、さまざまな攻撃に対して脆弱になります。この文書では、NDP のセキュリティ メカニズムを指定します。元の NDP 仕様とは異なり、これらのメカニズムは IPsec を使用しません。
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
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
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 は、RFC 2461 [4] および 2462 [5] で近隣探索プロトコル (NDP) を定義しています。同じリンク上のノードは、NDP を使用して、互いの存在とリンク層アドレスを検出し、ルーターを見つけ、アクティブな隣接ノードへのパスに関する到達可能性情報を維持します。NDP はホストとルーターの両方で使用されます。その機能には、近隣探索 (ND)、ルーター探索 (RD)、アドレス自動構成、アドレス解決、近隣到達不能検出 (NUD)、重複アドレス検出 (DAD)、およびリダイレクトが含まれます。
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 仕様では、NDP メッセージを保護するために IPsec の使用が必要でした。ただし、RFC には、これを行うために IPsec を使用するための詳細な手順が記載されていません。この特定のアプリケーションでは、IKE を使用する際のブートストラップの問題のため、IPsec はセキュリティ アソシエーションの手動構成でのみ使用できます [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 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].
この文書は次のように構成されています。セクション 2 と 3 では、それぞれいくつかの用語を定義し、NDP の簡単なレビューを示します。セクション 4 では、NDP を保護するための全体的なアプローチについて説明します。このアプローチには、公開キーベースの署名を伝送するための新しい NDP オプションの使用が含まれます。個々のノードのアドレス所有権を示すために、ゼロ構成メカニズムが使用されます。ルーターはトラスト アンカーによって認証されます [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.
必要な新しい NDP オプションについては、セクション 5 で説明します。セクション 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 とセキュリティ保護されていない NDP の共存について説明し、セクション 9 では、SEcure Neighbor Discovery (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.
アドレスの使用を許可するためにエンドホストにプロビジョニングされた ID 証明書の使用は、アドレスを防御するエンティティがそのアドレスを主張するエンティティ (「プロキシ」とも呼ばれる) と同じでない場合の NDP のセキュリティと同様に、このドキュメントの範囲外です。ND」）。これらは SEND の拡張であり、必要に応じて別のドキュメントで扱うことができます。
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」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、および「MAY」は、[2] で説明されているように解釈されます。
Authorization Delegation Discovery (ADD)
認可委任検出 (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 つの方法では、当局は証明書失効リストと呼ばれる署名付きデータ構造を定期的に発行します。これは、発行者によって署名され、パブリック リポジトリで自由に利用できる、失効した証明書を識別するタイムスタンプ付きのリストです。
Certification Path Advertisement (CPA)
認証パスのアドバタイズメント (CPA)
The advertisement message used in the ADD process.
ADD プロセスで使用されるアドバタイズメント メッセージ。
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)
重複アドレス検出 (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 セット以外の文字を含むドメイン名を表すことができます。RFC 3490 [9] を参照してください。
Neighbor Discovery (ND)
近隣探索 (ND)
The Neighbor Discovery function of the Neighbor Discovery Protocol (NDP). NDP contains functions besides ND.
近隣探索プロトコル (NDP) の近隣探索機能。NDPにはND以外の機能も含まれています。
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].
近隣探索プロトコルは ICMPv6 [6] の一部です。
Neighbor Unreachability Detection (NUD)
近隣到達不能検出 (NUD)
A mechanism used for tracking the reachability of neighbors.
近隣ノードの到達可能性を追跡するために使用されるメカニズム。
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.
この仕様を実装せず、更新された RFC 2461 および 2462 で定義された近隣探索プロトコルのみをセキュリティなしで使用する 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.
ノードによって生成され、1 回だけ使用される予測不可能な乱数または擬似乱数。SEND では、特定の広告がそれをトリガーした勧誘にリンクされていることを保証するためにノンスが使用されます。
Router Authorization Certificate
ルーター認証証明書
An X.509v3 [7] public key certificate using the profile specified in Section 6.3.1.
セクション 6.3.1 で指定されたプロファイルを使用する X.509v3 [7] 公開鍵証明書。
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.
ルーター検出を使用すると、ホストはリンク上にどのようなルーターが存在するか、またどのようなサブネット プレフィックスが利用可能かを検出できます。Router Discovery は、Neighbor Discovery Protocol の一部です。
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).
ホストは、ルーター検出を保護するために一連のトラスト アンカーを使用して構成されます。トラスト アンカーは、ルーターがルーターとして機能することを許可するためにホストが信頼するエンティティです。トラストアンカー設定は、公開キーといくつかの関連パラメータで構成されます (これらのパラメータの詳細な説明については、セクション 6.5 を参照してください)。
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.
近隣探索プロトコルにはいくつかの機能があります。これらの多くは、ICMPv6 近隣通知メッセージなど、いくつかの中心的なメッセージ タイプで過負荷になっています。このセクションでは、メッセージをどのように処理すべきかをよりよく理解するために、これらのタスクのいくつかとその影響を確認します。このセクションは規範的なものではなく、このセクションと元の近隣探索 RFC が矛盾する場合は、更新された元の RFC が優先されます。
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 ルーター検出機能を使用すると、IPv6 ホストは接続されたリンク上のローカル ルーターを検出できます。Router Discovery は、RFC 2461 [4] のセクション 6 で説明されています。ルーター検出の主な目的は、ホストに代わってパケットを転送する隣接ルーターを見つけることです。サブネット プレフィックスの検出には、どの宛先がリンク上に直接存在するかを判断することが含まれます。この情報は、パケットをルーターに送信するか、宛先ノードに直接送信するかを知るために必要です。
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 リダイレクト機能は、ホストをより適切なファーストホップ ルーターに自動的にリダイレクトするため、または宛先が実際には近隣 (つまり、オンリンク) であることをホストに通知するために使用されます。リダイレクトは RFC 2461 [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 アドレス自動構成は、ホストにアドレスを自動的に割り当てるために使用されます [5]。これにより、IP 接続に関連する明示的な構成を行わなくてもホストが動作できるようになります。デフォルトの自動構成メカニズムはステートレスです。IP アドレスを作成するために、ホストはルーター検出中に提供されたプレフィックス情報を使用し、新しく形成されたアドレスの一意性をテストします。ステートフル メカニズムである 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 重複アドレス検出 (DAD) は、アドレス自動構成時などのアドレス衝突を防ぐために使用されます [5]。新しいアドレスをインターフェイスの 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 アドレス解決機能を使用すると、リンク上のノードが別のノードの IPv6 アドレスを対応するリンク層アドレスに解決できます。アドレス解決は RFC 2461 [4] のセクション 7.2 で定義されており、ホストとルーターの両方に同様に使用されます。繰り返しますが、送信者が宛先ノードまたは次ホップ ルーターのリンク層アドレスを知るまで、より高いレベルのトラフィックは続行できません。リンク層フレーム上の送信元リンク層アドレスは、アドレス解決を通じて学習した情報と照合されないことに注意してください。これにより、ブリッジやプロキシなどのネットワーク要素を簡単に追加できるようになり、層間で受け渡される情報が少なくなるため、スタックの実装要件が緩和されます。
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 近隣到達不能検出 (NUD) は、ホストとルーターの両方の近隣ノードの到達可能性を追跡するために使用されます。NUD は RFC 2461 [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 機能は、ルーター要請 (RS)、ルーター広告 (RA)、近隣要請 (NS)、近隣広告 (NA)、およびリダイレクト メッセージを使用して実現されます。実際の NDP メッセージには、ICMPv6 ヘッダーと ND メッセージ固有のデータで構成される NDP メッセージ ヘッダーと、0 個以上の NDP オプションが含まれています。NDP メッセージ オプションは、タイプ-長さ-値の形式でフォーマットされます。
<------------NDP Message---------------->
*-------------------------------------------------------------*
| IPv6 Header | ICMPv6 | ND Message- | ND Message |
| Next Header = 58 | Header | specific | Options |
| (ICMPv6) | | data | |
*-------------------------------------------------------------*
<--NDP Message header-->
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 のさまざまな機能を保護するために、一連の新しい近隣探索オプションが導入されています。これらは 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 信頼できる当事者に基づいた認証パスは、ルーターの権限を認証することが期待されます。ホストがルータをデフォルト ルータとして採用するには、その前に、ルータが認証パスを持つトラスト アンカーをホストに設定する必要があります。証明書パス要請およびアドバタイズメント メッセージは、実際のルーター検出メッセージで長い証明書パスを伝送する必要なく、トラスト アンカーへの証明書パスを検出するために使用されます。利用可能な証明書パスがない、保護されたルーター アドバタイズメント メッセージを受信すると、認可委任の検出プロセスがトリガーされます。
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 暗号的に生成されたアドレスは、近隣探索メッセージの送信者が要求されたアドレスの「所有者」であることを確認するために使用されます。公開鍵と秘密鍵のペアは、アドレスを要求する前にすべてのノードによって生成されます。新しい 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.
この仕様により、ノードは、その使用を許可する証明書を持つ非 CGA を使用することもできます。ただし、そのような使用法の詳細はこの仕様の範囲を超えており、将来の作業に残されています。
o A new NDP option, the RSA Signature option, is used to protect all messages relating to Neighbor and Router discovery.
o 新しい NDP オプションである RSA 署名オプションは、近隣およびルーターの検出に関連するすべてのメッセージを保護するために使用されます。
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.
公開キー署名はメッセージの整合性を保護し、送信者の身元を認証します。公開キーの権限は、構成と保護されるメッセージの種類に応じて、証明書を使用する認可委任プロセス、または CGA を使用するアドレス所有権証明メカニズム、あるいはその両方によって確立されます。
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 が義務付けられているのは、複数の署名アルゴリズムを使用すると、実装間の互換性が損なわれたり、複数のアルゴリズムとその中から選択するメカニズムの実装が強制され、実装の複雑さが増大したりするためです。2 番目の署名アルゴリズムは、RSA に欠陥が見つかった場合の回復メカニズムとしてのみ必要です。この場合、より強力な署名アルゴリズムを選択し、SEND を修正することができます。このドキュメントで説明されている新しいアルゴリズムと RSA ベースの SEND との関係は、RSA ベースの SEND と 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 つの新しい近隣探索オプションが導入されました。近隣およびルーター探索メッセージがマルチキャスト アドレスに送信される場合があることを考慮すると、タイムスタンプ オプションは、事前に確立された状態番号やシーケンス番号なしでリプレイ保護を提供します。メッセージが要請と広告のペアで使用される場合、メッセージは Nonce オプションで保護されます。
The options described in this section MUST be supported.
このセクションで説明するオプションはサポートされなければなりません。
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 オクテット単位のオプションの長さ (タイプ、長さ、パッド長、予約済み、CGA パラメーター、およびパディング フィールドを含む)。
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 パラメータ フィールドの終わりを越えるが、長さフィールドで指定された長さ以内のパディング オクテットの数。パディングオクテットは送信者によってゼロに設定され、受信者によって無視されなければなりません (MUST)。
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 ビットのフィールド。この値は送信者によってゼロに初期化されなければならず、受信者によって無視されなければなりません。
CGA Parameters
CGAパラメータ
A variable-length field containing the CGA Parameters data structure described in Section 4 of [11].
[11] のセクション 4 で説明されている CGA パラメータ データ構造を含む可変長フィールド。
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 署名オプションの両方が存在する場合、CGA オプションの CGA Parameters フィールドから見つかった公開鍵は、RSA Signature オプションの Key Hash フィールドによって参照される公開鍵でなければなりません (MUST)。2 つの異なるキーで受信されたパケットは、サイレントに破棄されなければなりません (MUST)。将来の拡張では、アドレスの所有者と署名者を別の当事者にできるメカニズムが提供される可能性があることに注意してください。
Padding
パディング
A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field.
オプションの長さを 8 の倍数にする可変長フィールド。パッド長フィールドで指定されたのと同じ数のオクテットが含まれます。
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.
ノードが SEND を使用するように設定されている場合、CGA オプションはすべての近隣要請メッセージと広告メッセージに存在しなければならず、未指定の送信元アドレスで送信される場合を除き、ルーター要請メッセージにも存在しなければなりません。CGA オプションは他のメッセージに存在してもよい(MAY)。
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:
CGA オプションの CGA パラメータ フィールドは、上記および [11] に示されているルールに従って入力されます。フィールド内の公開キーは、CGA の生成に使用される構成から、通常は送信元アドレスに関連付けられたデータ構造から取得されます。アドレスは、[11] のセクション 4 で指定されているように構築されなければなりません (MUST)。メッセージのタイプに応じて、このアドレスは次のようにさまざまな場所に表示されます。
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.
アドレスは、重複アドレス検出のために送信される送信要求のターゲット アドレスでなければなりません。それ以外の場合は、メッセージの送信元アドレスでなければなりません。
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.
アドレスはメッセージの送信元アドレスでなければなりません。
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 オプションのない近隣要請および通知メッセージは、安全でないものとして扱われなければなりません (つまり、非 SEND ノードによって送信される NDP メッセージと同じ方法で処理されます)。安全でないメッセージの処理はセクション 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 オプションのないルーター要請メッセージも、メッセージの送信元アドレスが未指定のアドレスでない限り、安全でないものとして扱われなければなりません (MUST)。
Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages containing a CGA option MUST be checked as follows:
CGA オプションを含むリダイレクト、近隣要請、近隣広告、ルーター要請、およびルーター広告メッセージは、次のようにチェックする必要があります。
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 に記載されているアルゴリズムを使用して、パケットの送信元アドレスを検証しなければなりません (MUST)。アルゴリズムへの入力は、前のセクションで定義したように、要求されたアドレスと CGA パラメーター フィールドです。
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 プロパティは単に検証されないままになります。
All nodes that support the verification of the CGA option MUST record the following configuration information:
CGA オプションの検証をサポートするすべてのノードは、次の構成情報を記録する必要があります。
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.
CGA の生成に使用される公開キーの最小許容キー長。デフォルトは 1024 ビットであるべきです。実装は、これらのセキュリティ アソシエーションを使用するパケットを検証するときに必要な計算量の上限を設定してもよい(MAY)。上限は少なくとも 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] で説明されている CGA の構築に必要な情報。
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 署名オプションを使用すると、公開キーベースの署名を NDP メッセージに添付できます。RSA 署名オプションの形式を次の図に示します。
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 オクテット単位のオプションの長さ (タイプ、長さ、予約済み、キー ハッシュ、デジタル署名、およびパディング フィールドを含む)。
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 ビットのフィールド。この値は送信者によってゼロに初期化されなければならず、受信者によって無視されなければなりません。
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 ビットのフィールド。SHA-1 ハッシュは、CGA オプションで伝送される CGA パラメータ データ構造の公開キー フィールドで使用されるプレゼンテーションを引き継ぎます。その目的は、署名を受信者が知っている特定のキーに関連付けることです。このようなキーは、受信者の証明書キャッシュに保存することも、同じメッセージ内の 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#1 v1.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 の 128 ビット CGA メッセージ タイプ タグ [11] 値、0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08。(タグ値は、この仕様の編集者によってランダムに生成されました。)
2. The 128-bit Source Address field from the IP header.
2. IP ヘッダーの 128 ビットの送信元アドレス フィールド。
3. The 128-bit Destination Address field from the IP header.
3. IP ヘッダーの 128 ビットの宛先アドレス フィールド。
4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the ICMP header.
4. ICMP ヘッダーの 8 ビット タイプ、8 ビット コード、および 16 ビット チェックサム フィールド。
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 チェックサム フィールドの後のオクテットから始まり、NDP オプションまで続きますが、NDP オプションは含まれません。
6. All NDP options preceding the RSA Signature option.
6. RSA 署名オプションより前のすべての 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 署名オプションの長さから他のフィールド (可変長のパッド フィールドを含む) の長さを引いたものによって決まります。
Padding
パディング
This variable-length field contains padding, as many bytes long as remain after the end of the signature.
この可変長フィールドには、署名の終了後に残っている長さのバイト数のパディングが含まれます。
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、近隣要請、近隣通知、ルーター通知、およびリダイレクト メッセージを使用するように設定されている場合は、RSA 署名オプションを含める必要があります。送信元アドレスが指定されていないルーター要請メッセージには、RSA 署名オプションが含まれていなければなりません (MUST)。
A node sending a message with the RSA Signature option MUST construct the message as follows:
RSA 署名オプションを使用してメッセージを送信するノードは、次のようにメッセージを構築しなければなりません。
o The message is constructed in its entirety, without the RSA Signature option.
o メッセージは、RSA 署名オプションなしで全体が構築されます。
o The RSA Signature option is added as the last option in the message.
o RSA 署名オプションはメッセージの最後のオプションとして追加されます。
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 のデジタル署名フィールドの説明に従って構築されます。
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#1 v1.5 署名が [デジタル署名] フィールドに入力されます。
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 署名オプションのない近隣要請、近隣広告、ルーター広告、およびリダイレクト メッセージは、安全でないものとして扱われなければなりません (つまり、非 SEND ノードによって送信される NDP メッセージと同じ方法で処理されます)。セクション 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 署名オプションのないルーター要請メッセージも、メッセージの送信元アドレスが未指定のアドレスでない限り、安全でないものとして扱われなければなりません (MUST)。
Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages containing an RSA Signature option MUST be checked as follows:
RSA 署名オプションを含むリダイレクト、近隣要請、近隣通知、ルーター要請、およびルーター通知メッセージは、次のようにチェックする必要があります。
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 署名オプションの後に来るオプションを無視しなければなりません (MUST)。(オプションは、署名検証と 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 オプションから学習した公開鍵、または他の手段で既知の公開鍵の使用を示さなければなりません (MUST)。
o The Digital Signature field MUST have correct encoding and MUST not exceed the length of the RSA Signature option minus the Padding.
o デジタル署名フィールドは正しいエンコーディングを持っていなければならず、RSA 署名オプションからパディングを差し引いた長さを超えてはなりません。
o The Digital Signature verification MUST show that the signature has been calculated as specified in the previous section.
o デジタル署名の検証では、署名が前のセクションで指定されたとおりに計算されていることを示さなければなりません。
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 を参照) がわかっていなければなりません (MUST)。
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).
ホストがセキュリティで保護された ND メッセージのみを受け入れるように設定されている場合、上記のすべてのテストに合格しないメッセージは、サイレントに破棄されなければなりません (MUST)。ホストが保護されたメッセージと保護されていないメッセージの両方を受け入れるように設定されている場合、メッセージは受け入れられてもよい (MAY) が、保護されていないメッセージとして扱われなければなりません (MUST)。受信者は、そうでない場合には（たとえば、明らかな CPU を使い果たす DoS 攻撃への応答として）パケットを静かに破棄してもよい（MAY）。
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 署名オプションの受信をサポートするすべてのノードは、個別の NDP メッセージ タイプごとに次の情報を設定できるようにしなければなりません (MUST)。
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 で説明されているように検証されます。送信者は CGA を使用して追加の許可を要求する場合がありますが、これは必須でも検証されるものでもありません。
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] で説明されているように検証されます。送信者はトラストアンカーを通じて追加の権限を要求できますが、これは必須でも検証されません。
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 署名オプションの送信をサポートするすべてのノードは、次の構成情報を記録する必要があります。
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 プロトコルの将来の拡張では、このフラグはサブネット プレフィックスごとにもなる可能性があることに注意してください。)
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 署名オプションの構築と検証には、計算コストがかかります。ただし、NDP コンテキストでは、ホストは通常、リンクに入るときにいくつかの署名操作、通信する新しいオンリンク ピアを見つけるときにいくつかの操作、または既存の近隣機器との近隣機器到達不能検出を実行するだけで済みます。
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 プロトコルでは、要請に対するマルチキャスト応答の送信速度が制限されていますが、ルーターの要請が多数あると、非対称操作の実行に対する要求が高くなる可能性があります。
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.
将来のアドバタイズメントのタイミングがわかっている場合、未承諾 (マルチキャスト) ネイバーおよびルーター アドバタイズメントの署名を事前に計算できます。通常、要請された近隣広告は、要請の送信元のユニキャスト アドレスに送信されます。IPv6 ヘッダーが署名でカバーされているとすると、要請されたアドバタイズメントを事前に計算することはできません。
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:
タイムスタンプ オプションの目的は、一方的な通知とリダイレクトが再生されないようにすることです。このオプションの形式については、以下で説明します。
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 オクテット単位のオプションの長さ (タイプ、長さ、予約済み、およびタイムスタンプの各フィールドを含む)。つまり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 ビットのフィールド。この値は送信者によってゼロに初期化されなければならず、受信者によって無視されなければなりません。
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 日の 00:00 UTC からの秒数を示します。この形式では、秒の整数がフィールドの最初の 48 ビットに含まれ、残りの 16 ビットは 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 での通常の時間表現と互換性がありますが、整数部分と小数部分に使用できるビット数は異なる場合があります。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 バイトでなければなりません。乱数の長さは、nonce オプションの長さが 8 オクテットの倍数になるように選択しなければなりません (MUST)。
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 が含まれなければなりません (MUST)。要請を送信するとき、送信者は、その特定のノンスを含む応答を認識できるように、そのノンスを内部に保存しなければなりません (MUST)。
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 が含まれなければなりません (MUST)。ルーターは、特定のホストへの応答ではなく、すべてのノードにマルチキャスト アドバタイズメントを送信することを決定する場合があることに注意してください。このような場合、ルーターは、マルチキャスト広告をトリガーしたホストの nonce 値を含めてもよい (MAY)。(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 を使用するように設定されている場合、すべての要請、通知、およびリダイレクト メッセージにはタイムスタンプが含まれなければなりません (MUST)。送信者は、リアルタイムクロックに従って、タイムスタンプフィールドを現在時刻に設定すべきです(SHOULD)。
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 オプションと Nonce オプションの少なくとも 1 つを指定せずに受信したメッセージは、安全でないものとして扱われなければなりません (つまり、非 SEND ノードによって送信された NDP メッセージと同じ方法で処理されます)。
o Messages received with the RSA Signature option but without the Timestamp option MUST be silently discarded.
o RSA 署名オプションを使用してタイムスタンプ オプションを使用せずに受信したメッセージは、サイレントに破棄されなければなりません (MUST)。
o Solicitation messages received with the RSA Signature option but without the Nonce option MUST be silently discarded.
o RSA Signature オプションを使用して Nonce オプションを使用せずに受信した要請メッセージは、サイレントに破棄されなければなりません (MUST)。
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)。
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 実装では、リプレイ攻撃に対する耐性を強化するために、タイムスタンプ キャッシュなどのメカニズムを使用してもよい(MAY)。同じリンク上に非常に多くのノードが存在する場合、またはキャッシュ フィル攻撃が進行中の場合、送信者ごとの最新のタイムスタンプを保持するキャッシュがいっぱいになる可能性があります。この場合、ノードはキャッシュから一部のエントリを削除するか、新しく要求されたエントリを拒否しなければなりません (MUST)。どのエントリが他のエントリよりも優先されるかに関する具体的なポリシーは、実装の決定として残されます。ただし、一般的なポリシーでは、新しいエントリよりも既存のエントリが優先され、Sec 値が大きい CGA が小さい Sec 値よりも優先される場合があります。この問題については、付録 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 受信者は、RFC 2461 [4]、セクション 9 に従って、タイムスタンプとノンスオプションを任意の順序で受信できるように準備しなければなりません (MUST)。
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 のコピーが含まれていることを検証しなければなりません (MUST)。
If the message contains a Nonce option but the Nonce value is not recognized, the message MUST be silently discarded.
メッセージに Nonce オプションが含まれているが、Nonce 値が認識されない場合、メッセージは黙って破棄されなければなりません (MUST)。
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 オプションが含まれていない場合、そのメッセージは一方的な広告とみなされ、セクション 5.3.4.2 に従って処理されてもよい(MAY)。
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.
メッセージが受け入れられた場合、受信者はセクション5.3.4.2で指定されているように、メッセージの受信時刻とタイムスタンプ時刻をメッセージに保存する必要があります(SHOULD)。
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_DELTA です。ファズ係数 TIMESTAMP_FUZZ の場合。クロックドリフトの場合は TIMESTAMP_DRIFT (セクション 10.2 を参照)。
To facilitate timestamp checking, each node SHOULD store the following information for each peer:
タイムスタンプのチェックを容易にするために、各ノードはピアごとに次の情報を保存する必要があります。
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と呼びます。
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 メッセージは、特定のピアからの、正常に検証された近隣要請、近隣通知、ルーター要請、ルーター通知、またはリダイレクト メッセージです。上記の変数を更新する前に、このようなメッセージで RSA 署名オプションを使用する必要があります。
Receivers SHOULD then check the Timestamp field as follows:
次に、受信者は次のようにタイムスタンプフィールドを確認する必要があります。
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
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 タイムスタンプが境界内にないが、メッセージが受信者が応答すべき近隣要請メッセージである場合、受信者はメッセージに応答すべきである(SHOULD)。ただし、たとえメッセージに応答したとしても、近隣キャッシュ エントリを作成してはなりません。これにより、クロックの差が大きいノードでも、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
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の場合、受信機はRDlastとTSlastを更新すべきである(SHOULD)。それ以外の場合、受信者は RDlast または TSlast を更新してはなりません (MUST NOT)。
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)。
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 Discovery Protocol では、証明書の形式が義務付けられ、ホストとルーター間で使用される 2 つの新しい ICMPv6 メッセージが導入され、ホストがルーターの支援を受けて証明書パスを学習できるようになります。
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 Discovery を保護するために、SEND ではルーターがルーターとして機能することが許可されている必要があります。この認可はルーターとホストの両方でプロビジョニングされます。ルーターにはトラスト アンカーから証明書が与えられ、ホストはルーターを承認するためにトラスト アンカーを使用して構成されます。このプロビジョニングは SEND に固有であり、他の目的で既に展開されている証明書が使用できることを想定していません。
The authorization for routers in SEND is twofold:
SEND におけるルーターの承認は 2 つあります。
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 など) に委任し、その人がこのセットの一部を個々のルーターに委任することもあります。
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 アドレスがあり、サブネット プレフィックスには有効期間があり、ルーターはステートレスおよびステートフル アドレスの自動構成の使用を制御します。ただし、ルーターになる機能とサブネット プレフィックスは、承認するための最も基本的なパラメーターです。これは、ホストがデフォルト ルーターとして使用するルーターを選択する必要があることと、アドバタイズされたサブネット プレフィックスがホストが使用するアドレスに影響を与えるためです。サブネット プレフィックスは、ネットワーク内のルーターのトポロジ上の位置に関する要求も表します。
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 では null プレフィックスの使用が許可されているため、他のアプリケーションで検証やルーティングの問題が発生する可能性があります。null プレフィックスを含む SEND 証明書は、SEND のみに使用することが推奨されます。
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.
現在の Web クライアントが認定鍵を使用したエンドホストのプロビジョニングを必要としないのと同様に、エンドホストも独自の認定公開鍵を使用してプロビジョニングする必要がないことに注意してください。CGA 生成用の公開鍵は、アドレスに関連付けることによって CGA での操作を許可する機能を取得するため、認証する必要はありません。
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.
トラスト アンカーの展開モデルは、グローバルにルートされた公開キー インフラストラクチャ、または Web サーバーの TLS に現在使用されているものと同様の、よりローカルな分散型展開モデルのいずれかになります。集中型モデルは、ルーターと、オプションでルーターがアドバタイズするアドレス空間を認可できるグローバル ルートを想定しています。エンドホストは、グローバル ルートの公開キーを使用して構成されます。グローバル ルートは、たとえば、Internet Assigned Numbers Authority (IANA) の下で、または地域インターネット レジストリ (RIR) 間の協同組合として動作する可能性があります。ただし、そのようなグローバル ルートは現在存在しません。
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 向け。
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 ルーターの使用にフォールバックできます。これにより、考えられるすべてのネットワークにトラスト アンカーがない場合でも、ローカルのトラスト アンカーから開始できるようになります。
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 ノードがルーターとして機能することを許可するルーター許可証明書で終了します。この記事の執筆時点では認証パスはインターネットでは一般的ではないため、パスは標準の公開鍵証明書 ([8] の意味での PKC) で構成されなければなりません (MUST)。認証パスは、ホストとルーターによって共有されるトラスト アンカーの ID から開始しなければなりません (MUST)。これにより、ホストはルーターの公開キーに対する信頼をトラスト アンカーに固定することができます。単一のトラスト アンカーによって複数の証明書が発行される可能性があることに注意してください。
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.
ルーター認証証明書は、RFC 3280 [7] で定義されている X.509v3 証明書であり、[10] で定義されている IP アドレスの X.509 拡張のインスタンスを少なくとも 1 つ含む必要があります (SHOULD)。証明書パス内の親証明書には、問題のルーターの元の IP アドレス ブロックを設定した、または権利を委任した信頼できる当事者 (ユーザーの ISP など) にバックアップされた、1 つ以上の X.509 IP アドレス拡張子が含まれている必要があります (SHOULD)。そうするために。中間委任機関の証明書には、副委任のための X.509 IP アドレス拡張が含まれている必要があります (SHOULD)。ルーターの証明書は、ルーターがアドバタイズすることを許可されているサブネット プレフィックスの委任機関によって署名されます。
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 つの addressOrRanges 要素が含まれなければなりません。この要素には、ルーターまたは中間エンティティがルーティングを許可されているプレフィックスの IPv6 アドレス プレフィックスを含む addressPrefix 要素が含まれなければなりません (MUST)。エンティティが任意のプレフィックスのルーティングを許可されている場合、使用される IPv6 アドレス プレフィックスはヌル プレフィックス ::/0 です。IPAddrBlocks シーケンス要素の addressFamily 要素には、[10] で指定されている、IPv6 サブネット プレフィックスの IPv6 アドレス ファミリ識別子 (0002) が含まれなければなりません (MUST)。複数のプレフィックスが許可されている場合、addressPrefix 要素の代わりに、addressOrRange 要素にサブネット プレフィックスの範囲に対する addressRange 要素を含めることができます (MAY)。X.509 IP アドレス拡張には、addressPrefix または addressRange として表現される追加の IPv6 サブネット プレフィックスを含めることができます (MAY)。
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.
ルーター認可証明書を受け取るノードは、証明書の署名が委任機関によって生成されたものであるかどうかを最初に確認しなければなりません (MUST)。次に、クライアントは、ルーターの証明書内のすべての addressPrefix または addressRange エントリが委任機関の証明書のアドレス範囲内に含まれているかどうか、および addressPrefix エントリが委任機関の証明書内の addressPrefix エントリと一致するかどうかを確認する必要があります(SHOULD)。addressPrefix または addressRange が委任機関のサブネット プレフィックスまたは範囲内に含まれていない場合、クライアントは範囲/サブネット プレフィックスの交差部分を取得し、その交差部分を使用することを試みてもよい(MAY)。結果の交差が空の場合、クライアントは証明書を受け入れてはなりません (MUST NOT)。証明書内の addressPrefix が欠落している場合、または null プレフィックス ::/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.
ホストは、証明書パスの最後の証明書内の subjectPublicKeyInfo フィールドをチェックして、ルーター署名の検証を試行するために RSA 公開鍵のみが使用されていることを確認しなければなりません (MUST)。ホストは、SEND 用の証明書に RSA キーが含まれていない場合、その証明書を無視しなければなりません (MUST)。
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 アドレス拡張要素がすぐには含まれない可能性があるため、実装にはプレフィックスと範囲のチェックを緩和できる機能が含まれていてもよい(MAY)。ただし、そのような構成オプションはデフォルトでオフにすべきです(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_group_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_group_example.net 有効期間: 2004 年 1 月 1 日から 2004 年 12 月 31 日まで 件名: isp_group_example.net 拡張子: IP アドレス委任拡張子: プレフィックス: P1、...、Pk ... おそらく他の拡張子 ... 。.. 他の証明書パラメータ ...
When the host attaches to a link served by router_x.isp_foo_example.net, it receives the following certification path:
ホストが router_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_group_example.net 有効期間: 2004 年 1 月 1 日から 2004 年 12 月 31 日まで 件名: isp_foo_example.net 拡張子: 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 有効期間: 2004 年 1 月 1 日から 2004 年 12 月 31 日まで 件名: router_x.isp_foo_example.net 拡張子: 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 つの証明書が処理されると、通常の RFC 3280 [7] 証明書パスの検証が実行されます。ただし、ノードがルーターから受信した証明書をチェックするときは、通常、まだインターネットに接続されていないため、必要に応じてオンラインの証明書失効リスト (CRL) チェックを実行できないことに注意してください。このチェックが実行されるまで、証明書の受け入れは暫定的なものとみなされなければならず (MUST)、ノードはルータを介してインターネットとの接続を確立したらすぐにチェックを実行しなければなりません (MUST)。ルーターが侵害されている場合、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 のサブセットである必要があります。認証パスが有効な場合、router_foo.isp_foo_example.com はプレフィックス R1、...、Rs をルーティングする権限を与えられます。
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 アドレス拡張の展開自体は一般的ではないため、ネットワーク サービス プロバイダーは、署名付きルーター アドバタイズメント用のルーターの公開キーを提供するために、標準の ID 証明書をルーターに展開することを選択してもよい(MAY)。
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.
他の証明書にプレフィックス情報が含まれている場合、標準のアイデンティティ証明書はそれらのサブネット プレフィックスを許可すると解釈されます。
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.
証明書パス要請 (CPS) メッセージは、ルーターとホストのトラスト アンカーの 1 つとの間の証明書パスを要求する場合に、ホストによって送信されます。証明書パス アドバタイズメント (CPA) メッセージは、CPS メッセージへの応答として送信されます。これらのメッセージは、他のメッセージに対する膨大な量になる可能性がある認証パス情報の影響を軽減するために、残りの近隣およびルーター探索とは別に保管されます。
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.
Authorization Delegation Discovery (ADD) プロセスは、他の形式の証明書パスの検出を除外しません。たとえば、高速移動中に、モバイル ノードは前のルーターから次のルーターに関する情報 (認証パスを含む) を学習したり、ローミング パートナーからの認証パスを使用してノードが事前に設定されたりすることがあります。
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.
ホスト自体がトラストアンカーによって認証されている場合、オプションでこれらのメッセージをホスト間でピアの認証パスを取得するために使用してもよい(MAY)。ただし、そのような使用法の詳細は、この仕様の範囲を超えています。
Hosts send Certification Path Solicitations in order to prompt routers to generate Certification Path Advertisements.
ホストは、ルーターに認証パス アドバタイズメントを生成するよう促すために、認証パス要請を送信します。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-
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-Routers マルチキャスト アドレス、Solicited-Node マルチキャスト アドレス、またはホストのデフォルト ルーターのアドレスです。
Hop Limit
ホップ制限
255
255
ICMP Fields:
ICMP フィールド:
Type
タイプ
148
148
Code
コード
0
0
Checksum
チェックサム
The ICMP checksum [6].
ICMP チェックサム [6]。
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 ビットの符号なし整数フィールド。広告と要請を照合するのに役立つ識別子として機能します。識別子フィールドはゼロであってはならず、その値はランダムに生成されるべきです。このランダム性は、衝突を避けることのみが目的であるため、暗号的に難しい必要はありません。
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 ビットの符号なし整数フィールドは 65,535 に設定されます。それ以外の場合は、受信者が取得したい証明書に対応するコンポーネント識別子に設定されます (セクション 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.
クライアントが受け入れてもよい 1 つ以上のトラスト アンカー。最初 (または唯一) のトラスト アンカー オプションには、DER エンコードされた X.501 名が含まれなければなりません。セクション6.4.3を参照してください。トラスト アンカー オプションが複数ある場合、最初のオプション以降のオプションには、任意のタイプのトラスト アンカーを含めることができます。
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.
このプロトコルの将来のバージョンでは、新しいオプション タイプが定義される可能性があります。受信者は、認識できないオプションを黙って無視し、メッセージの処理を続行しなければなりません (MUST)。含まれるすべてのオプションの長さはゼロより大きくなければなりません。
ICMP length (derived from the IP length) MUST be 8 or more octets.
ICMP 長 (IP 長から導出) は 8 オクテット以上でなければなりません。
Routers send out Certification Path Advertisement messages in response to a Certification Path Solicitation.
ルーターは、証明書パス要請に応じて証明書パス アドバタイズメント メッセージを送信します。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-
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.
受信者の要請ノード マルチキャスト アドレス、またはリンク スコープの全ノード マルチキャスト アドレス。
Hop Limit
ホップ制限
255
255
ICMP Fields:
ICMP フィールド:
Type
タイプ
149
149
Code
コード
0
0
Checksum
チェックサム
The ICMP checksum [6].
ICMP チェックサム [6]。
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 ビットの符号なし整数フィールド。広告と要請を照合するのに役立つ識別子として機能します。識別子フィールドは、全ノードのマルチキャスト アドレスに送信される広告の場合は 0 でなければなりません (MUST)。その他の場合は 0 であってはなりません。
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.
パスに複数の証明書がある場合、IP 層での過度の断片化を避けるために、単一のアドバタイズメントを個別に送信されるコンポーネントに分割する必要があります (SHOULD)。
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.
パス内の個々の証明書は、すべての証明書が到着する前に、受信したままの状態で保存および使用できます (MAY)。これにより、プロトコルの信頼性がわずかに向上し、サービス拒否攻撃の可能性が低くなります。
Examples of packet lengths of Certification Path Advertisement messages for typical certification paths are listed in Appendix C.
一般的な認証パスの認証パス アドバタイズメント メッセージのパケット長の例を付録 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 コンポーネント アドバタイズメントの最初のメッセージの Component フィールドは N-1 に設定され、2 番目のメッセージは N-2 に設定されます。ゼロは、このアドバタイズメントにこれ以上コンポーネントが含まれていないことを示します。
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)。最初の証明書の後に送信された各証明書は、以前に送信された証明書で検証できます。送信者の証明書は最後に来ます。トラストアンカー証明書は送信すべきではありません。
Reserved
予約済み
An unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
未使用のフィールド。これは送信者によってゼロに初期化されなければならず、受信者によって無視されなければなりません。
Valid Options:
有効なオプション:
Certificate
証明書
One certificate is provided in each Certificate option to establish part of a certification path to a trust anchor.
トラスト アンカーへの証明書パスの一部を確立するために、各証明書オプションに 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.
受信者がどの広告が有益であるかを判断できるように、0 個以上のトラスト アンカー オプションを含めることができます。これらのオプションが存在する場合は、マルチコンポーネント アドバタイズメントの最初のコンポーネントに表示されなければなりません。
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.
このプロトコルの将来のバージョンでは、新しいオプション タイプが定義される可能性があります。受信者は、認識できないオプションを黙って無視し、メッセージの処理を続行しなければなりません (MUST)。含まれるすべてのオプションの長さはゼロより大きくなければなりません。
The ICMP length (derived from the IP length) MUST be 8 or more octets.
ICMP 長さ (IP 長さから導出) は 8 オクテット以上でなければなりません。
The format of the Trust Anchor 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 | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 オクテット単位で示します。
Name Type
名前の種類
The type of the name included in the Name field. This specification defines two legal values for this field:
「名前」フィールドに含まれる名前のタイプ。この仕様では、このフィールドに対して 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 フィールドで指定された長さ以内のパディング オクテットの数。パディングオクテットは送信者によってゼロに設定され、受信者によって無視されなければなりません (MUST)。
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].
[名前の種類] フィールドが 1 に設定されている場合、[名前] フィールドにはトラスト アンカーを識別する DER エンコードされた X.501 名が含まれます。値は、[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.
「名前タイプ」フィールドが 2 に設定されている場合、「名前」フィールドにはトラスト アンカーの完全修飾ドメイン名が含まれます。たとえば、「trustanchor.example.com」などです。名前は、RFC 1034 [1] で指定されているように、DNS ワイヤー形式の文字列として保存されます。さらに、RFC 3280 [7] のセクション 4.2.1.7 で説明されている制限が適用されます。
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 の場合、[9] で定義されているように、名前フィールドは「IDN 非認識ドメイン名スロット」です。つまり、ASCII 文字のみを含めることができます。実装は、ToASCII 操作を使用して国際化ドメイン名 (IDN) をサポートしてもよい (MAY)。詳細については、[9] を参照してください。
All systems MUST support the DER Encoded X.501 Name. Implementations MAY support the FQDN name type.
すべてのシステムは、DER エンコードされた X.501 名をサポートしなければなりません。実装では FQDN 名前タイプをサポートしてもよい (MAY)。
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.
「長さ」フィールドで指定されたように、オプションの長さを 8 の倍数にする可変長フィールド。前のフィールドの終了後に始まり、オプションの終わりまで続きます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 オクテット単位のオプションの長さ (タイプ、長さ、証明書タイプ、パッド長、および証明書フィールドを含む)。
Cert Type
証明書の種類
The type of the certificate included in the Certificate field. This specification defines only one legal value for this field:
「証明書」フィールドに含まれる証明書のタイプ。この仕様では、このフィールドの有効な値を 1 つだけ定義します。
1 X.509v3 Certificate, as specified below
以下に指定されている 1 つの X.509v3 証明書
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.
証明書タイプ フィールドが 1 に設定されている場合、セクション 6.3.1 で説明されているように、証明書フィールドには X.509v3 証明書 [7] が含まれます。
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.
オプションの長さを 8 の倍数にする可変長フィールド。前のフィールド [7, 15] の ASN.1 エンコードが終了した後に始まり、長さフィールドで指定されたオプションの終わりまで続きます。
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 で定義されたメッセージ形式に準拠しない受信した認証パス要請メッセージを黙って破棄しなければなりません (MUST)。Reserved フィールドと認識されないオプションの内容は無視しなければなりません (MUST)。将来、プロトコルに対する下位互換性のある変更により、予約フィールドの内容が指定されたり、新しいオプションが追加されたりする可能性があります。下位互換性のない変更では、異なるコード値が使用される場合があります。Router Solicitation メッセージで使用するように指定されていない定義済みオプションの内容は無視されなければならず (MUST)、パケットは通常の方法で処理されます。表示される唯一の定義済みオプションは、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)。要請の送信元アドレスが未指定のアドレスであった場合、ルータはリンクスコープの全ノードマルチキャストアドレスに応答を送信しなければなりません(MUST)。送信元アドレスがユニキャスト アドレスの場合、ルータは、以下で指定するように、負荷がかかっている場合を除き、送信元アドレスに対応する要請ノード マルチキャスト アドレスに応答を送信しなければなりません (MUST)。ルーターは、1 秒以内に MAX_CPA_RATE 回を超える証明書パス アドバタイズメントを送信してはなりません (SHOULD NOT)。さらに要請がある場合、ルーターは、要請に現れた送信元アドレスに関係なく、応答を全ノードのマルチキャスト アドレスに送信する必要があります(SHOULD)。
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.
ルーターは、勧誘されたトラストアンカー (または、要請の Component フィールドが 65,535 に等しくない場合はその一部) への認証パスを確立できるように、アドバタイズメントに適切な証明書オプションを含めるべきです (SHOULD)。パスに複数の証明書がある場合、単一のアドバタイズメントは別々に送信されるコンポーネントに分割され、特定の方法で順序付けされることにも注意してください (セクション 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.
アンカーは、トラスト アンカー オプションによって識別されます。トラスト アンカー オプションが DER エンコードされた X.501 名として表される場合、名前はアンカーの証明書の Subject フィールドと同じである必要があります。トラスト アンカー オプションが FQDN として表される場合、その FQDN はアンカーの証明書の subjectAltName フィールドの FQDN と同じである必要があります。ルータは、証明書パスが見つかったアドバタイズメントにトラスト アンカー オプションを含めるべきです(SHOULD)。
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)。
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 で定義されたメッセージ形式に準拠しない、受信した認証パス広告メッセージを黙って破棄しなければなりません (MUST)。Reserved フィールドの内容と認識されないオプションの内容は無視しなければなりません (MUST)。将来の下位互換性のあるプロトコルへの変更では、Reserved フィールドの内容を指定したり、新しいオプションを追加したりすることができます (MAY)。下位互換性のない変更では、異なるコード値を使用しなければなりません (MUST)。証明書パス広告メッセージで使用するように指定されていない定義済みオプションの内容は無視され、パケットは通常の方法で処理されなければなりません (MUST)。表示される定義済みのオプションは、[証明書] オプションと [トラスト アンカー] オプションのみです。有効性チェックに合格した広告を「有効な広告」と呼びます。
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)。証明書パスは、保存する前に、セクション 6.3 で定義されているように検証されなければなりません (MUST)。ルーターは、パスのトラスト アンカーの終端から始めて証明書を 1 つずつ送信します。
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.
注: メッセージの損失や一時的な目的での並べ替えを許可する場合を除き、ホストは、トラスト アンカーまたは以前に検証された証明書のいずれかに対してすぐに検証できる証明書が含まれていない限り、証明書パス アドバタイズメントで受信した証明書を保存しない場合があります。この措置は、ホストが検証できない証明書を攻撃者がホストに大量に送り込み、証明書を保存するためのメモリを過剰に使用するサービス拒否攻撃を防ぐことを目的としています。
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 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.
ホストのキャッシュ内の証明書からは取得できない公開鍵を含むルーター通知を受信した場合、またはホストのトラスト アンカーの 1 つへの証明書パスがない場合、ホストは証明書パスを取得する必要があります (SHOULD)。このような状況では、ホストはパスを取得するために証明書パス要請メッセージを送信してもよい(MAY)。CPS_RETRY 秒以内に応答がない場合は、メッセージを再試行する必要があります。後続の各再送信の待機間隔は、毎回 2 倍に指数関数的に増加しなければなりません (MUST)。CPS_RETRY_MAX 秒経過しても応答がない場合、ホストは証明書パスの取得プロセスを放棄します。ホストが最初の部分を受信してから CPS_RETRY_FRAGMENTS 秒以内に証明書パスの一部のみを受信した場合、さらに、コンポーネント フィールドを 65,535 以外の値に設定した証明書パス要請メッセージを送信してもよい(MAY)。このメッセージは、最初のメッセージと同じプロセスを使用して再送信できます。欠落している証明書が複数ある場合は、最初の証明書に対する応答を取得した後に追加の 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.
ホストが到達可能なルーターからトラストアンカーまでの現在有効な認証パスを持っている場合、認証パス要請は送信すべきではありません(SHOULD NOT)。
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.
ルーターの証明書を要求する場合、ホストは、デフォルト ルーターがまだ選択されていない場合はオールルーター マルチキャスト アドレスに、デフォルト ルーターが既に選択されている場合はデフォルト ルーターの IP アドレスに証明書パス要求を送信しなければなりません (MUST)。
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 メッセージは受信者の Solicited-Node マルチキャスト アドレスに送信されるべきです (SHOULD)。広告はルーターに対して上記で指定されたように送信されるべきです(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).
要請への応答として送信される可能性のある広告を処理するとき、ホストは、要請と同じ識別子フィールド値を持つそれらの広告を最初に処理することを優先してもよい(MAY)。これにより、このメカニズムに対するサービス拒否攻撃がより困難になります (セクション 9.3 を参照)。
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 Discovery を保護するために、エンド ホストは一連のトラスト アンカーを使用して構成されます。トラスト アンカー設定は次の項目で構成されます。
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 を使用するように設定されている場合、ホストは少なくとも 1 つのトラスト アンカーに関する上記の情報を所有している必要があります (SHOULD)。
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 つの認証パスを使用して構成する必要があります。
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 対応ノードは、自身のアドレスに CGA のみを使用すべきです (SHOULD)。他のタイプのアドレスは、テスト、診断、または他の目的に使用できます。ただし、このドキュメントでは、さまざまな通信に対してさまざまなタイプのアドレスを選択する方法については説明しません。動的な選択は、[21] で定義されているような API によって提供できます。
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 リダイレクト メッセージのターゲット アドレス フィールドと宛先アドレス フィールドが等しい場合、このメッセージは宛先が実際には近隣であることをホストに通知するために使用されます。この場合、受信者は、指定されたアドレスがルーターの証明書で定義された範囲内にあることを確認しなければなりません (MUST)。このチェックに失敗したリダイレクト メッセージは、セクション 7.3 で説明されているように、安全でないものとして扱われなければなりません (MUST)。
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 ルールにより、ホストがリダイレクトで指定された宛先に到達するために使用していないルーターからのリダイレクト メッセージをホストが受け入れることができないことに注意してください。これにより、攻撃者がデフォルト ルーターではない場合に、攻撃者がノードをだましてトラフィックをリダイレクトすることが防止されます。
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.
ルーターの証明書は、安全にアドバタイズできるアドレス範囲を定義します。ただし、ルーターは、認証済みサブネットプレフィックスと未認証サブネットプレフィックスの組み合わせをアドバタイズしてもよい(MAY)。認証されていないサブネット プレフィックスは、セキュリティで保護されていないものとして扱われます (つまり、非 SEND ルーターによって送信されたセキュリティで保護されていないルーター通知と同じ方法で処理されます)。安全でないメッセージの処理は、セクション 8 で規定されています。非 SEND ノードとの相互運用を試みない SEND ノードは、安全でない情報を単純に破棄してもよいことに注意してください。
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.
ルーター広告内のプレフィックス情報オプションを処理する際、証明書にプレフィックス拡張が含まれている場合、ノードはこのオプションで指定されたプレフィックスが証明書で定義された範囲内にあることを検証する必要があります(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.
ノードは、ステートレス自動構成に認定されたサブネット プレフィックスの 1 つを使用する必要があります (SHOULD)。アドバタイズされたサブネット プレフィックスがどれも一致しない場合、ホストは、別のアドバタイズ ルーターが利用可能な場合は、それをデフォルト ルーターとして使用する必要があります (SHOULD)。ノードがステートフル自動構成を実行している場合、DHCP サーバーによって提供されたアドレスを認証されたサブネット プレフィックスと照合する必要があります (SHOULD)。プレフィックスが認証されていない場合は、そのアドレスを使用すべきではありません (SHOULD NOT)。
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 パケットの保護については扱いません。これらのノードには、将来の認証パスベースの認可仕様が必要です。この仕様は、固定インターフェイス識別子 (EUI-64 など) から IPv6 ステートレス アドレス自動構成によって生成されたアドレスにも適用されません。
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 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.
アドレスが動的に変化するノード間でのトラスト アンカー認証の使用について説明することは、この仕様の範囲外です。これらのアドレスは、ステートフルまたはステートレス アドレスの自動構成の結果である場合もあれば、RFC 3041 [17] アドレスの使用の結果である場合もあります。CGA 方式が使用されない場合、ノードは、特定のインターフェイス識別子を持つ IP アドレスの使用をノードに許可する証明書で終わる証明書パスを交換する必要があります。この仕様では、これらの証明書の形式は指定していません。これは、現時点ではリンク層によって証明書が提供されるケースはほとんどなく、インターフェイス識別子の証明書を提供するかどうかはリンク層次第であるためです。これは将来の仕様の主題となる可能性があります。また、ステートフル アドレス自動構成が 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.
近隣アドバタイズメントのターゲット アドレスは、この仕様でサポートされていないプロキシ近隣探索を除き、パケットのソース アドレスと等しい必要があります。
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 をサポートするノードは、保護された NDP メッセージと保護されていない NDP メッセージの使用を同時にサポートする必要があります (SHOULD)。
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)。これを使用して、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 の使用を完全に無効にする設定オプションがあってもよい (MAY)。この設定オプションはデフォルトではオフにすべきです。つまり、SEND が使用されます。プレーン (非 SEND) NDP ノードは、明らかに、セキュリティで保護されていないメッセージのみを送信します。RFC 2461 [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 ノードによって送信されるすべての要請は保護されなければなりません (MUST)。
o Unsolicited advertisements sent by a SEND node MUST be secured.
o SEND ノードによって送信される一方的な広告は保護されなければなりません (MUST)。
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 ノードは、安全な要請に応じて安全な広告を送信しなければなりません (MUST)。安全でない要請に応じて送信される広告も同様に安全でなければなりません (MUST) が、Nonce オプションを含めてはなりません (MUST NOT)。
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 CGA 認証方式を使用して近隣要請を保護する SEND ノードは、次のように重複アドレス検出を実行する必要があります (SHOULD)。重複アドレス検出により、仮アドレスが既に使用されていることが示された場合、ノードは新しい仮 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].)
最初の仮アドレスに対して重複アドレス検出を実行する場合、ノードは、セキュリティ保護されたおよびセキュリティ保護されていない近隣通知と、近隣要請に応答して受信した要請の両方を受け入れます。2 番目または 3 番目の仮アドレスに対して重複アドレス検出を実行する場合、安全でない近隣アドバタイズメントと要請は無視されます。(これによるセキュリティへの影響については、セクション 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 ノードは、最初の仮アドレスに対して重複アドレス検出を実行する場合でも、安全でない通知を無視する設定オプションを持っていてもよい(MAY)。この設定オプションはデフォルトで無効にする必要があります。これは、最初のアドレスに対する攻撃が多発した場合の回復メカニズムです。
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 近隣キャッシュ、プレフィックス リスト、およびデフォルト ルーター リストのエントリには、エントリの作成または最終更新の原因となったメッセージが保護されているか保護されていないかを示す保護/非保護フラグがなければなりません (MUST)。受信した保護されていないメッセージによって、近隣キャッシュ、プレフィックス リスト、またはデフォルト ルーター リスト内の既存の保護されたエントリが変更されてはなりません (MUST NOT)。受信した保護されたメッセージは、一致するエントリの更新を引き起こさなければならず (MUST)、保護されているというフラグが立てられなければなりません (MUST)。
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 で保護されていない場合、近隣到達不能検出 (NUD) を目的とした近隣要請は、その近隣の要請ノードのマルチキャスト アドレスに送信されなければなりません (MUST)。
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 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.
セキュリティで保護されていない近隣キャッシュ エントリに対する上位層の確認は、近隣キャッシュ エントリが以前に REACHABLE であったことがない場合、SEND ノード上の近隣キャッシュの状態を STALE から REACHABLE に更新すべきではありません (SHOULD NOT)。これにより、有効な SEND ホストを偽装するエントリが非 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).
その結果、混合モードでは、(a) SEND ノードが被害者ノードと通信しておらず、安全なエントリが存在しない場合にのみ、攻撃者は 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 ノードは、安全でないメッセージを送信するルータ、または安全なメッセージは受信したが、セキュリティチェックが進行中であるが完全なセキュリティチェックがまだ完了していないルータを採用してもよい(MAY)。この場合のセキュリティ チェックには、証明書パスの要求、証明書の検証、CRL チェック、および RA 署名チェックが含まれます。ノードは、安全であることがわかっているルータが到達不能になった場合に、安全でないメッセージを送信するルータを採用してもよい(MAY)が、到達不能は攻撃の結果である可能性があるため、できるだけ早く安全であることがわかっているルータを見つけることを試みるべきである(SHOULD)。これにより、新しいネットワークへの接続が高速化されますが、セキュリティで保護されていないメッセージを送信しているルーター、またはセキュリティ チェックが完了していないルーターを受け入れると、ノードが攻撃を受ける可能性があることに注意してください。このようなルーターを受け入れることを選択したノードは、自らの責任で受け入れます。いずれの場合でも、ノードは、セキュリティチェックが完了したルータが利用可能になり次第、安全であることがわかっているルータを優先すべきである(SHOULD)。
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 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.
SEND では、リンク層フレーム アドレスと IPv6 アドレスの間に暗号バインディングが存在しない可能性があります。リンク層が安全でない場合、ノードが他のノードのリンク層アドレスを偽装できる可能性があります。攻撃者は、フレーム上のリンク層ソース アドレスを被害者のソース アドレスとして設定し、有効な CGA アドレスとそれ自体に対応する有効な署名、および被害者に対応するターゲット リンク層アドレス拡張子。その後、攻撃者は 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 ではリンク層上のアドレスと近隣通知が一致している必要はありません。ただし、リンク層テクノロジーが許可する場合は、これらのチェックを実行することが推奨されます。
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.
近隣探索および重複アドレス検出に参加する前に、ノードは、アドレスとして主張しているアドレスについて、リンクスコープの全ノード マルチキャスト グループおよび要請ノード マルチキャスト グループにサブスクライブする必要があります。RFC 2461 [4]。マルチキャスト グループに加入するには、ノードが MLD [16] を使用する必要があります。MLD にはセキュリティに関する規定は含まれていません。攻撃者は、MLD Done メッセージを送信して、被害者を要請ノード マルチキャスト アドレスから登録解除する可能性があります。ただし、ルータはマルチキャスト アドレス固有のクエリを送信してそのアドレス上にまだリスナーがいるかどうかを判断するため、被害者はこの攻撃を検出できるはずです。その時点で被害者は応答してグループからの脱落を回避できます。この手法は、リンク上のルータが侵害されていない場合に機能します。MLD を使用した他の攻撃も可能ですが、それらは主に無関係な (ただし、必ずしも圧倒的ではない) トラフィックを引き起こします。
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 プロトコルは、[22] で概説されているように、NDP に対する脅威に対抗するように設計されています。次のサブセクションには、脅威に対する SEND プロトコルの回帰が含まれており、プロトコルのどの側面が各脅威に対抗するかを示します。
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 で定義されています。脅威は、なりすましメッセージがノードの近隣キャッシュに誤ったエントリを引き起こす可能性があることです。次の 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. 近隣要請またはルーター要請の副作用として作成されるエントリ。ターゲット リンク層アドレス拡張子と、未指定のアドレスと異なる IPv6 送信元アドレスを持つルーター要請を受信したルーターは、IPv6 アドレスのエントリを近隣キャッシュに挿入します。また、重複アドレス検出 (DAD) を実行しているノードは、同じアドレスに対する近隣要請を受信すると、その状況を衝突とみなし、そのアドレスの要請を停止します。
In either case, SEND counters these threats by requiring that the RSA Signature and CGA options be present in these solicitations.
いずれの場合も、SEND は、これらの要求に RSA 署名と CGA オプションが存在することを要求することで、これらの脅威に対抗します。
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 オプションを含むルーター要請メッセージを送信できます。ルーターはこれを検証して、近隣キャッシュ バインディングが正しいかどうかを確認できます。SEND ノードが未指定のアドレスでルーター要請を送信する必要がある場合、ルーターは基本 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. 近隣通知メッセージの結果として作成されたエントリ。SEND は、これらのアドバタイズメントに RSA 署名と CGA オプションが存在することを要求することで、この脅威に対抗します。
Also see Section 9.2.5, below, for discussion about replay protection and timestamps.
リプレイ保護とタイムスタンプについては、以下のセクション 9.2.5 も参照してください。
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 で説明されています。SEND は、NUD プローブとして送信された近隣要請に応答するノードに、RSA 署名オプションと、プローブされるアドレス内のインターフェイス識別子を使用するための認可の証明を含めることを要求することで、これに対抗します。これらの前提条件が満たされていない場合、NUD を実行するノードは応答を破棄します。
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 で説明されています。SEND は、DAD への応答として送信される近隣通知に RSA 署名オプションと、テスト対象のアドレス内のインターフェイス識別子を使用するための認可の証明を含めることを要求することで、この攻撃に対抗します。これらの前提条件が満たされていない場合、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 ノードの間でアドレス衝突が発生する可能性を犠牲にして、非 SEND ノードまたは非 SEND ノードをシミュレートする攻撃者による DAD DoS 攻撃から SEND ノードが保護されます。このようなアドレス衝突の確率と影響については、[11] で説明されています。
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 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.
これらの攻撃については、[22] のセクション 4.2.1、4.2.4、4.2.5、4.2.6、および 4.2.7 で説明されています。SEND は、ルーター アドバタイズメントに RSA 署名オプションが含まれていること、およびプレフィックス情報オプションに含まれるサブネット プレフィックスをルーティングする権限を証明できるノードの公開キーを使用して署名が計算されることを要求することで、これらに対抗します。ルーターは、特定のプレフィックスを含む証明書、またはルーターが任意のプレフィックスのルーティングを許可されていることを示すことによって、その承認を証明します。これらの保護のないルーター アドバタイズメントは破棄されます。
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 は、[22] のセクション 4.4.2 および 4.4.3 で説明されているように、DoS 攻撃などのルータに対するブルート フォース攻撃やルータの侵害に対しては保護しません。
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 で説明されています。SEND は、要請に Nonce オプションを含め、アドバタイズメントに一致するオプションが含まれることを要求することにより、ルーター要請/ルーター アドバタイズメントおよび近隣要請/近隣アドバタイズメントのトランザクションにおける攻撃から保護します。これは署名とともに、チャレンジ/レスポンス プロトコルを形成します。
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 は、タイムスタンプ オプションを含めることにより、近隣アドバタイズメント、ルーター アドバタイズメント、リダイレクトなどの一方的なメッセージからの攻撃を防ぎます。次のセキュリティ問題は、迷惑メッセージにのみ関係します。
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 ノードは、タイムスタンプを含むメッセージによって作成された状態をキャッシュしている限り、リプレイ攻撃からも保護されます。キャッシュされた状態により、ノードは再生されたメッセージからノード自体を保護できます。ただし、何らかの理由でノードが状態をフラッシュすると、攻撃者はタイムスタンプがまだ有効な間に古いメッセージを再生することで状態を再作成する可能性があります。セクション 5.3.1 で説明したように、ほとんどの SEND ノードはかなり粗いタイムスタンプを使用する可能性が高いため、これは一部のノードに影響を与える可能性があります。
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 recommended that SEND nodes keep independently maintained clocks or apply suitable security measures for the time synchronization protocols.
o NTP [23] などの時刻同期プロトコルに対する攻撃により、SEND ノードに不正なタイムスタンプ値が与えられる可能性があります。これは、通常の脆弱性の範囲外であっても、リプレイ攻撃を開始するために使用される可能性があります。これらの攻撃から保護するために、SEND ノードが独立して維持されるクロックを維持するか、時刻同期プロトコルに適切なセキュリティ対策を適用することをお勧めします。
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 で説明されています。その中で、攻撃者はリンク上の架空のアドレスに向けてパケットをルーターに大量に送り込み、存在しないアドレスに対して近隣要請を実行することでルーター自体をビジー状態にさせます。SEND はこの脅威には対処しません。この脅威は、近隣要請のレート制限、未解決の要請用に予約される状態の量の制限、賢明なキャッシュ管理などの技術によって対処できるためです。これらはすべて、ルーター上で近隣探索を実装する際に必要なテクニックです。
The CGAs have a 59-bit hash value. The security of the CGA mechanism has been discussed in [11].
CGA には 59 ビットのハッシュ値があります。CGA メカニズムのセキュリティについては、[11] で議論されています。
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 保護が使用されている場合、SEND はセクション 5.2.2 で説明されている検証プロセスを使用して 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 でのアドレス検証にトラスト アンカーと証明書が使用される場合、防御はそれほど効果的ではありません。実装は、RSA 署名オプションで受信したパケットの処理に費やされたリソースを追跡し、あまりにも多くのリソースが消費された場合に選択的にパケットの破棄を開始する必要があります (SHOULD)。実装は、CGA で保護されていないパケットを最初に破棄してもよい (MAY)。
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 responses) and by limiting the number of different discovery processes in which they engage.
認可委任の検出プロセスも、サービス拒否攻撃に対して脆弱になる可能性があります。攻撃は、さまざまなトラスト アンカーに対する多数の証明書パスの検出を要求することにより、ルーターをターゲットにする可能性があります。ルーターは、発見された情報 (否定的な応答を含む) をキャッシュし、関与するさまざまな発見プロセスの数を制限することによって、このような攻撃を防御すべきです (SHOULD)。
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)。
Host constants:
ホスト定数:
CPS_RETRY 1 second
CPS_RETRY_FRAGMENTS 2 seconds
CPS_RETRY_MAX 15 seconds
Router constants:
ルーター定数:
MAX_CPA_RATE 10 times per second
MAX_CPA_RATE 1 秒あたり 10 回
TIMESTAMP_DELTA 300 seconds (5 minutes)
TIMESTAMP_FUZZ 1 second
TIMESTAMP_DRIFT 1 % (0.01)
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:
この文書では、認可委任の検出で使用される 2 つの新しい ICMP メッセージ タイプを定義します。これらのメッセージには、情報メッセージ範囲の ICMPv6 タイプ番号を割り当てる必要があります。
o The Certification Path Solicitation message (148), described in Section 6.4.1.
o 認証パス要請メッセージ (148)。セクション 6.4.1 で説明されています。
o The Certification Path Advertisement message (149), described in Section 6.4.2.
o 認証パス広告メッセージ (149)。セクション 6.4.2 で説明されています。
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 つの新しい近隣探索プロトコル [4] オプションを定義します。これらのオプションには、近隣探索プロトコル メッセージのオプション番号付けスペース内のオプション タイプ値を割り当てる必要があります。
o The CGA option (11), described in Section 5.1.
o CGA オプション (11) (セクション 5.1 で説明)。
o The RSA Signature option (12), described in Section 5.2.
o RSA 署名オプション (12) (セクション 5.2 で説明)。
o The Timestamp option (13), described in Section 5.3.1.
o タイムスタンプ オプション (13) (セクション 5.3.1 で説明)。
o The Nonce option (14), described in Section 5.3.2.
o Nonce オプション (14) (セクション 5.3.2 で説明)。
o The Trust Anchor option (15), described in Section 6.4.3.
o トラスト アンカー オプション (15) (セクション 6.4.3 で説明)。
o The Certificate option (16), described in Section 6.4.4.
o 証明書オプション (16) (セクション 6.4.4 で説明)。
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] 名前空間で新しい 128 ビット値、0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08 を定義します。
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
このドキュメントでは、[トラスト アンカー] オプションの [名前の種類] フィールドの新しい名前空間を定義します。このフィールドの将来の値は、標準アクション [3] を使用して割り当てることができます。このフィールドの現在の値は次のとおりです。
1 DER Encoded X.501 Name
1 DER エンコードされた X.501 名
2 FQDN
2 完全修飾ドメイン名
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
別の新しい名前空間が、「証明書」オプションの「証明書タイプ」フィールドに割り当てられます。このフィールドの将来の値は、標準アクション [3] を使用して割り当てることができます。このフィールドの現在の値は次のとおりです。
1 X.509v3 Certificate
1 X.509v3 証明書
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris, P.、「ドメイン名 - 概念と機能」、STD 13、RFC 1034、1987 年 11 月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、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. Alvestruct、「RFC で IANA 考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、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. Simpson、「IP バージョン 6 (IPv6) の近隣探索」、RFC 2461、1998 年 12 月。
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[5] Thomson, S. および T. Narten、「IPv6 ステートレス アドレス自動構成」、RFC 2462、1998 年 12 月。
[6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[6] Conta、A.、S. Deering、「インターネット プロトコル バージョン 6 (IPv6) 仕様のインターネット コントロール メッセージ プロトコル (ICMPv6)」、RFC 2463、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.、Polk, W.、Ford, W.、および D. Solo、「インターネット X.509 公開鍵インフラストラクチャ証明書および証明書失効リスト (CRL) プロファイル」、RFC 3280、2002 年 4 月。
[8] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[8] Farrell, S. および R. Housley、「認可のためのインターネット属性証明書プロファイル」、RFC 3281、2002 年 4 月。
[9] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[9] Faltstrom, P.、Hoffman, P.、および A. Costello、「アプリケーションにおけるドメイン名の国際化 (IDNA)」、RFC 3490、2003 年 3 月。
[10] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[10] Lynn, C.、Kent, S.、および K. Seo、「X.509 Extensions for IP Addresses and AS Identifiers」、RFC 3779、2004 年 6 月。
[11] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[11] Aura, T.、「Cryptographically Generated Addresses (CGA)」、RFC 3972、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] 国際電気通信連合、「情報技術 - 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 Laboratories、「RSA 暗号化標準バージョン 2.1」、PKCS 1、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 PUB 180-1、1995 年 4 月、<http://www.itl.nist.gov/fipspubs/fip180-1.htm>。
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[15] Harkins, D. および D. Carrel、「インターネット鍵交換 (IKE)」、RFC 2409、1998 年 11 月。
[16] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[16] Deering, S.、Fenner, W.、および B. Haberman、「IPv6 のマルチキャスト リスナー検出 (MLD)」、RFC 2710、1999 年 10 月。
[17] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[17] Narten, T. および R. Draves、「IPv6 におけるステートレス アドレス自動構成のためのプライバシー拡張」、RFC 3041、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.、Bound, J.、Volz, B.、Lemon, T.、Perkins, C.、および M. Carney、「IPv6 の動的ホスト構成プロトコル (DHCPv6)」、RFC 3315、2003 年 7 月。
[19] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", Work in Progress, March 2003.
[19] Arkko, J.、「IKE および IPsec ポリシーに対する ICMPv6 の影響」、進行中の作業、2003 年 3 月。
[20] Arkko, J., "Manual SA Configuration for IPv6 Link Local Messages", Work in Progress, June 2002.
[20] Arkko, J.、「IPv6 リンク ローカル メッセージの手動 SA 構成」、進行中の作業、2002 年 6 月。
[21] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API for Address Selection", Work in Progress, October 2003.
[21] Nordmark, E.、Chakrabarti, S.、および J. Laganier、「アドレス選択のための IPv6 ソケット API」、進行中の作業、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.、Kempf, J.、および E. Nordmark、「IPv6 近隣探索 (ND) 信頼モデルと脅威」、RFC 3756、2004 年 5 月。
[23] Bishop, M., "A Security Analysis of the NTP Protocol", Sixth Annual Computer Security Conference Proceedings, December 1990.
[23] Bishop, M.、「NTP プロトコルのセキュリティ分析」、第 6 回年次コンピュータ セキュリティ会議議事録、1990 年 12 月。
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 で移行メカニズムの仕様を提供しました。Jonathan 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.
著者らはまた、Tuomas Aura、Bill Sommerfeld、Erik Nordmark、Gabriel Montenegro、Pasi Aeronen、Greg Daley、Jon Wood、Julien Laganier、Francis Dupont、Pekka Savola、Wenxiao He、Valtteri Niemi、Mike Roe、Russ Housley、Thomas に感謝します。Narten と Steven Bellovin には、この問題分野での興味深い議論と SEND プロトコルに関するフィードバックを提供していただきました。
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 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.
新しいエントリと古いエントリに別々のキャッシュ スペースを設けるのが合理的です。攻撃を受けた場合、新しくキャッシュされたエントリはより簡単に削除されます。トラフィックを追跡し、本物のトラフィックを受信する適切な新しいエントリのみを古いキャッシュ エントリに変換できるようにすることもできます。このような計画により攻撃はより困難になりますが、完全に防ぐことはできません。たとえば、攻撃者は各 NS の後に少量のトラフィック (つまり、ping または TCP syn) を送信して、被害者をだましてそのキャッシュ エントリを古いキャッシュに昇格させる可能性があります。これに対抗するために、ノードは単に黒/白の新旧境界を持つ場合よりも、よりインテリジェントにキャッシュ エントリを保持できます。
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 パラメータを持つエントリを優先的に保持することで、キャッシュ エントリを強制的に排除するときに Sec パラメータと CGA パラメータを区別することも可能なアプローチであると思われます。これは、より高い Sec パラメータを持つ CGA はなりすましが難しいためです。
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 で認可委任検出テストの実行が行われました。トラスト アンカーの証明書は双方がすでに知っているため、証明書パス アドバタイズメント メッセージを使用して 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 つの証明書パス アドバタイズメント メッセージは、イーサネット リンク層上で 1,050 ～ 1,066 バイトの範囲にありました。証明書自体がパケットの大部分を占めます。残りは、トラスト アンカー オプション、ICMP ヘッダー、IPv6 ヘッダー、およびリンク層ヘッダーです。
Authors' Addresses
著者の住所
Jari Arkko Ericsson Jorvas 02420 Finland
ヤリ・アルコ・エリクソン・ジョルバス 02420 フィンランド
EMail: jari.arkko@ericsson.com
James Kempf DoCoMo Communications Labs USA 181 Metro Drive San Jose, CA 94043 USA
James Kempf DoCoMo Communications Labs USA 181 Metro Drive San Jose, CA 94043 USA
EMail: kempf@docomolabs-usa.com
Brian Zill Microsoft Research One Microsoft Way Redmond, WA 98052 USA
Brian Zill Microsoft Research One Microsoft Way Redmond, WA 98052 USA
EMail: bzill@microsoft.com
Pekka Nikander Ericsson Jorvas 02420 Finland
ペッカ ニカンデル エリクソン ジョルバス 02420 フィンランド
EMail: Pekka.Nikander@nomadiclab.com
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2005).
著作権 (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.
この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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 は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを示すものでもありません。RFC 文書の権利に関する手順に関する情報は、BCP 78 および BCP 79 に記載されています。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ http://www.ietf.org/ipr から。
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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。