[要約] RFC 5991は、Teredoプロトコルのセキュリティの問題を修正するためのアップデートです。その目的は、Teredoの脆弱性を解消し、ユーザーのネットワークセキュリティを向上させることです。
Internet Engineering Task Force (IETF) D. Thaler
Request for Comments: 5991 Microsoft
Updates: 4380 S. Krishnan
Category: Standards Track Ericsson
ISSN: 2070-1721 J. Hoagland
Symantec
September 2010
Teredo Security Updates
Teredoセキュリティの更新
Abstract
概要
The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible.
Teredoプロトコルは、すべてのTeredo IPv6アドレスに埋め込まれた一連のフラグを定義します。このドキュメントは、このフラグフィールドの使用を変更するが、後方互換性のある一連のセキュリティアップデートを指定します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc5991.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5991で取得できます。
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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Specification ...................................................4
3.1. Random Address Flags .......................................4
3.2. Deprecation of Cone Bit ....................................6
4. Security Considerations .........................................7
5. Acknowledgments .................................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
Appendix A. Implementation Status .................................9
Appendix B. Resistance to Address Prediction ......................9
Teredo [RFC4380] defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backwards compatible. This document updates RFC 4380.
Teredo [RFC4380]は、すべてのTeredo IPv6アドレスに埋め込まれた一連のフラグを定義します。このドキュメントは、このフラグフィールドの使用を変更するが、後方互換性のあるセキュリティアップデートのセットを指定します。このドキュメントは、RFC 4380を更新します。
The Flags field in a Teredo IPv6 address has 13 unused bits out of a total of 16 bits. To guard against address-scanning risks [RFC5157] from malicious users, this update randomizes 12 of the 13 unused bits when configuring the Teredo IPv6 address. Even if an attacker were able to determine the external (mapped) IPv4 address and port assigned by a NAT to the Teredo client, the attacker would still need to attack a range of 4,096 IPv6 addresses to determine the actual Teredo IPv6 address of the client.
Teredo IPv6アドレスのフラグフィールドには、合計16ビットのうち13ビットがありません。悪意のあるユーザーからのアドレススキャンリスク[RFC5157]を防ぐために、この更新は、Teredo IPv6アドレスを構成するときに13の未使用ビットのうち12をランダム化します。攻撃者がTeredoクライアントにNATによって割り当てられた外部（マッピング）IPv4アドレスとポートを決定できたとしても、攻撃者は、クライアントの実際のTeredo IPv6アドレスを決定するために4,096のIPv6アドレスの範囲を攻撃する必要があります。
The cone bit in a Teredo IPv6 address indicates whether a peer needs to send Teredo control messages before communicating with a Teredo IPv6 address. Unfortunately, it may also have some value in terms of profiling to the extent that it reveals the security posture of the network. If the cone bit is set, an attacker may decide it is fruitful to port-scan the embedded external IPv4 address and others associated with the same organization, looking for open ports. Deprecating the cone bit prevents the a priori revelation of the security posture of the NAT.
Teredo IPv6アドレスのコーンビットは、Teredo IPv6アドレスと通信する前に、ピアがTeredoコントロールメッセージを送信する必要があるかどうかを示します。残念ながら、ネットワークのセキュリティ姿勢を明らかにする限り、プロファイリングに関してある程度の価値があるかもしれません。コーンビットが設定されている場合、攻撃者は、オープンポートを探して、同じ組織に関連付けられた外部IPv4アドレスおよびその他の外部IPv4アドレスをポートスキャンするのが実りあると判断する場合があります。コーンビットを非難すると、NATのセキュリティ姿勢の先験的な啓示が妨げられます。
This document uses the following terminology, for consistency with [RFC4380].
このドキュメントでは、[RFC4380]との一貫性のために、次の用語を使用します。
Cone NAT: A NAT that maps all requests from the same internal IP address and port to the same external IP address and port. Furthermore, any external host can send a packet to the internal host by sending a packet to the mapped external address and port.
CONE NAT：同じ内部IPアドレスとポートから同じ外部IPアドレスとポートにすべての要求をマッピングするNAT。さらに、外部ホストは、マッピングされた外部アドレスとポートにパケットを送信することにより、内部ホストにパケットを送信できます。
Indirect Bubble: A Teredo control message that is sent to another Teredo client via the destination's Teredo server, as specified in [RFC4380], Section 5.2.4.
間接バブル：[RFC4380]で指定されているように、宛先のTeredoサーバーを介して別のTeredoクライアントに送信されるTeredoコントロールメッセージ。セクション5.2.4。
Local Address/Port: The IPv4 address and UDP port from which a Teredo client sends Teredo packets. The local port is referred to as the Teredo service port in [RFC4380]. The local address of a node may or may not be globally routable because the node can be located behind one or more NATs.
ローカルアドレス/ポート：TeredoクライアントがTeredoパケットを送信するIPv4アドレスとUDPポート。ローカルポートは、[RFC4380]のTeredoサービスポートと呼ばれます。ノードのローカルアドレスは、ノードが1つ以上のNATの後ろに配置できるため、グローバルにルーティング可能である場合があります。
Mapped Address/Port: A global IPv4 address and a UDP port that results from the translation of a node's own local address/port by one or more NATs. The node learns these values through the Teredo protocol specified in [RFC4380]. The mapped address/port can be different for every peer with which a node tries to communicate.
マッピングされたアドレス/ポート：グローバルIPv4アドレスと、1つ以上のNATによるノード独自のローカルアドレス/ポートの変換に起因するUDPポート。ノードは、[RFC4380]で指定されたTeredoプロトコルを介してこれらの値を学習します。マップされたアドレス/ポートは、ノードが通信しようとするピアごとに異なる場合があります。
Network Address Translation (NAT): The process of converting between IP addresses used within an intranet or other private network and Internet IP addresses.
ネットワークアドレス変換（NAT）：イントラネットまたはその他のプライベートネットワークおよびインターネットIPアドレス内で使用されるIPアドレス間の変換プロセス。
Peer: A Teredo client with which another Teredo client needs to communicate.
ピア：別のTeredoクライアントが通信する必要があるTeredoクライアント。
Port-Preserving NAT: A NAT that translates a local address/port to a mapped address/port such that the mapped port has the same value as the local port, as long as that same mapped address/port has not already been used for a different local address/port.
ポート予約済みNAT：ローカルアドレス/ポートをマッピングされたアドレス/ポートに変換するNATが、マッピングされたポートがローカルポートと同じ値を持つように、同じマッピングされたアドレス/ポートがまだ使用されていない限り、ローカルポートと同じ値を持つNAT異なるローカルアドレス/ポート。
Public Address: An external global address used by a NAT.
パブリックアドレス：NATが使用する外部グローバルアドレス。
Restricted NAT: A NAT where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike the cone NAT, an external host can send packets to an internal host (by sending a packet to the external mapped address and port) only if the internal host has first sent a packet to the external host.
制限付きNAT：同じ内部IPアドレスとポートからのすべての要求が同じ外部IPアドレスとポートにマッピングされるNAT。コーンNATとは異なり、外部ホストは、内部ホストが最初に外部ホストにパケットを送信した場合にのみ、内部ホストにパケットを内部ホストに送信できます（外部マッピングアドレスとポートにパケットを送信することにより）。
Teredo Client: A node that implements the client parts of [RFC4380], has access to the IPv4 Internet, and wants to gain access to the IPv6 Internet.
Teredoクライアント：[RFC4380]のクライアント部分を実装し、IPv4インターネットにアクセスし、IPv6インターネットにアクセスしたいと考えています。
Teredo IPv6 Address: An IPv6 address that starts with the prefix 2001:0000:/32 and is formed as specified in Section 4 of [RFC4380].
Teredo IPv6アドレス：プレフィックス2001：0000：/32で始まり、[RFC4380]のセクション4で指定されているように形成されるIPv6アドレス。
Teredo Server: A node that has a globally routable address on the IPv4 Internet, and is used as a helper to provide IPv6 connectivity to Teredo clients.
Teredo Server：IPv4インターネットにグローバルにルーティング可能なアドレスを備えたノードで、TeredoクライアントにIPv6接続を提供するヘルパーとして使用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Teredo addresses are structured, and some of the fields contained in them are fairly predictable. This makes the addresses themselves easier to predict and opens up a vulnerability.
Teredoアドレスは構造化されており、それらに含まれるフィールドの一部はかなり予測可能です。これにより、アドレス自体が予測を容易にし、脆弱性を開きます。
Teredo prefix: This field is 32 bits and has a single IANA-assigned value.
Teredo Prefix：このフィールドは32ビットで、IANAが割り当てられた1つの値があります。
Server: This field is 32 bits and is set to the server in use. The server to use is generally statically configured on the client. This means that overall entropy of the server field will be low, i.e., that the server will not be hard to predict. Attackers could confine their guessing to the most popular server IP addresses.
サーバー：このフィールドは32ビットで、使用中のサーバーに設定されています。使用するサーバーは、通常、クライアントで静的に構成されています。これは、サーバーフィールドの全体的なエントロピーが低くなること、つまりサーバーを予測するのが難しくないことを意味します。攻撃者は、推測を最も人気のあるサーバーIPアドレスに限定できます。
Flags: The Flags field is 16 bits in length, but [RFC4380] provides for only one of these bits (the cone bit) to vary.
フラグ：フラグフィールドの長さは16ビットですが、[RFC4380]は、これらのビットの1つ（コーンビット）のみが変化することを提供します。
Client port: This 16-bit field corresponds to the external port number assigned to the client's Teredo service port. Thus, the value of this field depends on two factors (the chosen Teredo service port and the NAT port assignment behavior), and it therefore is harder to predict the entropy this field will have. If clients tend to use a predictable port number and NATs are often port-preserving, then the port number can be rather predictable.
クライアントポート：この16ビットフィールドは、クライアントのTeredoサービスポートに割り当てられた外部ポート番号に対応しています。したがって、このフィールドの値は2つの要因（選択されたテレドサービスポートとNATポート割り当ての動作）に依存するため、このフィールドが持つエントロピーを予測することは困難です。クライアントが予測可能なポート番号を使用する傾向があり、NATがポート圧力をかけることが多い場合、ポート番号はかなり予測可能です。
Client IPv4 address: This 32-bit field corresponds to the external IPv4 address the NAT has assigned for the client port. In principle, this can be any address in the assigned part of the IPv4 unicast address space. However, if an attacker is looking for the address of a specific Teredo client, they will have to have the external IPv4 address pretty well narrowed down. Certain IPv4 address ranges could also become well known for having a higher concentration of Teredo clients, making it easier to find an arbitrary Teredo client. These addresses could correspond to large organizations that allow Teredo, such as a university or enterprise, or to Internet Service Providers that only provide their customers with RFC 1918 addresses.
クライアントIPv4アドレス：この32ビットフィールドは、クライアントポートに割り当てられたNATが割り当てた外部IPv4アドレスに対応します。原則として、これはIPv4ユニキャストアドレス空間の割り当てられた部分の任意のアドレスになります。ただし、攻撃者が特定のTeredoクライアントのアドレスを探している場合、外部IPv4アドレスをかなり絞り込む必要があります。特定のIPv4アドレス範囲は、Teredoクライアントの集中度が高いことでもよく知られる可能性があり、任意のTeredoクライアントを見つけやすくすることができます。これらの住所は、大学や企業などのテレドを許可する大規模な組織、またはRFC 1918アドレスを顧客に提供するインターネットサービスプロバイダーに対応できます。
Optimizations in scanning can also reduce the number of addresses that need to be checked. For example, for addresses behind a cone NAT, it would likely be easy to probe if a specific port number is open on an IPv4 address, prior to trying to form a Teredo address for that address and port.
スキャンの最適化は、チェックする必要があるアドレスの数も減らすことができます。たとえば、Cone Natの背後にあるアドレスの場合、そのアドレスとポートのTeredoアドレスを形成しようとする前に、IPv4アドレスで特定のポート番号が開いている場合、簡単にプローブすることができます。
Hence, the Flags field specified in [RFC4380], Section 4 is updated as follows:
したがって、[RFC4380]で指定されたフラグフィールドは、次のように更新されます。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|z|Random1|U|G| Random2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C: This flag is specified in [RFC4380], and its use is modified in Section 3.2 below.
C：このフラグは[RFC4380]で指定されており、その使用は以下のセクション3.2で変更されています。
z: This flag is reserved. It MUST be set to zero when the address is constructed, as specified in [RFC4380].
Z：このフラグは予約されています。[RFC4380]で指定されているように、アドレスを構築するときにゼロに設定する必要があります。
Random1: MUST be set to a random value.
ランダム1：ランダム値に設定する必要があります。
U: This flag is specified in [RFC4380].
U：このフラグは[RFC4380]で指定されています。
G: This flag is specified in [RFC4380].
G：このフラグは[RFC4380]で指定されています。
Random2: MUST be set to a random value.
ランダム2：ランダム値に設定する必要があります。
The qualification procedure is specified in [RFC4380], Section 5.2.1, and is modified as follows. Teredo clients SHOULD completely skip the first phase of the qualification procedure and implement only the second phase where it uses the Teredo link-local address with the cone bit set to zero. Consequently, a distinction between cone and restricted NATs can no longer be made. Teredo communication will still succeed, but at the expense of forcing peers to skip case 4 of the sending details specified in [RFC4380], Section 5.2.4. This will result in the same number of indirect bubbles being sent as if the other end were a peer behind a restricted NAT. Even though the peer behind the cone NAT does not need these indirect bubbles, it replies to these indirect bubbles just like it would to any other indirect bubbles. Skipping case 4 is already allowed for reliability reasons (as also specified in [RFC4380], Section 5.2.4), and hence this does not break interoperability, but the result of skipping the first phase of qualification is to force that behavior (which is less efficient, but potentially more reliable) to be taken by peers.
資格手順は[RFC4380]、セクション5.2.1で指定されており、次のように変更されています。Teredoのクライアントは、資格手順の第1フェーズを完全にスキップし、Cone Biteがゼロに設定されたCone Biteを使用してTeredo Link-Localアドレスを使用する2番目のフェーズのみを実装する必要があります。その結果、コーンと制限されたNATの区別はもはや行われません。Teredoコミュニケーションは引き続き成功しますが、[RFC4380]で指定された送信詳細のケース4をスキップすることをピアに強制することを犠牲にして、セクション5.2.4です。これにより、他の端が制限されたNATの背後にあるピアであるかのように、同じ数の間接バブルが送信されます。Cone Natの後ろのピアはこれらの間接的な泡を必要としませんが、他の間接的な泡と同じように、これらの間接的な泡に応答します。ケース4のスキップは、信頼性の理由ですでに許可されています（[RFC4380]、セクション5.2.4で指定されているように）。したがって、これは相互運用性を破りませんが、資格の第1フェーズをスキップした結果は、その行動を強制することです（効率が低いが、潜在的に信頼性が高い）仲間が服用すること。
In addition, clients and relays SHOULD ignore the cone bit in the address of a Teredo peer and treat it as if it were always clear, as specified in [RFC4380], Section 5.2.4 (last paragraph).
さらに、クライアントとリレーは、[RFC4380]で指定されているように、セクション5.2.4（最後の段落）で指定されているように、テレドピアのアドレスのコーンビットを無視し、それを常に明確であるかのように扱う必要があります。
Teredo servers MUST NOT ignore the cone bit for the following reasons.
Teredoサーバーは、次の理由でコーンビットを無視してはなりません。
o The cone bit in the IPv6 source address of a Router Solicitation (RS) from a client controls what IPv4 source address the server should use when sending a Router Advertisement (RA). If this behavior is not preserved, legacy clients will conclude that they are behind a cone NAT even when they are not (because the client WILL receive the RA where previously it would not, since a cone bit set to 1 requires the server to respond from another IP address). They will then set their cone bit and lose connectivity.
o クライアントからのルーター勧誘（RS）のIPv6ソースアドレスのコーンビットは、ルーター広告（RA）を送信するときにサーバーが使用するIPv4ソースアドレスを制御します。この動作が保存されていない場合、レガシーのクライアントは、そうでない場合でもコーンナットの背後にいると結論付けます（クライアントは以前はraを受け取っていないため、コーンビットが1に設定されているため、サーバーが応答する必要があるため別のIPアドレス）。その後、コーンビットを設定し、接続性を失います。
o When the Teredo server sends RAs (or bubbles if it's also a relay), the cone bit in its own Teredo address is set, indicating that it doesn't require bubbles to reach it.
o TeredoサーバーがRAS（またはリレーである場合はバブル）を送信すると、独自のTeredoアドレスのコーンビットが設定されており、到達するにはバブルが必要ないことを示しています。
The basic threat model for Teredo is described in detail in [RFC4380], Section 7, but briefly, the goal is that a Teredo client should be as secure as if a host were directly attached to an untrusted Internet link. This document specifies updates to [RFC4380] that improve the security of the base Teredo mechanism regarding specific threats.
Teredoの基本的な脅威モデルは[RFC4380]、セクション7で詳細に説明されていますが、簡単に言えば、テレドクライアントは、ホストが信頼できないインターネットリンクに直接接続されているかのように安全であることです。このドキュメントは、特定の脅威に関するベーステレドメカニズムのセキュリティを改善する[RFC4380]の更新を指定します。
IPv6 address scanning [RFC5157] by off-path attackers: The Teredo IPv6 Address format defined in [RFC4380], Section 4 makes it relatively easy for a malicious user to conduct an address-scan to determine IPv6 addresses by guessing the external (mapped) IPv4 address and port assigned to the Teredo client. The random address bits guard against address-scanning risks by providing a range of 4,096 IPv6 addresses per external IPv4 address/port. As a result, even if a malicious user were able to determine the external (mapped) IPv4 address and port assigned to the Teredo client, the malicious user would still need to attack a range of 4,096 IPv6 addresses to determine the actual Teredo IPv6 address of the client. Appendix B compares the address prediction resistance of a Teredo address following this specification to that of an address formed using standard IPv6 stateless address autoconfiguration [RFC4862].
IPv6アドレスは、オフパス攻撃者によるスキャン[RFC5157]：[RFC4380]で定義されているTeredo IPv6アドレス形式形式で、セクション4では、悪意のあるユーザーがアドレスSCANを実行して、外部（マッピング）を推測してIPv6アドレスを決定することが比較的簡単になります。Teredoクライアントに割り当てられたIPv4アドレスとポート。ランダムアドレスビットは、外部IPv4アドレス/ポートごとに4,096のIPv6アドレスの範囲を提供することにより、アドレススキャンリスクを防ぎます。その結果、悪意のあるユーザーがTeredoクライアントに割り当てられた外部（マッピング）IPv4アドレスとポートを決定できたとしても、悪意のあるユーザーは4,096のIPv6アドレスの範囲を攻撃する必要があります。クライアント。付録Bでは、この仕様に続くTeredoアドレスのアドレス予測抵抗を、標準のIPv6ステートレスアドレスAutoconfiguration [RFC4862]を使用して形成されたアドレスのアドレスと比較しています。
In order to prevent adversaries from easily guessing the values of the random bits and hence the address, the Random1 and Random2 bits in the Teredo Flags field MUST be constructed following the recommendations for random number generation as specified in [NIST-RANDOM] and [RFC4086].
敵がランダムビットの値、したがってアドレスの値を簡単に推測できないようにするには、[nist-random]および[RFC4086で指定されているランダム数生成の推奨事項に従って、テレドフラグフィールドのランダム1およびランダム2ビットを構築する必要があります。]。
Opening a hole in an enterprise firewall [TUNNEL-SEC]: Teredo is NOT RECOMMENDED as a solution for networks that wish to implement strict controls for what traffic passes to and from the Internet. Administrators of such networks may wish to filter all Teredo traffic at the boundaries of their networks.
エンタープライズファイアウォールに穴を開ける[トンネルSEC]：Teredoは、インターネットとの間でトラフィックが通過するものの厳格なコントロールを実装したいネットワークのソリューションとして推奨されません。このようなネットワークの管理者は、ネットワークの境界ですべてのテレドトラフィックをフィルタリングすることをお勧めします。
The authors would like to thank Remi Denis-Courmont, Fred Templin, Jordi Palet Martinez, James Woodyatt, Christian Huitema, Tom Yu, Jari Arkko, David Black, Tim Polk, and Sean Turner for reviewing earlier versions of this document and providing comments to make this document better. The authors would also like to thank Alfred Hoenes for a careful review of this document.
著者は、レミ・デニス・コースモント、フレッド・テンプリン、ジョルディ・パレット・マルティネス、ジェームズ・ウッディヤット、クリスチャン・フイテマ、トム・ユ、ジャリ・アークコ、デビッド・ブラック、ティム・ポーク、ショーン・ターナーの以前のバージョンをレビューし、コメントを提供してくれたことに感謝します。このドキュメントをより良くします。著者はまた、この文書を慎重にレビューしてくれたAlfred Hoenesにも感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：ネットワークアドレス翻訳（NAT）を介してUDPを介したIPv6のトンネル」、RFC 4380、2006年2月。
[NIST-RANDOM] "NIST SP 800-90, Recommendation for Random Number Generation Using Deterministic Random Bit Generators", March 2007, <http://csrc.nist.gov/publications/ nistpubs/800-90/SP800-90revised_March2007.pdf>.
[nist-random] "nist sp 800-90、決定論的なランダムビットジェネレーターを使用した乱数生成の推奨」、2007年3月、<http://csrc.nist.gov/publications/ nistpubs/800-90/sp800-90revized_march2007。pdf>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[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月。
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008.
[RFC5157] Chown、T。、「ネットワークスキャンに対するIPv6の影響」、RFC 5157、2008年3月。
[TUNNEL-SEC] Hoagland, J., Krishnan, S., and D. Thaler, "Security Concerns With IP Tunneling", Work in Progress, March 2010.
[Tunnel-Sec] Hoagland、J.、Krishnan、S。、およびD. Thaler、「IPトンネリングに関するセキュリティ上の懸念」、2010年3月、進行中の作業。
Deprecation of the cone bit as specified in this document is implemented in Windows Vista and Windows Server 2008.
このドキュメントで指定されているコーンビットの非難は、Windows VistaおよびWindows Server 2008に実装されています。
The random flags specified in this document are implemented in Windows Vista SP1 and Windows Server 2008.
このドキュメントで指定されたランダムフラグは、Windows Vista SP1およびWindows Server 2008に実装されています。
All Windows implementations automatically disable Teredo if they detect that they are on a managed network with a domain controller.
すべてのWindows実装は、ドメインコントローラーを備えたマネージドネットワーク上にあることを検出した場合、Teredoを自動的に無効にします。
This section compares the address prediction resistance of a Teredo address as compared to an address formed using IPv6 stateless address autoconfiguration (SLAAC) [RFC4862].
このセクションでは、IPv6ステートレスアドレスAutoconfiguration（SLAAC）[RFC4862]を使用して形成されたアドレスと比較して、Teredoアドレスのアドレス予測抵抗を比較します。
Let's assume that the attacker knows a Teredo client's external IPv4 address and Ethernet card's vendor. Since the attacker knows the client's external IPv4 address, he does not have to search this space. The attacker does not know the external port (16 bits) and the value of the random bits (12 bits), and he has to search this space. This gives the attacker a total search space of 28 bits (16+12). This compares very favorably with the 24 bits of search space required to find an address configured using SLAAC (when the Ethernet card's vendor is known) as described in Section 2.3 of [RFC5157]. Without the 12 random bits, the search space is limited to only 16 bits, and this is significantly worse than the 24 bits of search space provided by SLAAC.
攻撃者は、Teredoクライアントの外部IPv4アドレスとイーサネットカードのベンダーを知っていると仮定しましょう。攻撃者はクライアントの外部IPv4アドレスを知っているため、このスペースを検索する必要はありません。攻撃者は、外部ポート（16ビット）とランダムビット（12ビット）の値を知らず、このスペースを検索する必要があります。これにより、攻撃者は28ビットの合計検索スペース（16 12）になります。これは、[RFC5157]のセクション2.3で説明されているように、SLAAC（イーサネットカードのベンダーが知られている場合）を使用して構成されたアドレスを見つけるために必要な24ビットの検索スペースと非常に好意的に比較されます。12のランダムビットがないと、検索スペースは16ビットのみに制限されており、これはSLAACが提供する24ビットの検索スペースよりも大幅に悪化しています。
As the knowledge of the attacker decreases, the number of bits of search space in both cases is likely to increase in a relatively similar fashion. The predictability of Teredo addresses will stay comparable to that of SLAAC addresses with the added 12 bits of search space, but will be significantly worse without the random bits.
攻撃者の知識が減少すると、どちらの場合も検索スペースのビット数が比較的類似して増加する可能性があります。Teredoアドレスの予測可能性は、12ビットの検索スペースを持つSLAACアドレスの予測可能性に匹敵しますが、ランダムビットなしでは著しく悪化します。
Authors' Addresses
著者のアドレス
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
Suresh Krishnan Ericsson 8400 Decarie Blvd.QCカナダのマウントロイヤルの町
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
James Hoagland Symantec Corporation 350 Ellis St. Mountain View, CA 94043 USA
James Hoagland Symantec Corporation 350 Ellis St. Mountain View、CA 94043 USA
EMail: Jim_Hoagland@symantec.com
URI: http://symantec.com/