[要約] 要約：RFC 5909は、ネイバー・ディスカバリー・プロキシのセキュリティに関する問題を議論しています。 目的：このRFCの目的は、ネイバー・ディスカバリー・プロキシのセキュリティ上の脆弱性を特定し、それに対する解決策を提案することです。
Internet Engineering Task Force (IETF) J-M. Combes
Request for Comments: 5909 France Telecom Orange
Category: Informational S. Krishnan
ISSN: 2070-1721 Ericsson
G. Daley
Netstar Logicalis
July 2010
Securing Neighbor Discovery Proxy: Problem Statement
近隣発見プロキシの保護：問題のステートメント
Abstract
概要
Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf.
Neighbor Discoveryプロキシは、リンクに存在しなくなったノードのリンク上のアドレスの存在を提供するために使用されます。彼らは、ノードがそのアドレスに向けられたパケットを受信し、別のデバイスがその代わりに近隣発見操作を実行できるようにすることで、そのアドレスに向けられたパケットを受信できます。
Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages.
Neighbor Discovery Proxyは、モバイルノードが自宅にいない場合、ホームエージェントがプロキシとして機能できるようにすることにより、モバイルIPv6および関連プロトコルで使用されます。また、グローバルプレフィックスが複数のリンクに及ぶことを可能にするメカニズムとしても使用されます。ここでは、プロキシは近隣発見メッセージのリレーとして機能します。
Neighbor Discovery Proxy currently cannot be secured using Secure Neighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND.
近隣のディスカバリープロキシは現在、Secure Neighbor Discovery（送信）を使用して保護できません。本日、送信は、アドレスを宣伝するノードが住所所有者であり、そのノードに適切な公開キーとプライベートキーを所有していると仮定しています。このドキュメントでは、Proxy Neighbor Discoveryの既存の慣行が送信にどのように関連しているかについて説明します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5909.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5909で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy . . . . . . 4
2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy . . . . . . 6
2.3. Bridge-Like ND Proxies . . . . . . . . . . . . . . . . . . 6
3. Proxy Neighbor Discovery and SEND . . . . . . . . . . . . . . 9
3.1. CGA Signatures and Proxy Neighbor Discovery . . . . . . . 9
3.2. Non-CGA Signatures and Proxy Neighbor Discovery . . . . . 10
3.3. Securing Proxy DAD . . . . . . . . . . . . . . . . . . . . 11
3.4. Securing Router Advertisements . . . . . . . . . . . . . . 11
4. Potential Approaches to Securing Proxy ND . . . . . . . . . . 12
4.1. Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . 12
4.1.1. Mobile IPv6 and Router-Based Authorization . . . . . . 13
4.1.2. Mobile IPv6 and Per-Address Authorization . . . . . . 13
4.1.3. Cryptographic-Based Solutions . . . . . . . . . . . . 13
4.1.4. Solution Based on the 'Point-to-Point' Link Model . . 14
4.2. Secured Proxy ND and Bridge-Like Proxies . . . . . . . . . 14
4.2.1. Authorization Delegation . . . . . . . . . . . . . . . 14
4.2.2. Unauthorized Routers and Proxies . . . . . . . . . . . 14
4.2.3. Multiple Proxy Spans . . . . . . . . . . . . . . . . . 15
4.2.4. Routing Infrastructure Delegation . . . . . . . . . . 15
4.2.5. Local Delegation . . . . . . . . . . . . . . . . . . . 16
4.2.6. Host Delegation of Trust to Proxies . . . . . . . . . 17
4.3. Proxying Unsecured Addresses . . . . . . . . . . . . . . . 17
5. Two or More Nodes Defending the Same Address . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Router Trust Assumption . . . . . . . . . . . . . . . . . 19
6.2. Certificate Transport . . . . . . . . . . . . . . . . . . 19
6.3. Timekeeping . . . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Neighbor Discovery Proxy is defined in IPv6 Neighbor Discovery [RFC4861]. It is used in networks where a prefix has to span multiple links [RFC4389] but also in Mobile IPv6 [RFC3775] (and so in Mobile-IPv6-based protocols like Network Mobility (NEMO) [RFC3963], Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5568], or Hierarchical Mobile IPv6 (HMIPv6) [RFC5380]) and in the Internet Key Exchange Protocol (IKE) version 2 (IKEv2) [RFC4306]. It allows a device that is not physically present on a link to have another advertise its presence, and forward packets to the off-link device.
Neighbor Discovery Proxyは、IPv6 Neighbor Discovery [RFC4861]で定義されています。接頭辞が複数のリンク[RFC4389]に及ぶ必要があるネットワークで使用されますが、モバイルIPv6 [RFC3775]（また、ネットワークモビリティ（NEMO）[RFC3963]などのモバイル-IPV6ベースのプロトコルでも使用されます。fmipv6）[rfc5568]、または階層モバイルIPv6（hmipv6）[rfc5380]）およびインターネットキーエクスチェンジプロトコル（IKE）バージョン2（IKEV2）[RFC4306]。リンクに物理的に存在しないデバイスが、別の存在を宣伝し、オフリンクデバイスにパケットを転送するデバイスを許可します。
Neighbor Discovery Proxy relies upon another device, the proxy, to monitor for Neighbor Solicitations (NSs), and answer with Neighbor Advertisements (NAs). These proxy Neighbor Advertisements direct data traffic through the proxy. Proxied traffic is then forwarded to the end destination.
Neighbor Discovery Proxyは、別のデバイスであるプロキシに依存して、近隣の勧誘（NSS）を監視し、Neighbor Advertisements（NAS）で回答します。これらのプロキシネイバー広告は、プロキシを介してデータトラフィックを向けます。その後、プロキシされたトラフィックはエンド宛先に転送されます。
This section describes the different scenarios where the interaction between Secure Neighbor Discovery (SEND) and ND Proxy raises issues.
このセクションでは、安全な近隣発見（送信）とNDプロキシの間の相互作用が問題を提起するさまざまなシナリオについて説明します。
The goal of IPv6 mobility is to allow nodes to remain reachable while moving around in the IPv6 Internet. The following text is focused on Mobile IPv6 but the issue raised by the interaction between SEND and ND Proxy may be the same with Mobile IPv6 based protocols (e.g., NEMO, HMIPv6).
IPv6モビリティの目標は、IPv6インターネットで動き回っている間、ノードが到達可能なままにすることです。次のテキストはモバイルIPv6に焦点を当てていますが、送信とNDプロキシの間の相互作用によって提起された問題は、モバイルIPv6ベースのプロトコル（NEMO、HMIPV6など）で同じである可能性があります。
For Mobile IPv6 Mobile Nodes (MNs), it is necessary to keep existing sessions going or to allow new sessions even when one leaves the home network.
モバイルIPv6モバイルノード（MNS）の場合、ホームネットワークを離れても、既存のセッションを維持し続けるか、新しいセッションを許可する必要があります。
In order to continue existing sessions, when nodes are present on the home link, the Proxy (i.e., the Home Agent in Mobile IPv6) sends an unsolicited NA to the all-nodes multicast address on the home link as specified [RFC3775].
既存のセッションを継続するために、ホームリンクにノードが存在する場合、プロキシ（つまり、モバイルIPv6のホームエージェント）は、指定された[RFC3775]のように、ホームリンクのオールノードマルチキャストアドレスに未承諾NAを送信します。
For new sessions, the Proxy, which listens to the MN's address responds with a Neighbor Advertisement that originates at its own IPv6 address and has the proxy's address as the Target Link-Layer Address, but contains the absent mobile in the Target Address field of the Neighbor Advertisement. In this case, SEND cannot be applied because the address in the Target Address field is not the same as the one in the Source Address field of the IP header.
新しいセッションの場合、MNのアドレスに耳を傾けるプロキシは、独自のIPv6アドレスに由来する近隣広告で応答し、ターゲットリンク層アドレスとしてプロキシのアドレスを持っていますが、ターゲットアドレスのターゲットアドレスフィールドに不在のモバイルが含まれています。近隣の広告。この場合、ターゲットアドレスアドレスフィールドのアドレスがIPヘッダーのソースアドレスフィールドのアドレスと同じではないため、送信は適用できません。
As seen in Figure 1, solicitors send a multicast solicitation to the solicited nodes multicast address (based on the unicast address) of the absent node (a mobile node that is away from the home link).
図1に見られるように、弁護士は、不在ノード（ホームリンクから離れているモバイルノード）の勧誘されたノードマルチキャストアドレス（ユニキャストアドレスに基づく）にマルチキャスト勧誘を送信します。
Absent Mobile Proxy Solicitor
モバイル代理人の不在
NS:SL3=S,DL3=Sol(A),TA=A
+-----+ SL2=s,DL2=sol(a),SLL=s
| |<================
| |
| |================>
+-----+ NA:SL3=P,DL3=S,TA=A,
SL2=p,DL2=s,TLL=p
Legend:
SL3: Source IPv6 Address NS: Neighbor Solicitation
DL3: Destination IPv6 Address NA: Neighbor Advertisement
SL2: Source Link-Layer Address RS: Router Solicitation
DL2: Destination Link-Layer Address RA: Router Advertisement
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Figure 1
図1
While at home, if the MN has configured Cryptographically Generated Addresses (CGAs) [RFC3972], it can secure establishment by its on-link neighbors of Neighbor Cache Entries (NCEs) for its CGAs by using SEND [RFC3971]. SEND security requires a node sending Neighbor Advertisements for a given address to be in possession of the public/ private key pair that generated the address.
自宅にいる間、MNが暗号化されたアドレス（CGA）[RFC3972]を構成している場合、Send [RFC3971]を使用して、CGAの近隣キャッシュエントリ（NCES）のオンリンクネイバーによる確立を確保できます。セキュリティを送信するには、指定されたアドレスの近隣広告を送信するノードが必要です。
When an MN moves away from the home link, a proxy has to undertake Neighbor Discovery signaling on behalf of the MN. In Mobile IPv6, the role of the proxy is undertaken by the Home Agent. While the Home Agent has a security association with the MN, it does not have access to the public/private key pair used to generate the MN's CGA. Thus, the Home Agent acting as an ND proxy cannot use SEND for the address it is proxying [RFC3971].
MNがホームリンクから離れて移動すると、プロキシはMNに代わって近隣発見シグナリングを行う必要があります。モバイルIPv6では、プロキシの役割はホームエージェントによって行われます。ホームエージェントはMNとセキュリティ関連を持っていますが、MNのCGAを生成するために使用されるパブリック/プライベートキーペアにはアクセスできません。したがって、NDプロキシとして機能するホームエージェントは、プロキシであるアドレスに送信を使用できません[RFC3971]。
When an MN moves from the home network to a visited network, the proxy will have to override the MN's existing Neighbor Cache Entries that are flagged as secure [RFC3971]. This is needed for the Home Agent to intercept traffic sent on-link to the MN that would otherwise be sent to the MN's link-layer address.
MNがホームネットワークから訪問されたネットワークに移動すると、プロキシは、安全であるとフラグが付けられたMNの既存の近隣キャッシュエントリをオーバーライドする必要があります[RFC3971]。これは、ホームエージェントがMNのリンク層アドレスに送信されるMNにリンク上のトラフィックを傍受するために必要です。
With the current SEND specification, any solicitation or advertisement sent by the proxy will be unsecure and thus will not be able to update the MN's NCE for the home address because it is flagged as secured. These existing Neighbor Cache Entries will only time-out after Neighbor Unreachability Detection [RFC4861] concludes the Home Address is unreachable at the link layer recorded in the NCE.
現在の送信仕様では、プロキシによって送信される勧誘または広告は安全ではないため、セキュリティとフラグが付けられているため、自宅の住所のMNのNCEを更新することはできません。これらの既存の近隣キャッシュエントリは、近隣の到達不能検出[RFC4861]がNCEに記録されたリンク層ではホームアドレスが到達できないと結論付けた後にのみタイムアウトします。
Where secured proxy services are not able to be provided, a proxy's advertisement may be overridden by a rogue proxy without the receiving host realizing that an attack has occurred. This is identical to what happens in a network where SEND is not deployed.
セキュリティで保護されたプロキシサービスを提供できない場合、攻撃が発生したことを認識して、受信ホストが発生することなく、プロキシの広告が不正なプロキシによってオーバーライドされる場合があります。これは、送信が展開されていないネットワークで起こることと同じです。
This scenario is a sub-case of the previous one. In this scenario, the IPv6 node will never be on the link where the ND messages are proxied. For example, an IPv6 node gains remote access to a network protected by a security gateway that runs IKEv2 [RFC4306]. When a node needs an IP address in the network protected by a security gateway, the security gateway assigns an address dynamically using Configuration Payload during IKEv2 exchanges. The security gateway then needs to receive packets sent to this address; one way to do so would be to proxy ND messages.
このシナリオは、前のシナリオのサブケースです。このシナリオでは、IPv6ノードがNDメッセージがプロキシ化されるリンクにはありません。たとえば、IPv6ノードは、IKEV2 [RFC4306]を実行するセキュリティゲートウェイによって保護されているネットワークへのリモートアクセスを獲得します。ノードがセキュリティゲートウェイによって保護されているネットワーク内のIPアドレスが必要な場合、セキュリティゲートウェイは、IKEV2交換中に構成ペイロードを使用してアドレスを動的に割り当てます。セキュリティゲートウェイは、このアドレスに送信されたパケットを受信する必要があります。これを行う1つの方法は、メッセージとメッセージをプロキシすることです。
The Neighbor Discovery (ND) Proxy specification [RFC4389] defines an alternative method to classic bridging. Just as with classic bridging, multiple link-layer segments are bridged into a single segment, but with the help of proxying at the IP layer rather than link-layer bridging. In this case, the proxy forwards messages while modifying their source and destination MAC addresses, and it rewrites their solicited and override flags and Link-Layer Address Options.
Neighbor Discovery（ND）プロキシ仕様[RFC4389]は、クラシックブリッジングの代替方法を定義します。古典的なブリッジングと同様に、複数のリンク層セグメントが単一のセグメントにブリッジされていますが、リンク層ブリッジングではなくIPレイヤーでプロキシするのに役立ちます。この場合、プロキシはソースと宛先MACアドレスを変更しながらメッセージを転送し、勧誘およびオーバーライドフラグとリンクレイヤーアドレスオプションを書き直します。
This rewriting is incompatible with SEND signed messages for a number of reasons:
この書き換えは、いくつかの理由で送信された署名されたメッセージと互換性がありません。
o Rewriting elements within the message will break the digital signature.
o メッセージ内の要素を書き換えると、デジタル署名が破損します。
o The source IP address of each packet is the packet's origin, not the proxy's address. The proxy is unable to generate another signature for this address, as it doesn't have the CGA private key [RFC3971].
o 各パケットのソースIPアドレスは、プロキシのアドレスではなく、パケットの起源です。プロキシは、CGA秘密キー[RFC3971]がないため、このアドレスの別の署名を生成することができません。
Thus, proxy modification of SEND solicitations may require sharing of credentials between the proxied node and the proxying node or creation of new options with proxying capabilities.
したがって、送信勧誘のプロキシ変更では、プロキシノードとプロキシノード間の資格情報の共有、またはプロキシ機能を備えた新しいオプションの作成が必要になる場合があります。
While bridge-like ND proxies aim to provide as little interference with ND mechanisms as possible, SEND has been designed to prevent modification or spoofing of advertisements by devices on the link.
ブリッジのようなNDプロキシは、NDメカニズムへの干渉を可能な限り提供することを目的としていますが、Sendはリンク上のデバイスによる広告の変更またはスプーフィングを防ぐために設計されています。
Of particular note is the fact that ND Proxy performs a different kind of proxy Neighbor Discovery to Mobile IPv6 [RFC3775] [RFC4389]. RFC 3775 (Mobile IPv6) specifies that the Home Agent as proxy sends Neighbor Advertisements from its own address with the Target Address set to the absent Mobile Node's address. The Home Agent's own link-layer address is placed in the Target Link-Layer Address Option [RFC3775]. On the other hand, ND Proxy resends messages containing their original address, even after modification (i.e., the IP source address remains the same) [RFC4389]. Figure 2 describes packet formats for proxy Neighbor solicitation and advertisement as specified by RFC 4389.
特に注目すべきは、NDプロキシがモバイルIPv6 [RFC3775] [RFC4389]に対して異なる種類のプロキシネイバーディスカバリーを実行するという事実です。RFC 3775（モバイルIPv6）は、ホームエージェントとしてプロキシとしてのホームエージェントが、ターゲットアドレスが不在のモバイルノードのアドレスに設定された独自のアドレスから近隣広告を送信することを指定します。ホームエージェント自身のリンク層アドレスは、ターゲットリンク層アドレスオプション[RFC3775]に配置されます。一方、NDプロキシは、変更後も元のアドレスを含むメッセージを再送信します（つまり、IPソースアドレスは同じままです）[RFC4389]。図2は、RFC 4389で指定されているプロキシネイバーの勧誘と広告のパケット形式を説明しています。
Advertiser Proxy Solicitor
広告主の代理人
NS:SL3=S,DL3=Sol(A),TA=A, NS:SL3=S,DL3=Sol(A),TA=A,
SL2=p,DL2=sol(a),SLL=p +-----+ SL2=s,DL2=sol(a),SLL=s
<==================| |<================
| |
==================>| |================>
NA:SL3=A,DL3=S,TA=A, +-----+ NA:SL3=A,DL3=S,TA=A
SL2=a,DL2=p,TLL=a SL2=p,DL2=s,TLL=p
Legend:
SL3: Source IPv6 Address NS: Neighbor Solicitation
DL3: Destination IPv6 Address NA: Neighbor Advertisement
SL2: Source Link-Layer Address
DL2: Destination Link-Layer Address
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Figure 2
図2
In order to use the same security procedures for both ND Proxy and Mobile IPv6, changes may be needed to the proxying procedures in [RFC4389], as well as changes to SEND.
NDプロキシとモバイルIPv6の両方に同じセキュリティ手順を使用するには、[RFC4389]のプロキシ手順、および送信の変更に変更が必要になる場合があります。
An additional (and undocumented) requirement for bridge-like proxying is the operation of router discovery. Router discovery packets may similarly modify Neighbor Cache state, and require protection from SEND.
ブリッジのようなプロキシの追加（および文書化されていない）要件は、ルーター発見の操作です。ルーターディスカバリーパケットも同様に近隣キャッシュ状態を変更し、送信からの保護が必要になる場合があります。
In Figure 3, the router discovery messages propagate without modification to the router address, but elements within the message change. This is consistent with the description of Neighbor Discovery above.
図3では、ルーターアドレスを変更せずにルーターディスカバリーメッセージが伝播しますが、メッセージ内の要素は変更されます。これは、上記の近隣発見の説明と一致しています。
Advertiser Proxy Solicitor
広告主の代理人
RS:SL3=S,DL3=AllR, RS:SL3=S,DL3=AllR,
SL2=p,DL2=allr,SLL=p +-----+ SL2=s,DL2=allr,SLL=s
<==================| |<================
| |
==================>| |================>
RA:SL3=A,DL3=S, +-----+ RA:SL3=A,DL3=S,
SL2=a,DL2=p,SLL=a SL2=p,DL2=s,SLL=p
Legend:
SL3: Source IPv6 Address RS: Router Solicitation
DL3: Destination IPv6 Address RA: Router Advertisement
SL2: Source Link-Layer Address
DL2: Destination Link-Layer Address
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Figure 3
図3
Once again, these messages may not be signed with a CGA signature by the proxy, because it does not own the source address.
繰り返しますが、これらのメッセージは、ソースアドレスを所有していないため、プロキシによるCGA署名で署名されない場合があります。
Additionally, Authorization Delegation Discovery messages need to be exchanged for bridge-like ND proxies to prove their authority to forward. Unless the proxy receives explicit authority to act as a router, or the router knows of its presence, no authorization may be made. This explicit authorization requirement may be at odds with the zero configuration goal of ND proxying [RFC4389].
さらに、承認委任の発見メッセージは、橋のようなNDプロキシと交換する必要があります。プロキシがルーターとして行動するための明示的な権限を受け取っていない場合、またはルーターがその存在を知っていない場合、許可は行われません。この明示的な承認要件は、NDプロキシ[RFC4389]のゼロ構成目標と対立する可能性があります。
An alternative (alluded to in an appendix of ND Proxy [RFC4389]) suggests that the proxy send Router Advertisements (RAs) from its own address. As described by ND Proxy, this is insufficient for providing proxied Neighbor Advertisement service, but may be matched with Neighbor solicitation and advertisement services using the proxy's source address in the same way as Mobile IPv6 [RFC4389] [RFC3775]. This means that all router and Neighbor advertisements would come from the proxied address, but may contain a target address that allows proxied Neighbor presence to be established with peers on other segments. Router discovery in this case has the identity of the original (non-proxy) router completely obscured in router discovery messages.
代替案（NDプロキシ[RFC4389]の付録で言及）は、プロキシが独自のアドレスからルーター広告（RAS）を送信することを示唆しています。NDプロキシで説明されているように、これはプロキシドネイバー広告サービスを提供するには不十分ですが、モバイルIPv6 [RFC4389] [RFC3775]と同じ方法で、プロキシのソースアドレスを使用して近隣勧誘および広告サービスと一致する場合があります。これは、すべてのルーターと近隣の広告がプロキシドアドレスから来ることを意味しますが、他のセグメントのピアでプロキシされた近隣の存在を確立できるターゲットアドレスが含まれている場合があります。この場合のルーターの発見には、ルーターの発見メッセージで完全に不明瞭になった元の（非プロキシ）ルーターのアイデンティティがあります。
The resultant proxy messages would have no identifying information indicating their origin, which means that proxying between multiple links would require state to be stored on outstanding solicitations (effectively a ND only NAT). This level of state storage may be undesirable.
結果のプロキシメッセージには、その起源を示す識別情報がありません。つまり、複数のリンク間でプロキシを作成するには、未解決の勧誘（事実上、NATのみ）に状態を保存する必要があります。このレベルの状態ストレージは望ましくない場合があります。
Mobile IPv6 does not experience this issue when supplying its own address, since ND messages are never forwarded on to the absent node (the Home Agent having sufficient information to respond itself).
NDメッセージが不在のノードに転送されることはないため、モバイルIPv6は独自のアドレスを提供するときにこの問題を発生しません（ホームエージェントは、それ自体に応答するのに十分な情報を持っています）。
Authorization from a router may still be required for Router Advertisement, and will be discussed in Section 4.2.
ルーターの広告にはルーターからの承認が必要になる場合があり、セクション4.2で説明します。
There are currently no existing secured Neighbor Discovery procedures for proxied addresses, and all Neighbor Advertisements from SEND nodes are required to have equal source and target addresses, and be signed by the transmitter (Section 7.4 of [RFC3971]).
現在、プロキシアドレスの既存の保護された近隣発見手順はなく、送信ノードからのすべての近隣広告は、等しいソースとターゲットアドレスを持つために必要であり、送信機によって署名されます（[RFC3971]のセクション7.4）。
Signatures over SEND messages are required to be applied on the CGA source address of the message, and there is no way of indicating that a message is proxied.
送信メッセージを介した署名は、メッセージのCGAソースアドレスに適用する必要があり、メッセージがプロキシされていることを示す方法はありません。
Even if the message is able to be transmitted from the original owner, differences in link-layer addressing and options require modification by a proxy. If a message is signed with a CGA-based signature, the proxy is unable to regenerate a signature over the changed message as it lacks the keying material.
メッセージを元の所有者から送信できる場合でも、リンク層アドレス指定とオプションの違いは、プロキシによる変更が必要です。メッセージがCGAベースの署名で署名されている場合、プロキシは、キーイング素材がないため、変更されたメッセージの上に署名を再生できません。
Therefore, a router wishing to provide proxy Neighbor Advertisement service cannot use existing SEND procedures on those messages.
したがって、プロキシNeighbor Advertisement Serviceの提供を希望するルーターは、それらのメッセージで既存の送信手順を使用することはできません。
A host may wish to establish a session with a device that is not on-link but is proxied. As a SEND host, it prefers to create Neighbor Cache Entries using secured procedures. Since SEND signatures cannot be applied to an existing proxy Neighbor Advertisement, it must accept non-SEND advertisements in order to receive proxy Neighbor Advertisements.
ホストは、リンクしていないがプロキシされているデバイスを使用してセッションを確立することをお勧めします。送信ホストとして、セキュリティで保護された手順を使用してネイバーキャッシュエントリを作成することを好みます。送信署名は既存のプロキシネイバー広告に適用できないため、プロキシネイバー広告を受け取るために、非センド広告を受け入れる必要があります。
Neighbor Cache spoofing of another node therefore becomes trivial, as any address may be proxy-advertised to the SEND node, and overridden only if the node is there to protect itself. When a node is present to defend itself, it may also be difficult for the solicitor determine the difference between a proxy-spoofing attack, and a situation where a proxied device returns to a link and overrides other proxy advertisers [RFC4861].
したがって、別のノードの隣接キャッシュスプーフィングは、任意のアドレスが送信ノードにプロキシ宣伝され、ノードが自分自身を保護するためにそこにある場合にのみオーバーライドされるため、些細なものになります。ノードが存在する場合、弁護士がプロキシスポーフィング攻撃とプロキシデバイスがリンクに戻り、他のプロキシ広告主をオーバーライドする状況の違いを決定することも困難な場合があります[RFC4861]。
SEND defines one public-key and signature format for use with Cryptographically Generated Addresses (CGAs) [RFC3972]. CGAs are intended to tie address ownership to a particular public/private key pair.
sendは、暗号化されたアドレス（CGA）[RFC3972]で使用する1つのパブリックキーおよび署名形式を定義します。CGAは、住所の所有権を特定のパブリック/プライベートキーペアに結び付けることを目的としています。
In SEND as defined today, Neighbor Discovery messages (including the IP Addresses from the IPv6 header) are signed with the same key used to generate the CGA. This means that message recipients have proof that the signer of the message owned the address.
本日定義されている送信では、近隣のディスカバリーメッセージ（IPv6ヘッダーからのIPアドレスを含む）が、CGAを生成するために使用されるのと同じキーで署名されます。これは、メッセージ受信者がメッセージの署名者が住所を所有していることを証明していることを意味します。
When a proxy replaces the message's source IPv6 address with its own CGA, the existing CGA option and RSA signature option would need to be replaced with ones that correspond to the CGA of the proxy. To be valid according to the SEND specification, the Target Address of the Neighbor Advertisement message would need to be replaced also to be equal to the Source Address [RFC3971].
プロキシがメッセージのソースIPv6アドレスを独自のCGAに置き換える場合、既存のCGAオプションとRSA署名オプションをプロキシのCGAに対応するものに置き換える必要があります。送信仕様に従って有効にするには、近隣広告メッセージのターゲットアドレスを、ソースアドレス[RFC3971]と等しくするために置き換える必要があります。
Additional authorization information may be needed to prove that the proxy is indeed allowed to advertise for the target address, as is described in Section 4.
セクション4で説明されているように、プロキシが実際にターゲットアドレスを宣伝することが許可されていることを証明するために、追加の承認情報が必要になる場合があります。
Where a proxy retains the original source address in a proxied message, existing security checks for SEND will fail, since fields within the message will be changed. In order to achieve secured proxy Neighbor Discovery in this case, extended authorization mechanisms may be needed for SEND.
プロキシがプロキシされたメッセージで元のソースアドレスを保持する場合、メッセージ内のフィールドが変更されるため、既存のセキュリティチェックが送信されます。この場合、安全なプロキシ近隣発見を達成するために、送信には拡張許可メカニズムが必要になる場合があります。
SEND provides mechanisms for extension of SEND to non-CGA-based authorization. Messages are available for Authorization Delegation Discovery, which is able to carry arbitrary PKIX/X.509 certificates [RFC5280].
Sendは、非CGAベースの認可への送信の拡張のメカニズムを提供します。メッセージは、任意のPKIX/X.509証明書[RFC5280]を携帯できる承認委任の発見に利用できます。
There is, however, no specification of keying information option formats analogous to the SEND CGA Option [RFC3971]. The existing option allows a host to verify message integrity by specifying a key and algorithm for digital signature, without providing authorization via mechanisms other than CGA ownership.
ただし、send CGAオプション[RFC3971]に類似したキーイング情報オプション形式の仕様はありません。既存のオプションにより、ホストは、CGAの所有権以外のメカニズムを介して許可を提供することなく、デジタル署名のキーとアルゴリズムを指定することにより、メッセージの整合性を検証できます。
The digital signature in SEND is transported in the RSA Signature Option. As currently specified, the signature operation is performed over a CGA Message type, and allows for CGA verification. Updating the signature function to support non-CGA operations may be necessary.
Sendのデジタル署名は、RSA署名オプションで輸送されます。現在指定されているように、署名操作はCGAメッセージタイプで実行され、CGAの検証が可能になります。非CGA操作をサポートするために署名関数を更新する必要がある場合があります。
Within SEND, more advanced functions such as routing may be authorized by certificate path verification using Authorization Delegation Discovery.
送信内では、ルーティングなどのより高度な関数は、承認委任の発見を使用した証明書パス検証によって承認される場合があります。
With non-CGA signatures and authentication, certificate contents for authorization may need to be determined, as outlined in Section 4.
非CGAの署名と認証を使用すると、セクション4で概説されているように、承認の証明書の内容を決定する必要がある場合があります。
While SEND provides for extensions to new non-CGA methods, existing SEND hosts may silently discard messages with unverifiable RSA signature options (Section 5.2.2 of [RFC3971]), if configured only to accept SEND messages. In cases where unsecured Neighbor Cache Entries are still accepted, messages from new algorithms will be treated as unsecured.
Sendは新しい非CGAメソッドへの拡張機能を提供しますが、既存の送信ホストは、送信メッセージを受け入れるように構成されている場合、検証できないRSA署名オプション（[RFC3971]のセクション5.2.2）を使用して静かに廃棄する場合があります。無担保の近隣キャッシュエントリがまだ受け入れられている場合、新しいアルゴリズムからのメッセージは無担保として扱われます。
Initiation of proxy Neighbor Discovery also requires Duplicate Address Detection (DAD) checks of the address [RFC4862]. These DAD checks need to be performed by sending Neighbor Solicitations, from the unspecified source address, with the target being the proxied address.
プロキシネイバーディスカバリーの開始には、住所の重複した住所検出（DAD）チェックも必要です[RFC4862]。これらのお父さんのチェックは、不特定のソースアドレスから隣人の勧誘を送信することで実行する必要があり、ターゲットはプロキシドアドレスです。
In existing SEND procedures, the address that is used for CGA tests on DAD NS is the target address. A Proxy that originates this message while the proxied address owner is absent is unable to generate a CGA-based signature for this address and must undertake DAD with an unsecured NS. It may be possible that the proxy can ensure that responding NAs are secured though.
既存の送信手順では、DAD NSのCGAテストに使用されるアドレスがターゲットアドレスです。プロキシドアドレスの所有者が不在の間にこのメッセージを発信するプロキシは、このアドレスのCGAベースの署名を生成することができず、無担保のNSでパパを引き受ける必要があります。ただし、プロキシが応答するNASが確実に保護されることを保証できる可能性があります。
Where bridge-like ND proxy operations are being performed, DAD NSs may be copied from the original source, without modification (considering they have an unspecified source address and contain no link-layer address options) [RFC4389].
ブリッジのようなNDプロキシ操作が実行されている場合、DAD NSSは、変更なしで元のソースからコピーされる場合があります（不特定のソースアドレスがあり、リンクレイヤーアドレスオプションが含まれていないことを考慮して）[RFC4389]。
If non-CGA-based signatures are available, then the signature over the DAD NS doesn't need to have a CGA relationship to the Target Address, but authorization for address configuration needs to be shown using certificates.
非CGAベースの署名が利用可能な場合、DAD NSの署名はターゲットアドレスとCGA関係を持つ必要はありませんが、住所構成の許可を証明書を使用して表示する必要があります。
In case there is a DAD collision between two SEND nodes on different interfaces of the proxy, it is possible that the proxy may not have the authority to modify the NA defending the address. In this case, the proxy still needs to modify the NA and pass it onto the other interfaces even if it will fail SEND verification on the receiving node.
プロキシの異なるインターフェイスで2つの送信ノード間に父親の衝突がある場合、プロキシには住所を防御するNAを変更する権限がない可能性があります。この場合、プロキシは、受信ノードの確認が失敗した場合でも、NAを変更して他のインターフェイスに渡す必要があります。
While Router Solicitations are protected in the same manner as Neighbor Solicitations, the security for Router Advertisements is mainly based on the use of certificates. Even though the mechanism for securing RAs is different, the problems that arise due to the modification of the L2 addresses are exactly the same: the proxy needs to have the right security material (e.g., certificate) to sign the RA messages after modification.
ルーターの勧誘は近隣の勧誘と同じ方法で保護されていますが、ルーター広告のセキュリティは主に証明書の使用に基づいています。RAを保護するメカニズムは異なりますが、L2アドレスの変更により発生する問題はまったく同じです。プロキシは、変更後にRAメッセージに署名するために適切なセキュリティ資料（例：証明書）を持つ必要があります。
SEND nodes already have the concept of delegated authority through requiring external authorization of routers to perform their routing and advertisement roles. The authorization of these routers takes the form of delegation certificates.
送信ノードは、ルーティングと広告の役割を実行するためにルーターの外部認証を要求することにより、委任された権限の概念を既に持っています。これらのルーターの承認は、委任証明書の形をとっています。
Proxy Neighbor Discovery requires a delegation of authority (on behalf of the absent address owner) to the proxier. Without this authority, other devices on the link have no reason to trust an advertiser.
プロキシネイバーディスカバリーでは、プロキシに権限の委任（不在住所所有者に代わって）が必要です。この権限がなければ、リンク上の他のデバイスには、広告主を信頼する理由はありません。
For bridge-like proxies, it is assumed that there is no preexisting trust between the host owning the address and the proxy. Therefore, authority may necessarily be dynamic or based on topological roles within the network [RFC4389].
ブリッジのようなプロキシの場合、住所を所有するホストとプロキシの間に既存の信頼がないと想定されています。したがって、権限は必然的に動的であるか、ネットワーク内のトポロジー的役割に基づいている可能性があります[RFC4389]。
Existing trust relationships lend themselves to providing authority for proxying in two alternative ways.
既存の信頼関係は、2つの代替方法でプロキシするための権限を提供することに役立ちます。
First, the SEND router authorization mechanisms described above provide delegation from the organization responsible for routing in an address domain to the certified routers. It may be argued that routers so certified may be trusted to provide service for nodes that form part of a link's address range, but are themselves absent. Devices which are proxies could either be granted the right to proxy by the network's router, or be implicitly allowed to proxy by virtue of being an authorized router.
まず、上記の送信ルーター認証メカニズムは、アドレスドメイン内のルーティングを担当する組織から認定ルーターへの委任を提供します。そのように認定されたルーターは、リンクのアドレス範囲の一部を形成するノードのサービスを提供すると信頼される可能性があるが、それ自体が欠席していると主張されるかもしれません。プロキシであるデバイスは、ネットワークのルーターによるプロキシの権利を付与するか、認定ルーターであることにより暗黙的にプロキシを許可される可能性があります。
Second, where the proxied address is itself a CGA, the holder of the public and private keys is seen to be authoritative about the address's use. If this address owner was able to sign the proxier's address and public key information, it would be possible to identify that the proxy is known and trusted by the CGA address owner for proxy service. This method requires that the proxied address know or learn the proxy's address and public key, and that the certificate signed by the proxied node's is passed to the proxy, either while they share the same link, or at a later stage.
第二に、プロキシドアドレス自体がCGAである場合、パブリックキーとプライベートキーの所有者は、住所の使用について権威あると見られています。このアドレス所有者が代理人のアドレスと公開鍵情報に署名できた場合、プロキシサービスのためにCGAアドレス所有者によってプロキシが既知で信頼されていることを特定することが可能です。この方法では、プロキシドアドレスがプロキシのアドレスと公開キーを知っているか、学習し、プロキシノードによって署名された証明書が同じリンクを共有している間、または後の段階でプロキシに渡されることが必要です。
In both methods, the original address owner's advertisements need to override the proxy if it suddenly returns, and therefore timing and replay protection from such messages need to be carefully considered.
どちらの方法でも、元のアドレス所有者の広告は、突然戻ってきた場合にプロキシをオーバーライドする必要があるため、そのようなメッセージからのタイミングとリプレイの保護を慎重に検討する必要があります。
Mobile IPv6 has a security association between the Mobile Node and Home Agent. The Mobile Node sends a Binding Update to the Home Agent, to indicate that it is not at home. This implies that the Mobile Node wishes the Home Agent to begin proxy Neighbor Discovery operations for its home address(es).
モバイルIPv6には、モバイルノードとホームエージェントの間にセキュリティ関連があります。モバイルノードは、ホームエージェントにバインディングアップデートを送信して、自宅にいないことを示します。これは、モバイルノードがホームエージェントがホームアドレスのプロキシネイバーディスカバリーオペレーションを開始することを望んでいることを意味します。
A secured Proxy Neighbor Advertisements proposal based on existing router trust would require no explicit authorization signaling between HA and MN to allow proxying. Hosts on the home link will believe proxied advertisements solely because they come from a trusted router.
既存のルータートラストに基づいた保護されたプロキシネイバー広告の提案では、プロキシを許可するためにHAとMNの間の明示的な承認シグナリングは必要ありません。ホームリンクのホストは、信頼できるルーターから来ているという理由だけで、プロキシの広告を信じるでしょう。
Where the home agent operates as a router without explicit trust to route from the advertising routing infrastructure (such as in a home, with a router managed by an ISP), more explicit proxying authorization may be required, as described in Section 4.2.
ホームエージェントが、広告ルーティングインフラストラクチャ（家庭など、ISPが管理するルーターなど）からルーティングする明示的な信頼なしにルーターとして動作する場合、セクション4.2で説明されているように、より明確なプロキシ許可が必要になる場合があります。
Where proxy Neighbor Discovery is delegated by the MN to the home agent, the MN needs to learn the public key for the Home Agent, so that it can generate a certificate authorizing the public/private key pair to be used in proxying. It may conceivably do this using Certificate Path Solicitations either over a home tunnel, when it is away from home, or during router discovery while still at home [RFC3971] [RFC3775].
プロキシネイバーディスカバリーがMNによってホームエージェントに委任された場合、MNはホームエージェントの公開キーを学習する必要があります。そうすれば、プロキシに使用されるパブリック/プライベートキーペアを許可する証明書を生成できます。これは、自宅から離れているとき、または自宅でのルーターの発見中に、家庭から離れたときに、住宅トンネルを介した証明書パスの勧誘を使用してこれを行う可能性があります[RFC3971] [RFC3775]。
When sending its Binding Update to the HA, the MN would need to provide a certificate containing the subject's (i.e., proxy HA's) public key and address, the issuer's (i.e., MN's) CGA and public key, and timestamps indicating when the authority began and when it ends. This certificate would need to be transmitted at binding time. Messaging or such an exchange mechanism would have to be developed.
バインディングアップデートをHAに送信する場合、MNは被験者の（つまり、プロキシHA）公開キーと住所、発行者（MN（MN）CGAと公開鍵、および当局が始まった時期を示すタイムスタンプを含む証明書を提供する必要がありますそして、それが終わったら。この証明書は、拘束時間に送信する必要があります。メッセージングまたはそのような交換メカニズムを開発する必要があります。
Specific cryptographic algorithms may help to allow trust between entities of a same group.
特定の暗号化アルゴリズムは、同じグループのエンティティ間の信頼を可能にするのに役立つ場合があります。
This is the case, for example, with ring signature algorithms. These algorithms generate a signature using the private key of any member from the same group, but to verify the signature the public keys of all group members are required. Applied to SEND, the addresses are cryptographically generated using multiple public keys, and the Neighbor Discovery messages are signed with an RSA ring signature [RING]. (Note that the cryptographic algorithms that are the foundation for [RING] and other similar solutions are not widely accepted in the security community; additional research is needed before a Standards Track protocol could be developed.)
これは、たとえば、リング署名アルゴリズムの場合です。これらのアルゴリズムは、同じグループのメンバーの秘密鍵を使用して署名を生成しますが、署名を確認するには、すべてのグループメンバーのパブリックキーが必要です。送信に適用されるアドレスは、複数のパブリックキーを使用して暗号化され、近隣のディスカバリーメッセージはRSAリング署名[リング]で署名されます。（[リング]およびその他の同様のソリューションの基礎である暗号化アルゴリズムは、セキュリティコミュニティでは広く受け入れられていないことに注意してください。標準の追跡プロトコルを開発する前に、追加の調査が必要です。）
Another approach is to use the 'Point-to-Point' link model.
別のアプローチは、「ポイントツーポイント」リンクモデルを使用することです。
In this model, one prefix is provided per MN, and only an MN and the HA are on a same link. The consequence is the HA no longer needs to act as ND Proxy.
このモデルでは、1つのプレフィックスがMNごとに提供され、MNとHAのみが同じリンクにあります。結果は、HAがNDプロキシとして機能する必要がなくなったことです。
One way to design such a solution is to use virtual interfaces, on the MN and the HA, and a virtual link between them. Addresses generated on the virtual interfaces will only be advertised on the virtual link. For Mobile IPv6, this results in a virtual Home Network where the MN will never come back.
このようなソリューションを設計する1つの方法は、仮想インターフェイス、MNとHAで、およびそれらの間の仮想リンクを使用することです。仮想インターフェイスで生成されたアドレスは、仮想リンクでのみ宣伝されます。モバイルIPv6の場合、これにより、MNが戻ってこない仮想ホームネットワークが得られます。
In link-extension environments, the role of a proxy is more explicitly separated from that of a router. In SEND, routers may expect to be authorized by the routing infrastructure to advertise and may provide this authority to hosts in order to allow them to change forwarding state.
リンク拡張環境では、プロキシの役割はルーターの役割からより明確に分離されています。送信では、ルーターがルーティングインフラストラクチャによって宣伝することが許可されることを期待する場合があり、転送状態を変更できるようにこの権限をホストに提供する場合があります。
Proxies are not part of the traditional infrastructure of the Internet, and hosts or routers may not have an explicit reason to trust them, except that they can forward packets to regions where otherwise those hosts or routers could not reach.
プロキシはインターネットの従来のインフラストラクチャの一部ではなく、ホストまたはルーターは、それらを信頼する明確な理由を持たない場合があります。
If a proxy can convince a device that it should be trusted to perform proxying function, it may require that device to vouch for its operation in dealing with other devices. It may do this by receiving a certificate, signed by the originating device that the proxy is believed capable of proxying under certain circumstances.
プロキシがプロキシ機能を実行することが信頼されるべきであるとデバイスに納得させることができる場合、そのデバイスは他のデバイスを扱う際の操作を保証する必要がある場合があります。これは、特定の状況下でプロキシがプロキシできると考えられていると考えられている発信装置によって署名された証明書を受け取ることでこれを行うことができます。
This allows nodes receiving proxied Neighbor Discovery packets to quickly check if the proxy is authorized for the operation. There are several bases for such trust, and requirements in proxied environments, which are discussed below.
これにより、Proxied Neighbor Discoveryパケットを受信するノードが操作のためにプロキシが承認されているかどうかをすばやく確認できます。そのような信頼のためのいくつかの基盤と、以下で説明するプロキシ環境には要件があります。
Routers may be advertising on networks without any explicit authorization, and SEND hosts will register these routers if there are no other options [RFC3971]. While proxies may similarly attempt to advertise without authority, this provides no security for the routing infrastructure. Any device can be setup as a SEND proxy/ router so long as it signs its own ND messages from its CGA.
ルーターは明示的な承認なしにネットワーク上に広告を掲載している可能性があり、他のオプションがない場合は、これらのルーターを登録します[RFC3971]。プロキシは同様に権限なしで宣伝しようとするかもしれませんが、これはルーティングインフラストラクチャのセキュリティを提供しません。任意のデバイスは、CGAから独自のメッセージに署名する限り、送信プロキシ/ルーターとしてセットアップできます。
This may not help in the case that a proxy attempts to update Neighbor Cache Entries for a SEND node that moves between links, since the SEND node's authority to advertise its own CGA address would not be superseded by a proxy with no credentials.
これは、プロキシがリンク間を移動する送信ノードの近隣キャッシュエントリを更新しようとする場合には役に立たないかもしれません。
Proxies may have multiple levels of nesting, which allow the network to connect between non-adjacent segments.
プロキシには複数のレベルのネストがあり、ネットワークが非隣接セグメント間で接続できるようにします。
In this case, authority delegated at one point will have to be redelegated (possibly in a diluted form) to proxies further away from the origin of the trust.
この場合、ある時点で委任された当局は、信託の起源から遠く離れたプロキシに再採用する必要があります（おそらく希釈された形で）。
Trust Proxy A Proxy B Distant
Origin - T Node - D
+-----+ +-----+
| | | |
+-----+ +-----+ +-----+ +-----+
| | | | | |
------------| |------------| |----------
| | | |
+-----+ +-----+
==========> ==============> ==========>
Deleg(A,T) Deleg(B,Deleg(A,T)) Advertise(D, Deleg(B,
Deleg(A,T))
Figure 4
図4
As shown in Figure 4, the Proxy A needs to redelegate authority to proxy for T to Proxy B; this allows it to proxy advertisements that target T back to D.
図4に示すように、プロキシAは、TのプロキシBのプロキシに権限を再選択する必要があります。これにより、Dに戻るTをターゲットにするプロキシ広告が可能になります。
Where it is possible for the proxy to pre-establish trust with the routing infrastructure, or at least to the local router, it may be possible to authorize proxying as a function of routing within the subnet. The router or CA may then be able to certify proxying for only a subset of the prefixes for which it is itself certified.
プロキシがルーティングインフラストラクチャとの信頼を事前に確立することが可能な場合、または少なくともローカルルーターに対しては、サブネット内のルーティングの関数としてプロキシを許可することが可能かもしれません。ルーターまたはCAは、それ自体が認定されている接頭辞のサブセットのみのプロキシを認定できる場合があります。
If a router or CA provides certification for a particular prefix, it may be able to indicate that only proxying is supported, so that Neighbor Cache Entries of routers connected to Internet infrastructure are never overridden by the proxy, if the router is present on a segment.
ルーターまたはCAが特定のプレフィックスの認定を提供する場合、プロキシのみがサポートされていることを示すことができる可能性があります。そのため、インターネットインフラストラクチャに接続されたルーターのネイバーキャッシュエントリは、ルーターがセグメントに存在する場合、プロキシによってオーバーライドされません。。
Hosts understanding such certificates may allow authorized proxies and routers to override the host when assuming proxy roles, if the host is absent.
このような証明書を理解するホストは、ホストが不在の場合、プロキシの役割を想定したときに、認定プロキシおよびルーターがホストをオーバーライドすることを可能にする場合があります。
Proxy certificate signing could be done either dynamically (requiring exchanges of identity and authorization information) or statically when the network is set up.
プロキシ証明書の署名は、動的に（IDと承認情報の交換が必要）、またはネットワークが設定されたときに静的に行うことができます。
Where no trust tie exists between the authority that provides the routing infrastructure and the provider of bridging and proxying services, it may still be possible for SEND hosts to trust the bridging provider to authorize proxying operations.
ルーティングインフラストラクチャを提供する当局とブリッジングおよびプロキシサービスのプロバイダーとの間に信頼関係が存在しない場合、ホストを送信してブリッジングプロバイダーを信頼して、プロキシ運営を許可することが可能です。
SEND itself requires that routers be able to show authorization, but doesn't require routers to have a single trusted root.
送信自体では、ルーターが許可を示すことができる必要がありますが、ルーターは単一の信頼ルートを持つ必要はありません。
A local bridging/proxying authority trust delegation may be possible. It would be possible for this authority to pass out local-use certificates, allowing proxying on a specific subnet or subnets, with a separate authorization chain to those subnets for the routers with Internet access.
地元のブリッジング/プロキシ機関の信託代表団が可能になる場合があります。この当局は、特定のサブネットまたはサブネットでプロキシを作成し、インターネットアクセスのあるルーターのサブネットに個別の認証チェーンを使用して、ローカル使用証明書を配置することが可能です。
This would require little modification to SEND, other than the addition of router-based proxy authority (as in Section 4.2.4), and proxies would in effect be treated as routers by SEND hosts [RFC3971]. Distribution of keying and trust material for the initial bootstrap of proxies would not be provided though (and may be static).
これには、ルーターベースのプロキシ機関の追加を除く（セクション4.2.4のように）、送信するための変更はほとんど必要ありません。また、プロキシは実際には送信ホスト[RFC3971]によってルーターとして扱われます。ただし、プロキシの初期ブートストラップのキーイングおよび信頼資料の分布は提供されません（そして静的である可能性があります）。
Within small domains, key management and distribution may be a tractable problem, so long as these operations are simple enough to perform.
小さなドメイン内では、これらの操作が実行できるほど簡単である限り、主要な管理と分布が扱いやすい問題になる可能性があります。
Since these domains may be small, it may be necessary to provide certificate chains for trust anchors that weren't requested in Certificate Path Solicitations, if the proxy doesn't have a trust chain to any requested trust anchor.
これらのドメインは小さいかもしれないので、プロキシが要求された信頼アンカーに信頼チェーンを持っていない場合、証明書パスの勧誘で要求されなかった信頼アンカーに証明書チェーンを提供する必要があるかもしれません。
This is akin to 'suggesting' an appropriate trusted root. It may allow for user action in allowing trust extension when visiting domains without ties to a global keying infrastructure. In this case, the trust chain would have to start with a self-signed certificate from the original CA.
これは、適切な信頼できるルートを「提案」することに似ています。グローバルキーイングインフラストラクチャとの関係なしにドメインにアクセスするときに、信頼拡張を許可するユーザーアクションが可能になる場合があります。この場合、トラストチェーンは、元のCAからの自己署名証明書から開始する必要があります。
Unlike Mobile IPv6, for bridge-like proxied networks, there is no existing security association upon which to transport proxying authorization credentials.
ブリッジのようなプロキシネットワーク用のモバイルIPv6とは異なり、承認資格情報を輸送するための既存のセキュリティ関連はありません。
Thus, proxies need to convince Neighbors to delegate proxy authority to them, in order to proxy-advertise to nodes on different segments. It will be difficult without additional information to distinguish between legitimate proxies and devices that have no need or right to proxy (and may want to make two network segments appear connected).
したがって、プロキシは、さまざまなセグメントのノードにプロキシアダバート化するために、隣人に代理権限を委任するよう説得する必要があります。追加情報がなければ、合法的なプロキシとプロキシの必要性または権利がないデバイスを区別することは困難です（2つのネットワークセグメントを接続しているようにしたい場合があります）。
When proxy advertising, proxies must not only identify that proxying needs to occur, but provide proof that they are allowed to do so, so that SEND Neighbor Cache Entries may be updated. Unless the authorization to update such entries is tied to address ownership proofs from the proxied host or the verifiable routing infrastructure, spoofing may occur.
プロキシ広告の場合、プロキシは、プロキシの必要性が発生することを特定するだけでなく、そうすることが許可されていることを証明する必要があります。そのようなエントリを更新する許可が、プロキシドホストまたは検証可能なルーティングインフラストラクチャからの所有権の証明に対処するために結び付けられない限り、スプーフィングが発生する可能性があります。
When a host received a proxied Neighbor advertisement, it would be necessary to check authorization in the same way that authorization delegation discovery is performed in SEND.
ホストがプロキシドネイバーの広告を受け取ったとき、承認委任の発見が送信で実行されるのと同じように、承認を確認する必要があります。
Otherwise, certificate transport will be required to exchange authorization between proxied nodes and proxies.
それ以外の場合、プロキシノードとプロキシの間の許可を交換するには、証明書輸送が必要です。
Proxies would have to be able to delegate this authorization to downstream proxies, as described in Section 4.2.3.
セクション4.2.3で説明されているように、プロキシはこの承認を下流のプロキシに委任できる必要があります。
Where the original Neighbor Discovery message is unsecured, there is an argument for not providing secured proxy service for that node.
元のNeighbor Discoveryメッセージがセキュアルである場合、そのノードにセキュリティで保護されたプロキシサービスを提供しないという議論があります。
In both the Mobile IPv6 and extended networks cases, the node may arrive back at the network and require other hosts to map their existing Neighbor Cache Entry to the node's link-layer address. The re-arriving node's overriding of link-layer address mappings will occur without SEND in this case.
モバイルIPv6と拡張ネットワークの両方のケースで、ノードはネットワークに戻って到着し、他のホストに既存のネイバーキャッシュエントリをノードのリンク層アドレスにマッピングする必要があります。このケースでは、リンクレイヤーアドレスマッピングの再登録ノードの無効化は、送信せずに発生します。
It is notable that without SEND protection any node may spoof the arrival, and effectively steal service across an extended network. This is the same as in the non-proxy case, and is not made significantly worse by the proxy's presence (although the identity of the attacker may be masked if source addresses are being replaced).
保護を送信しないと、ノードが到着を広げ、拡張ネットワーク全体でサービスを効果的に盗む可能性があることは注目に値します。これは、非プロキシの場合と同じであり、プロキシの存在によって有意に悪化することはありません（ただし、攻撃者のアイデンティティは、ソースアドレスが交換されている場合にマスクされる場合があります）。
If signatures over the proxied messages were to be used, re-arrival and override of the Neighbor Cache Entries would have to be allowed, so the signatures would indicate that at least the proxy wasn't spoofing (even if the original sender was).
Proxiedメッセージを介した署名を使用する場合、Neighbor Cacheエントリの再到達とオーバーライドを許可する必要があるため、署名は少なくともプロキシがスプーフィングしていないことを示します（元の送信者があったとしても）。
For non-SEND routers, though, it may be possible for secured proxies to send signed router advertisement messages, in order to ensure that routers aren't spoofed, and subsequently switched to different parts of the extended network.
ただし、非センドルーターの場合、ルーターがスプーフィングされていないことを確認し、その後拡張ネットワークの異なる部分に切り替えるために、セキュリティで保護されたプロキシが署名されたルーター広告メッセージを送信できる可能性があります。
This has problems in that the origin is again unsecured, and any node on the network could spoof router advertisement for an unsecured address. These spoofed messages may become almost indistinguishable (except for the non-CGA origin address) from unspoofed messages from SEND routers.
これには、起源が再びセキュリティでなく、ネットワーク上のノードは、無担保アドレスのルーター広告を押し上げる可能性があるという点で問題があります。これらのスプーフィングされたメッセージは、送信ルーターからのspoofedメッセージとはほとんど見分けがつかなくなる可能性があります（非CGA起源アドレスを除く）。
Given these complexities, the simplest method is to allow unsecured devices to be spoofed from any port on the network, as is the case today.
これらの複雑さを考えると、最も簡単な方法は、今日のように、ネットワーク上の任意のポートから無担保デバイスをスプーフィングできるようにすることです。
All the previous sections of this document focused on the case where two nodes defend the same address (i.e., the node and the proxy). However, there are also cases where two or more nodes are defending the same address. This is at least the case for:
このドキュメントの以前のセクションはすべて、2つのノードが同じアドレス（つまり、ノードとプロキシ）を守る場合に焦点を当てました。ただし、2つ以上のノードが同じアドレスを擁護している場合もあります。これは少なくとも次の場合です。
o Nodes having the same address, as the Mobile Access Gateway's (MAG's) ingress link-local address in Proxy Mobile IPv6 (PMIPv6) [RFC5213].
o プロキシモバイルIPv6（PMIPv6）[RFC5213]のモバイルアクセスゲートウェイ（MAG）イングレスリンクローカルアドレスと同じアドレスを持つノード。
o Nodes having a common anycast address [RFC4291].
o 共通のAnycastアドレス[RFC4291]を持つノード。
The problem statement, described previously in this document, applies for these cases, and the issues are the same from a signaling point of view.
このドキュメントで以前に説明した問題の声明は、これらのケースに適用され、問題はシグナル伝達の観点から同じです。
Multicast addresses are not mentioned here because Neighbor Discovery Protocol is not used for them.
マルチキャストアドレスは、近隣のディスカバリープロトコルが使用されていないため、ここでは言及されていません。
In the first case, [RFC5213] assumes that the security material used by SEND (i.e., public-private key pair) is shared between all the MAGs. For the second case, there is no solution today. But, in the same way, it should be possible to assume that the nodes having a common anycast address could also share the security material.
最初のケースでは、[RFC5213]は、SENDで使用されるセキュリティ資料（つまり、官民キーペア）がすべての雑誌間で共有されると仮定しています。2番目のケースでは、今日は解決策がありません。ただし、同様に、共通のAnycastアドレスを持つノードもセキュリティ資料を共有できると仮定することができるはずです。
It is important to notice that when many nodes defending the same address are not in the same administrative domain (e.g., MAGs in different administrative domains but in the same PMIPv6 domain [RFC5213]), sharing the security material used by SEND may raise a security issue.
同じアドレスを擁護する多くのノードが同じ管理ドメイン（例：異なる管理ドメインのMAGSではなく、同じPMIPV6ドメイン[RFC5213]）にある場合、SENDが使用するセキュリティ資料を共有する可能性があることに注意することが重要です。問題。
Router-based authorization for Secured Proxy ND may occur without the knowledge or consent of a device. It is susceptible to the 'Good Router Goes Bad' attack described in [RFC3756].
保護されたプロキシNDのルーターベースの承認は、デバイスの知識または同意なしに発生する場合があります。[RFC3756]に記載されている「良いルーターが悪い」攻撃の影響を受けやすい。
Certificate delegation relies upon transfer of the new credentials to the proxying HA in order to undertake ND proxy on its behalf. Since the binding cannot come into effect until DAD has taken place, the delegation of the proxying authority necessarily predates the return of the Binding Ack, as described in [RFC3775]. In the case above described, the home tunnel that comes into creation as part of the binding process may be required for transport of Certificate Path Solicitations or Advertisements [RFC3971]. This constitutes a potential chicken-and-egg problem. Either modifications to initial home binding semantics or certificate transport are required. This may be trivial if certificates are sent in the clear between the MN's Care-of Address (CoA) and the HA without being tunneled.
証明書委任は、新しい資格情報をプロキシHAに移転することに依存して、その代わりにNDプロキシを引き受けることに依存しています。父親が行われるまでバインディングは施行されないため、[RFC3775]に記載されているように、プロキシ当局の代表団は必然的にバインディングACKの復帰を前提としています。上記のケースでは、拘束力のあるプロセスの一部として作成されるホームトンネルが、証明書の勧誘または広告[RFC3971]の輸送に必要な場合があります。これは、潜在的な鶏と卵の問題を構成します。初期ホームバインディングセマンティクスの修正または証明書輸送が必要です。これは、MNのケアオブアドレス（COA）とHAの間の明確なものにトンネルを取られない場合、証明書が明確に送信される場合、些細なことです。
All of the presented methods rely on accurate timekeeping on the receiver nodes of Neighbor Discovery Timestamp Options.
提示されたすべての方法は、Neighbor Discoveryタイムスタンプオプションの受信機ノードの正確なタイムキーピングに依存しています。
For router-authorized proxy ND, a Neighbor may not know that a particular ND message is replayed from the time when the proxied host was still on-link, since the message's timestamp falls within the valid timing window. Where the router advertises its secured proxy NA, a subsequent replay of the old message will override the NCE created by the proxy.
Routerを認めるプロキシNDの場合、隣人は、メッセージのタイムスタンプが有効なタイミングウィンドウ内に収まるため、プロキシドホストがまだリンクしていたときから特定のNDメッセージが再生されることを知らない場合があります。ルーターが保護されたプロキシNAを宣伝する場合、古いメッセージのその後のリプレイは、プロキシによって作成されたNCEをオーバーライドします。
Creating the NCE in this way, without reference to accurate subsequent timing, may only be done once. Otherwise, the receiver will notice that the timestamp of the advertisement is old or doesn't match.
この方法でNCEを作成することは、その後のタイミングを正確に参照せずに、一度だけ行うことができます。それ以外の場合、レシーバーは、広告のタイムスタンプが古いか、一致していないことに気付くでしょう。
One way of creating a sequence of replayable messages that have timestamps likely to be accepted is to pretend to do an unsecured DAD on the address each second while the MN is at home. The attacker saves each DAD defense in a sequence. The granularity of SEND timestamp matching is around one second, so the attacker has a set of SEND NAs to advertise, starting at a particular timestamp, and valid for as many seconds as the original NA gathering occurred.
タイムスタンプが受け入れられる可能性が高い一連の再生可能なメッセージを作成する1つの方法は、MNが自宅にいる間に毎秒アドレスで無担保の父親をするふりをすることです。攻撃者は、各お父さんの防御を順番に保存します。送信タイムスタンプマッチングの粒度は約1秒であるため、攻撃者は特定のタイムスタンプから始まる広告を掲載する一連の送信nasを持ち、元のNAギャザリングが発生したときに数秒間有効です。
This sequence may then be played against any host that doesn't have a timestamp history for that MN, by tracking the number of seconds elapsed since the initial transmission of the replayed NA to that victim, and replaying the appropriate cached NA.
このシーケンスは、そのMNのタイムスタンプの履歴を持たないホストに対して再生される場合があります。これは、その犠牲者に再生されたNAの最初の送信以来経過した秒数を追跡し、適切なキャッシュされたNAを再生します。
Where certificate-based authorization of ND proxy is in use, the origination/starting timestamp of the delegated authority may be used to override a replayed (non-proxy) SEND NA, while also ensuring that the Proxy NA's timestamp (provided by the proxy) is fresh. A returning MN would advertise a more recent timestamp than the delegated authority and thus override it. This method is therefore not subject to the above attack, since the proxy advertisement's certificate will have a timestamp greater than any replayed messages, preventing it from being overridden.
NDプロキシの証明書ベースの承認が使用されている場合、委任された当局のオリジネーション/開始タイムスタンプを使用して、再生された（非プロキシ）NAをオーバーライドすると同時に、プロキシNAのタイムスタンプ（プロキシが提供する）を保証することもできます。新鮮です。戻ってくるMNは、委任された当局よりも最近のタイムスタンプを宣伝し、したがってそれをオーバーライドします。したがって、この方法は上記の攻撃の対象ではありません。プロキシ広告の証明書には、再生されたメッセージよりも大きなタイムスタンプがあり、オーバーライドされないようにするためです。
James Kempf and Dave Thaler particularly contributed to work on this document. Contributions to discussion on this topic helped to develop this document. The authors would also like to thank Jari Arkko, Vijay Devarapalli, Mohan Parthasarathy, Marcelo Bagnulo, Julien Laganier, Tony Cheneau, Michaela Vanderveen, Sean Shen, and Sheng Jiang for their comments and suggestions.
James KempfとDave Thalerは、この文書の作業に特に貢献しました。このトピックに関する議論への貢献は、この文書の開発に役立ちました。著者はまた、ジャリ・アークコ、ヴィジェイ・デヴァラパリ、モハン・パルタサラシー、マルセロ・バグヌロ、ジュリアン・ラガニエ、トニー・チェノー、ミカエラ・ヴァンダービーン、ショーン・シェン、そして彼らのコメントと提案に感謝したいと思います。
Jean-Michel Combes is partly funded by MobiSEND, a research project supported by the French 'National Research Agency' (ANR).
Jean-Michel Combesは、フランスの「国家研究機関」（ANR）がサポートする研究プロジェクトであるMobisendによって部分的に資金提供されています。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]オーラ、T。、「暗号化されたアドレス（CGA）」、RFC 3972、2005年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389] Thaler、D.、Talwar、M。、およびC. Patel、「Neighbor Discovery Proxies（ND Proxy）」、RFC 4389、2006年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trustモデルと脅威」、RFC 3756、2004年5月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963] Devarapalli、V.、Wakikawa、R.、Petrescu、A。、およびP. Thubert、「ネットワークモビリティ（NEMO）基本的なサポートプロトコル」、RFC 3963、2005年1月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380] Soliman、H.、Castelluccia、C.、Elmalki、K。、およびL. Bellier、「階層モバイルIPv6（HMIPV6）モビリティ管理」、RFC 5380、2008年10月。
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568] Koodli、R。、「モバイルIPv6高ファストハンドオーバー」、RFC 5568、2009年7月。
[RING] Kempf, J. and C. Gentry, "Secure IPv6 Address Proxying using Multi-Key Cryptographically Generated Addresses (MCGAs)", Work in Progress, August 2005.
[RING] Kempf、J。およびC. Gentry、「マルチキー暗号化されたアドレス（MCGAS）を使用して、IPv6アドレスを保護するIPv6アドレスのプロキシ」、2005年8月の作業。
Authors' Addresses
著者のアドレス
Jean-Michel Combes France Telecom Orange 38 rue du General Leclerc 92794 Issy-les-Moulineaux Cedex 9 France
ジャン・ミシェル・コームズ・フランス・テレコム・オレンジ38 rue general leclerc 92794 issy-les-moulineaux cedex 9フランス
EMail: jeanmichel.combes@orange-ftgroup.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal QC Canada
Suresh Krishnan Ericsson 8400 Decarie Blvd.マウントロイヤルQCカナダの町
EMail: Suresh.Krishnan@ericsson.com
Greg Daley Netstar Logicalis Level 6/616 St Kilda Road Melbourne, Victoria 3004 Australia
グレッグデイリーネットスターロジカリスレベル6/616セントキルダロードメルボルン、ビクトリア3004オーストラリア
Phone: +61 401 772 770
EMail: hoskuld@hotmail.com