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 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.
近隣探索プロキシは、モバイルノードがホームエージェントをプロキシとして動作できるようにすることで、家にいないときに、ホームネットワーク上のノードから到達可能性を提供するために、モバイル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.
近隣探索プロキシは、現在、セキュア近隣探索（SEND）を使用して保護することはできません。今日、SENDはアドレスを広告するノードは、アドレスの所有者と、そのノードのための適切な公開鍵と秘密鍵の所有物であることを前提としています。この文書では、プロキシ近隣探索のための既存の練習を送信するためにどのように関係するかを説明します。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
近隣探索プロキシは、IPv6近隣探索[RFC4861]で定義されています。これは、（モバイルIPv6の高速ハンドオーバ、プレフィックスが複数のリンク[RFC4389]をスパンする必要があるネットワークにもモバイルIPv6 [RFC3775]（したがってネットワークモビリティ（NEMO）のようなモバイルIPv6ベースのプロトコルで、[RFC3963]で使用され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.
近隣探索プロキシは、近隣要請（NSS）を監視、および近隣広告（NAS）に答えるために、別のデバイス、プロキシに依存しています。プロキシ経由でこれらのプロキシ近隣広告、ダイレクトデータトラフィック。プロキシトラフィックは、エンド宛先に転送されます。
This section describes the different scenarios where the interaction between Secure Neighbor Discovery (SEND) and ND Proxy raises issues.
このセクションでは、セキュア近隣探索（SEND）と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に焦点を当てているが、SENDと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モバイルノード（MNの）ために、起こって既存のセッションを維持するために、または1つは、ホームネットワークを離れた場合でも、新しいセッションを許可する必要があります。
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ヘッダのソースアドレスフィールド内のものと同じではないので、この場合には、SENDは適用できません。
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
凡例：SL3：ソースIPv6はNSアドレス：近隣要請DL3：デスティネーションIPv6アドレスNA：近隣広告SL2：ソースリンク層アドレスRS：ルーター要請DL2：デスティネーションリンク層アドレスRA：ルータアドバタイズメントTA：ターゲットアドレスSLL / TLL：ソース/ターゲットリンク層アドレスオプション
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が設定されている場合は暗号的に生成されたアドレス（CGAs）[RFC3972]は、[RFC3971]を使用することにより、SENDそのCGAsのための近隣キャッシュエントリ（のNCE）のそのリンク上のネイバーによって確立を確保することができますが。 SENDはセキュリティが指定されたアドレスがアドレスを生成し、公開鍵/秘密鍵のペアを所有されるようにするには近隣広告を送信するノードが必要です。
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]のために、SEND使用することはできません。
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が訪問先ネットワークに、ホームネットワークから移動した場合、プロキシは、セキュアな[RFC3971]としてフラグ付けされているMNの既存の近隣キャッシュエントリを上書きする必要があります。これは、そうでない場合は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.
現在SEND仕様では、プロキシによって送信された任意の勧誘や広告が安全でないとなりますので、固定して、それにフラグが設定されているため、自宅の住所のための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.
セキュリティで保護されたプロキシサービスを提供することができない場合は、プロキシの広告は、攻撃が発生したことを実現する受信ホストなしに不正なプロキシによって上書きされることがあります。これは、SENDが展開されていないネットワークで何が起こるかと同じです。
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交換時設定ペイロードを使用してアドレスを割り当てます。セキュリティゲートウェイは、このアドレスに送信されたパケットを受信する必要があります。そうするための一つの方法は、プロキシNDメッセージになります。
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.
近隣探索（ND）プロキシ仕様[RFC4389]は、古典的なブリッジの代替方法を規定します。ちょうど古典ブリッジと同様に、複数のリンク層セグメントはなく、IP層ではなく、リンク層ブリッジでプロキシの助けを借りて、単一のセグメントにブリッジされます。この場合、その送信元と宛先のMACアドレスを修正しながら、プロキシはメッセージを転送し、それは彼らの募集を書き換え、フラグとリンク層アドレスオプションをオーバーライドします。
This rewriting is incompatible with SEND signed messages for a number of reasons:
この書き換えは、多くの理由からSEND署名されたメッセージと互換性がありません。
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.
このように、SENDの勧誘のプロキシ変更は、プロキシノードとプロキシノードまたはプロキシ機能を持つ新しいオプションの作成の間に資格情報の共有を必要とするかもしれません。
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プロキシは[RFC4389]（すなわち、IPソースアドレスが同じままである）も変更後、元のアドレスを含むメッセージを再送します。 RFC 4389で指定され、図2は、プロキシ近隣勧誘および広告のためのパケットフォーマットを記述する。
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
凡例：SL3：ソースIPv6はNSアドレス：近隣要請DL3：デスティネーションIPv6アドレスNA：近隣広告SL2：ソースリンク層アドレスDL2：デスティネーションリンク層アドレスTA：ターゲットアドレスSLL / TLL：ソース/ターゲットリンク層アドレスオプションを
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.
ブリッジ状のプロキシのための追加（および文書化されていない）の要件は、ルータ発見の動作です。ルータディスカバリパケットは同様に近隣キャッシュの状態を変更し、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
凡例：SL3：送信元IPv6アドレスRS：ルーター要請DL3：デスティネーションIPv6アドレスRA：ルータアドバタイズメントSL2：ソースリンク層アドレスDL2：デスティネーションリンク層アドレスTA：ターゲットアドレスSLL / TLL：ソース/ターゲットリンク層アドレスオプション
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.
得られたプロキシ・メッセージは、複数のリンクとの間のプロキシが未要請（有効NDのみ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）がプロキシアドレスのための既存のセキュア近隣探索手順は現在なく、SENDノードからのすべての近隣広告等しいソースとターゲットアドレスが要求され、そして送信機によって署名されます。
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.
SENDメッセージ上の署名は、メッセージの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.
そのため、プロキシ近隣広告サービスを提供したいルータは、これらのメッセージに既存のSENDプロシージャを使用することはできません。
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.
ホストがオンリンクではなく、プロキシされているデバイスとのセッションを確立することを望むかもしれません。 SENDホストとして、それは安全な手順を使用して近隣キャッシュエントリを作成することを好みます。 SEND署名が既存のプロキシ近隣広告に適用することはできませんので、プロキシ近隣広告を受信するために、非SENDの広告を受け入れる必要があります。
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は、暗号化生成アドレス（CGAs）[RFC3972]と一緒に使用するための1つの公開鍵と署名フォーマットを定義します。 CGAsは、特定の公開鍵/秘密鍵のペアにアドレスの所有権を結びつけることを意図しています。
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.
現在定義されているようSENDにおいて、（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].
プロキシは、自身のCGA、既存のCGAオプションとRSA署名オプションを使用して、メッセージの送信元IPv6アドレスを置き換える場合は、プロキシのCGAに対応したものと交換する必要があります。 SEND仕様に従って有効であるために、近隣広告メッセージのターゲットアドレスは、送信元アドレス[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のための既存のセキュリティチェックは、失敗します。この場合、保護されたプロキシ近隣探索を達成するために、拡張された認証機構は、送信のために必要とされてもよいです。
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ベースの認証にSENDの拡張のためのメカニズムを提供します。メッセージは、任意の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.
SEND内で、そのようなルーティングなどのより高度な機能は、認可委譲発見を使用して、証明書パス検証によって許可されてもよいです。
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メソッドへの拡張を提供しながらのみSENDメッセージを受け入れるように構成されている場合、ホストを送信既存のサイレント、検証不可能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.
プロキシ近隣探索の開始は、アドレス[RFC4862]の重複アドレス検出（DAD）のチェックを必要とします。これらDADチェックは、ターゲットがプロキシアドレスであると、不特定の送信元アドレスから、近隣要請を送信することによって実行される必要があります。
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.
既存のSENDの手順では、DAD NS上のCGA試験に使用されているアドレスは、ターゲットアドレスです。プロキシアドレスの所有者が存在しないときにこのメッセージを発信プロキシは、このアドレスのCGAベースの署名を生成することができず、セキュリティで保護されていないNSでDADを行う必要があります。プロキシが応答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つのSENDノード間のDADの衝突があった場合には、プロキシアドレスを防御NAを変更する権限を持っていない可能性があります。この場合、プロキシは、まだそれが受信ノードにSEND検証を失敗した場合でも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.
プロキシ近隣探索がproxierに（不在のアドレスの所有者に代わって）権限委譲が必要です。この権限がないと、リンク上の他のデバイスは、広告主を信頼する理由がありません。
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.
既存の信頼関係は、二つの別の方法でプロキシの権限を提供することに自分自身を貸します。
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.
まず、上記SENDルータの認証機構は、認定のルータにアドレスドメインにルーティングする責任がある組織からの委任を提供しています。とても認定ルータはリンクのアドレス範囲の一部を形成し、それ自体が存在しないノードに対してサービスを提供するために信頼することができると主張することができます。プロキシされているデバイスは、いずれかのネットワークのルータによってプロキシに権利を付与することができ、または暗黙的に許可されたルータであることのおかげでプロキシに許可されます。
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、公開鍵と秘密鍵の所有者は、アドレスの使用についての信頼できると見られています。このアドレスの所有者がproxierのアドレスと公開鍵情報を署名することができたなら、プロキシが知られており、プロキシサービスの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
モバイルIPv6は、モバイルノードとホームエージェント間のセキュリティ・アソシエーションを持っています。モバイルノードは、それが家にいないことを示すために、ホームエージェントにバインディングアップデートを送信します。これは、ことを意味し
Mobile Node wishes the Home Agent to begin proxy Neighbor Discovery operations for its home address(es).
モバイルノードは、そのホームアドレス（複数可）のプロキシ近隣探索操作を開始するためにホームエージェントを願っています。
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の）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リング署名[RING]で署名されています。 （;標準化過程プロトコルが開発される前に、追加の研究が必要とされている[RING]および他の同様のソリューションが広くセキュリティコミュニティに受け入れられていないために基礎である暗号化アルゴリズムことに注意してください。）
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.
このようなソリューションを設計する一つの方法は、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.
リンク拡張環境では、プロキシの役割がより明確にルータのものから分離されています。 SENDでは、ルータはアドバタイズするルーティングインフラストラクチャによって承認されることを期待して、彼らがフォワーディング状態を変更することを可能にするためにホストにこの権限を提供することができます。
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.
これは、プロキシが操作のために許可されている場合は、プロキシ近隣探索パケットを受信したノードは、すぐに確認することができます。そのようないくつかの信頼の基盤、および以下で議論されているプロキシ環境での要件があります。
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から独自のNDメッセージに署名するようSENDプロキシ/ルータとして設定することができます。
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.
SENDノードの権限は、自身のCGAアドレスが無資格情報を持つプロキシに取って代わられることはない宣伝するので、これは、プロキシがリンク間移動SENDノードの近隣キャッシュエントリを更新しようとする場合には役に立たないことがあります。
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.
この場合には、一点に委任された権限は、遠く信頼の原点からプロキシに（おそらく希釈形態で）redelegatedされなければなりません。
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は、プロキシBへのTのプロキシに権限をredelegateする必要があります。これは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.
ネットワークが設定されている場合、プロキシ証明書の署名のいずれか動的（アイデンティティおよび権限情報の交換を必要とする）、または静的に行うことができます。
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ホストが動作をプロキシ認証するためにブリッジ・プロバイダを信頼することが依然として可能です。
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のように）ルータベースのプロキシ権限の添加以外送信するために少し修正を必要とするであろう、とプロキシは、実際にSENDホスト[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.
ホストは、プロキシ近隣広告を受信すると、その承認委任発見が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.
オリジナルの近隣探索メッセージは無担保である場合は、そのノードのためのセキュリティで保護されたプロキシサービスを提供していないの引数があります。
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と拡張ネットワークのケースでは、ノードは、ネットワークに戻って到着し、ノードのリンク層アドレスに既存の近隣キャッシュ・エントリをマッピングするために他のホストを必要とし得ます。リンク層アドレスのマッピングの再到着ノードのオーバーライドは、この場合にSENDせずに発生します。
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).
SEND保護なしで任意のノードは、到着を偽装することができ、効果的に拡張されたネットワーク経由でサービスを盗むことは注目に値します。これは、非プロキシの場合と同様であるため、（送信元アドレスが交換されている場合、攻撃者の身元をマスクしてもよいが）プロキシの存在によって著しく悪化していません。
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).
プロキシされたメッセージを超える署名が使用された場合は、近隣キャッシュエントリの再到来とオーバーライドが許可されなければならないので、署名は少なくともプロキシが（元の送信者がいたとしても）なりすましていなかったことを示します。
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.
セキュリティで保護されたプロキシはルータが偽装され、その後、拡張されたネットワークのさまざまな部分に切り替えされていないことを保証するために、署名したルータ広告メッセージを送信するために非SENDルータの場合は、しかし、それが可能です。
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.
これは、起源は再び無担保であるという問題がでており、ネットワーク上の任意のノードは、無担保アドレスに対してルータ広告をだますことができます。これらの偽装されたメッセージは、SENDルータからunspoofedのメッセージから（非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の）におけるモバイル・アクセス・ゲートウェイの（MAGの）入口リンクローカルアドレス[RFC5213]として、同じアドレスを有します。
o Nodes having a common anycast address [RFC4291].
Oノードは、共通のエニーキャストアドレス[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（すなわち、公開鍵と秘密鍵のペア）で使用されるセキュリティ材料は、すべてのMAG間で共有されることを前提としています。後者の場合には、何の解決今日はありません。しかし、同じように、一般的なエニーキャストアドレスを持つノードは、セキュリティ材料を共有できることを前提とすることができるはずです。
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.
同じアドレスを守る多くのノードが同じ管理ドメイン内にないとき（例えば、異なる管理ドメインではなく、同じPMIPv6ドメイン内のMAGは、[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.
証明書の代表団は、その代わりに、NDプロキシを引き受けるために、プロキシHAに新しい資格情報の転送に依存しています。 DADが行われるまで結合を施行することができないので、[RFC3775]に記載されているように、プロキシ権限の委譲は、必ずしも、バインディングACKを復帰に先行します。上記の場合に、結合プロセスの一部として作成に入るホームトンネルは、証明書パス要請または広告[RFC3971]の輸送のために必要とされ得ます。これは、潜在的な鶏と卵の問題を構成しています。家庭バインディングセマンティクスまたは証明書の輸送を当初の変更が必要とされていますか。証明書がトンネリングされることなく、MNの気付アドレス（CoA）との間に明確かつHAに送信された場合、これは些細なことがあります。
All of the presented methods rely on accurate timekeeping on the receiver nodes of Neighbor Discovery Timestamp Options.
提示した方法の全ては、近隣探索タイムスタンプオプションの受信ノードに正確な計時に依存しています。
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.
ルータ認定代理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秒ごとに無担保DADを行うことをふりをすることです。攻撃者は、シーケンス内の各DADの防衛を節約できます。元のNA収集が発生したとして送信タイムスタンプマッチングの粒度は、約1秒であるので、攻撃者は、特定のタイムスタンプから始まる、アドバタイズするSEND、NASの組を有し、そしてなどの多く秒間有効。
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.
このシーケンスは、その被害者へのリプレイNAの最初の送信からの経過秒数を追跡し、適切なキャッシュされたNAを再生することによって、そのMNのためのタイムスタンプの歴史を持っていない任意のホストと対戦することができます。
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.
ジェームズ・ケンプとDaveターラーは特に、この文書上で動作するように貢献しました。このトピックに関する議論への貢献は、このドキュメントの開発に役立ちました。著者はまた、彼らのコメントや提案のためのヤリArkko、ビジェイDevarapalli、モハンパルタサラティ、マルセロBagnulo、ジュリアンLaganier、トニーCheneau、ミカエラVANDERVEEN、ショーン・シェン、とシェン・ジャンに感謝したいと思います。
Jean-Michel Combes is partly funded by MobiSEND, a research project supported by the French 'National Research Agency' (ANR).
ジャン・ミッシェル・Combesのは、部分的にMobiSEND、フランスの「国立研究庁（ANR）でサポートされている研究プロジェクトによって資金を供給されます。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、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.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389]ターラー、D.、Talwar、M.、およびC.パテル、 "近隣探索プロキシ（NDプロキシ）"、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.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、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.、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、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.、ペトレスク、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.
[Ramphsi 5213] gundavelli、S。、Leunjiは、K.、Devarapalliは、VEの。、Chaudhuriの、K.、aとb。パティル、 "プロキシモバイル20 6"、rphak 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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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]ソリマン、H.、カステルッシア、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]ケンプ、J.とC.ジェントリー、「マルチキー暗号的に生成されたアドレスを使用したセキュアなIPv6アドレスのプロキシ（MCGAs）」、進歩、2005年8月の作業。
Authors' Addresses
著者のアドレス
Jean-Michel Combes France Telecom Orange 38 rue du General Leclerc 92794 Issy-les-Moulineaux Cedex 9 France
ジャン・ミッシェル・Combesのフランステレコムオレンジ38 RUEデュ一般ルクレール92794イシレムリノーセデックス9、フランス
EMail: jeanmichel.combes@orange-ftgroup.com
メールアドレス：jeanmichel.combes@orange-ftgroup.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal QC Canada
スレシュクリシュナンエリクソン8400 Decarie大通りマウントロイヤルQCカナダの町
EMail: Suresh.Krishnan@ericsson.com
メールアドレス：Suresh.Krishnan@ericsson.com
Greg Daley Netstar Logicalis Level 6/616 St Kilda Road Melbourne, Victoria 3004 Australia
グレッグデイリーネットスターLogicalisレベル616分の6セントキルダロードメルボルン、ビクトリア3004オーストラリア
Phone: +61 401 772 770 EMail: hoskuld@hotmail.com
電話：+61 401 772 770 Eメール：hoskuld@hotmail.com