Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6169 Ericsson
Category: Informational D. Thaler
ISSN: 2070-1721 Microsoft
J. Hoagland
Symantec
April 2011
Security Concerns with IP Tunneling
Abstract
抽象
A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues.
IPトンネルでのセキュリティ上の懸念の数は、このメモに記載されています。このドキュメントの対象読者は、ネットワーク管理者や将来のプロトコルの開発者が含まれています。このドキュメントの主な目的は、展開として、IPトンネルでセキュリティ問題に関する意識レベルを上げると、これらの問題を緩和するための戦略を提案することです。
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/rfc6169.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6169で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 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ライセンスのテキストを含める必要があり、この文書から抽出されました。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................2
2. Tunnels May Bypass Security .....................................3
2.1. Network Security Bypass ....................................3
2.2. IP Ingress and Egress Filtering Bypass .....................5
2.3. Source Routing after the Tunnel Client .....................6
3. Challenges in Inspecting and Filtering Content of
Tunneled Data Packets ...........................................7
3.1. Inefficiency of Selective Network Filtering of All
Tunneled Packets ...........................................7
3.2. Problems with Deep Packet Inspection of Tunneled
Data Packets ...............................................8
4. Increased Exposure Due to Tunneling .............................9
4.1. NAT Holes Increase Attack Surface ..........................9
4.2. Exposure of a NAT Hole ....................................11
4.3. Public Tunnels Widen Holes in Restricted NATs .............12
5. Tunnel Address Concerns ........................................13
5.1. Feasibility of Guessing Tunnel Addresses ..................13
5.2. Profiling Targets Based on Tunnel Address .................14
6. Additional Security Concerns ...................................15
6.1. Attacks Facilitated by Changing Tunnel Server Setting .....15
7. Mechanisms to Secure the Use of Tunnels ........................17
8. Acknowledgments ................................................18
9. Security Considerations ........................................18
10. Informative References ........................................18
With NAT devices becoming increasingly more prevalent, there have recently been many tunneling protocols developed that go through NAT devices or firewalls by tunneling over UDP or TCP. For example, Teredo [RFC4380], Layer Two Tunneling Protocol Version 2 (L2TPv2) [RFC2661], and Layer Two Tunneling Protocol Version 3 (L2TPv3) [RFC3931] all tunnel IP packets over UDP. Similarly, many Secure Socket Layer (SSL) VPN solutions that tunnel IP packets over HTTP (and hence over TCP) are deployed today.
NATデバイスがますます普及してきてと、最近、UDPまたはTCP上のトンネリングによって、NATデバイスやファイアウォールを通過開発し、多くのトンネリングプロトコルがありました。例えば、Teredoの[RFC4380]、レイヤ2トンネリングプロトコルバージョン2（L2TPv2）[RFC2661]、およびレイヤ2トンネリングプロトコルバージョン3（L2TPv3の）[RFC3931] UDP上すべてのトンネルIPパケット。同様に、多くのSecure Socket Layer（SSL）VPNソリューションは、HTTPを介してトンネルIPパケット（したがって、TCP経由）は本日配備されています。
This document discusses security concerns with tunneling IP packets and includes recommendations where relevant.
この文書では、トンネリングIPパケットでセキュリティ上の問題を説明し、関連する場合の推奨事項が含まれています。
The primary intent of this document is to help improve security deployments using tunnel protocols. In addition, the document aims to provide information that can be used in any new or updated tunnel protocol specification. The intended audience of this document includes network administrators and future protocol developers.
このドキュメントの主な目的は、トンネルプロトコルを使用して、セキュリティの展開を改善するためです。また、ドキュメントは、任意の新しいまたは更新されたトンネルプロトコル仕様で使用することができる情報を提供することを目的とします。このドキュメントの対象読者は、ネットワーク管理者や将来のプロトコルの開発者が含まれています。
Tunneled IP traffic may not receive the intended level of inspection or policy application by network-based security devices unless such devices are specifically tunnel aware. This reduces defense in depth and may cause security gaps. This applies to all network-located devices and to any end-host-based firewalls whose existing hooking mechanism(s) would not show them the IP packet stream after the tunnel client does decapsulation or before it does encapsulation.
そのようなデバイスは、特にトンネル認識しない限り、トンネル化IPトラフィックは、ネットワークベースのセキュリティ装置によって検査やポリシー適用の意図レベルを受けることができません。これは、深さで防衛を軽減し、セキュリティのギャップが発生することがあります。これは、すべてのネットワークにあるデバイスに、その既存のフッキングメカニズム（s）はトンネルクライアントは、カプセル化解除をした後、または、それがカプセル化を行う前に、それらをIPパケットストリームを示さない任意のエンドホストベースのファイアウォールに適用されます。
Evasion by tunneling is often a problem for network-based security devices such as network firewalls, intrusion detection and prevention systems, and router controls. To provide such functionality in the presence of tunnels, the developer of such devices must add support for parsing each new protocol. There is typically a significant lag between when the security developer recognizes that a tunnel will be used (or will be remotely usable) to a significant degree and when the parsing can be implemented in a product update, the update can be tested and released, and customers can begin using the update. Late changes in the protocol specification or in the way it is implemented can cause additional delays. This becomes a significant security concern when a delay in applied coverage is occurring frequently.
トンネリングによる回避は、多くの場合、このようなネットワークファイアウォール、侵入検知および防止システム、およびルータのコントロールなどのネットワークベースのセキュリティデバイスのための問題です。トンネルの存在下で、このような機能を提供するために、このようなデバイスの開発者は、それぞれの新しいプロトコルを解析するためのサポートを追加する必要があります。そこセキュリティ開発者が有意な程度までトンネルが使用される（またはリモート使用可能であろう）ことを認識し、解析は、製品の更新で実施することができる場合、更新がテストされ、解除することができるときとの間に有意な遅れは典型的には、そして顧客は、アップデートの使用を開始することができます。プロトコル仕様で、または、それが実装されている方法で、後期の変更は、追加の遅延を引き起こす可能性があります。これが適用される範囲の遅延が頻繁に発生している重大なセキュリティ上の問題となります。
One way to cut down on this lag is for security developers to follow the progress of new IETF protocols, but this will still not account for any new proprietary protocols.
セキュリティ開発者が新しいIETFプロトコルの進行を追跡するために、このタイムラグを削減する一つの方法ですが、これはまだ、新しい独自のプロトコルを考慮しています。
For example, for L2TP or Teredo, an unaware network security device would inspect or regulate the outer IP and the IP-based UDP layer as normal, but it would not recognize that there is an additional IP layer contained inside the UDP payload to which it needs to apply the same controls as it would to a native packet. (Of course, if the device discards the packet due to something in the IP or UDP header, such as referring to an unknown protocol, the embedded packet is no longer a concern.) In addition, if the tunnel does encryption, the network-based security device may not be able to do much, just as if IPsec end-to-end encryption were used without tunneling.
例えば、L2TPまたはTeredoのため、気付かないネットワークセキュリティデバイスは、点検又は調節通常、外側IPとIPベースのUDP層が、それはそれれるUDPペイロード内部に含まれる追加のIP層が存在することを認識しないであろうそれが本来のパケットをする場合と同じ制御を適用する必要があります。 （デバイスは、未知のプロトコルを参照するように、起因IP又はUDPヘッダ内の何かにパケットを廃棄する場合はもちろん、埋め込みパケットは、もはや関心事ではない。）また、トンネルは、ネットワーク - を暗号化しない場合IPsecのエンドツーエンドの暗号化をトンネリングすることなく使用した場合のベースのセキュリティデバイスは、同じように、非常に行うことができない場合があります。
Network security controls not being applied must be a concern to those that set them up, since those controls are supposed to provide an additional layer of defense against external attackers. If network controls are being bypassed due to the use of tunneling, the strength of the defense (i.e., the number of layers of defense) is reduced. Since security administrators may have a significantly reduced level of confidence without this layer, this becomes a concern to them.
適用されていないネットワーク・セキュリティ・コントロールは、これらのコントロールは、外部の攻撃者に対する防御の追加の層を提供することになっていることから、それらを設定するものと懸念しなければなりません。ネットワークコントロールが原因トンネリングの使用にバイパスされている場合、防御の強さ（すなわち、防御の層数）が低減されます。セキュリティ管理者は、この層のない自信を大幅に低減されたレベルを有することができるので、これは彼らに問題となります。
One implication of the security control bypass is that defense in depth has been reduced, perhaps down to zero unless a local firewall is in use as recommended in [RFC4380]. However, even if there are host-based security controls that recognize tunnels and all controls that were maintained by the network are available on the host, security administrators may not have configured them with full security control parity. Thus, there may be gaps in desired coverage.
セキュリティ制御バイパスの意味は[RFC4380]に推奨されているように、ローカルファイアウォールが使用されていない限り深さにおける防御は、おそらくゼロまで低減されていることです。ホスト上で利用可能ですが、トンネルやネットワークによって維持されたすべてのコントロールを認識し、ホストベースのセキュリティコントロールがある場合でも、セキュリティ管理者は、完全なセキュリティ制御パリティとそれらを構成していない可能性があります。したがって、所望のカバレッジにギャップがあってもよいです。
Compounding this is that, unlike what would be the case for native IP, some network administrators will not even be aware that their hosts are globally reachable if the tunnel provides connectivity to/from the Internet; for example, they may not be expecting this for hosts behind a stateful firewall. In addition, Section 3.2 discusses how it may not be efficient to find all tunneled traffic for network devices to examine.
これを配合してネイティブIPのためのケースであるものとは異なり、いくつかのネットワーク管理者でもトンネルに/インターネットからの接続を提供する場合、そのホストがグローバルに到達可能であることを認識していないだろう、ということです。例えば、彼らは、ステートフルファイアウォールの背後にあるホストのためにこれを期待することはできません。また、3.2節では、ネットワークデバイスが検討するために、すべてのトンネルトラフィックを見つけることが効率的ではないかもしれない方法について説明します。
Security administrators who do not consider tunneling an acceptable risk should disable tunnel functionality either on the end nodes (hosts) or on the network nodes at the perimeter of their network. However, there may be an awareness gap. Thus, due to the possible negative security consequences, tunneling functionality should be easy to disable on the host and through a central management facility if one is provided.
許容できるリスクをトンネリング考慮していないセキュリティ管理者は、ネットワークの境界でエンドノード（ホスト）またはネットワーク・ノード上のトンネル機能のいずれかを無効にする必要があります。しかし、意識のギャップがあるかもしれません。このように、起因するセキュリティに悪影響する可能性に、トンネリング機能は、1つが提供されている場合、ホスト上と中央管理機能によって無効にすることは容易でなければなりません。
To minimize security exposure due to tunnels, we recommend that a tunnel be an interface of last resort, independent of IP version. Specifically, we suggest that when both native and tunneled access to a remote host is available, the native access be used in preference to tunneled access except when the tunnel endpoint is known to not bypass security (e.g., an IPsec tunnel to a gateway provided by the security administrator of the network). This should also promote greater efficiency and reliability.
トンネルによるセキュリティリスクを最小限に抑えるために、我々は、トンネルがIPバージョンとは無関係に、最後のインタフェース、することをお勧めします。具体的には、ネイティブとの両方がリモートホストへのアクセスが利用可能であるトンネリング場合、ネイティブアクセストンネルエンドポイントが（ないバイパスセキュリティにはよく知られている場合を除いてトンネリングアクセスに優先して使用することを示唆している、例えば、によって提供ゲートウェイへのIPsecトンネルネットワークのセキュリティ管理者）。これはまた、より高い効率と信頼性を促進すべきです。
Note that although Rule 7 of [RFC3484], Section 6 will prefer native connectivity over tunnels, this rule is only a tie-breaker when a choice is not made by earlier rules; hence, tunneling mechanisms that are tied to a particular range of IP address space will be decided based on the prefix precedence. For example, using the prefix policy mechanism of [RFC3484], Section 2.1, Teredo might have a precedence of 5 so that native IPv4 is preferred over Teredo.
[RFC3484]のルール7は、第6トンネル上のネイティブ接続を好むであろうが、このルールは、選択は、以前のルールによって行われていないタイブレーカのみであることに注意してください。したがって、IPアドレス空間の特定の範囲に関連付けられていトンネリングメカニズムは、接頭辞の優先順位に基づいて決定されます。例えば、[RFC3484]、セクション2.1のプレフィックスポリシーメカニズムを使用して、TeredoはネイティブのIPv4のTeredo好まれるように5の優先順位を持っているかもしれません。
IP addresses inside tunnels are not subject to ingress and egress filtering in the network they tunnel over, unless extraordinary measures are taken. Only the tunnel endpoints can do such filtering.
特別の措置が取られない限り、トンネル内のIPアドレスは、それらトンネルを介してネットワーク内の入力および出力のフィルタリングを受けません。唯一のトンネルエンドポイントは、このようなフィルタリングを行うことができます。
Ingress filtering (sanity-checking incoming destination addresses) and egress filtering (sanity-checking outgoing source addresses) are done to mitigate attacks and to make it easier to identify the source of a packet and are considered to be a good practice. For example, ingress filtering at the network perimeter should not allow packets with a source address that belongs to the network to enter the network from outside the network. This function is most naturally (and in the general case, by requirement) done at network boundaries. Tunneled IP traffic bypassing this network control is a specific case of Section 2.1, but is illustrative.
イングレスフィルタリング（正気度チェックの着信先アドレス）と出口フィルタリング（正気度チェックの発信元アドレス）が攻撃を緩和するために、それが容易にパケットの送信元を特定するために作るために行われており、良い習慣であると考えられています。例えば、ネットワーク境界にイングレスフィルタリングは、ネットワークの外部からネットワークに入るために、ネットワークに属する発信元アドレスを持つパケットを許可してはなりません。この機能は、ネットワーク境界で行わ（要件によって、および一般的なケースでは）最も自然です。このネットワーク制御をバイパストンネル化IPトラフィックは、セクション2.1の特定の場合であるが、例示です。
Tunnel servers can apply ingress and egress controls to tunneled IP addresses passing through them to and from tunnel clients.
トンネルサーバーは、トンネルクライアントへとからそれらを通過するトンネル化IPアドレスに入力および出力の制御を適用することができます。
Tunnel clients could make an effort to conduct ingress and egress filtering.
トンネルクライアントは、入力および出力のフィルタリングを行うための努力をすることができます。
Implementations of protocols that embed an IPv4 address in a tunneled IPv6 address directly between peers should perform filtering based on checking the correspondence.
ピア間で直接トンネリングIPv6アドレスにIPv4アドレスを埋め込むプロトコルの実装は、対応するチェックに基づいてフィルタリングを実行すべきです。
Implementations of protocols that accept tunneled packets directly from a server, relay, or protocol peer do filtering the same way as it would be done on a native link with traffic from a router.
リレー、サーバーから直接トンネリングされたパケットを受け入れるプロトコルの実装、またはプロトコルのピアは、ルータからのトラフィックでネイティブリンクで行われるのと同じ方法でフィルタリングします。
Some protocols such as 6to4 [RFC3056], Teredo, and the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] allow both other hosts and a router over a common tunnel. To perform host-based filtering with such protocols, a host would need to know the outer IP address of each router from which it could receive traffic, so that packets from hosts beyond the router will be accepted even though the source address would not embed the router's IP address. Router addresses might be learned via SEcure Neighbor Discovery (SEND) [RFC3971] or some other mechanism (e.g., [RFC5214], Section 8.3.2).
いくつかのこのような6to4の[RFC3056]などのプロトコル、のTeredo、およびサイト内の自動トンネルプロトコル（ISATAP）をアドレッシング[RFC5214]は、他のホストと共通のトンネルを介してルータの両方を可能にします。ルータを越えたホストからのパケットは、送信元アドレスが埋め込まないだろうにもかかわらず、受け入れられるように、このようなプロトコルを持つホストベースのフィルタリングを実行するには、ホストは、それがトラフィックを受信でき、そこから各ルータの外側のIPアドレスを知っている必要がありますルータのIPアドレス。ルータアドレスは、セキュア近隣探索（SEND）[RFC3971]またはいくつかの他の機構（例えば、[RFC5214]、セクション8.3.2）を介して学習されるかもしれません。
If the encapsulated IP packet specifies source routing beyond the recipient tunnel client, the host may forward the IP packet to the specified next hop. This may be unexpected and contrary to administrator wishes and may have bypassed network-based source-routing controls.
カプセル化されたIPパケットは、受信者のトンネルクライアントを越えたソースルーティングを指定した場合、ホストは指定された次のホップにIPパケットを転送することができます。これは予期しないと、管理者希望に反していてもよく、バイパスネットワークベースのソースルーティング制御を有していてもよいです。
A detailed discussion of issues related to source routing can be found in [RFC5095] and [SECA-IP].
ソースルーティングに関連する問題の詳細な議論は[RFC5095]と[SECA-IP]に見出すことができます。
Tunnel clients should by default discard tunneled IP packets that specify additional routing, as recommended in [RFC5095] and [SECA-IP], though they may also allow the user to configure what source-routing types are allowed. All pre-existing source-routing controls should be upgraded to apply these controls to tunneled IP packets as well.
[RFC5095]と[SECA-IP]の推奨トンネルクライアントは、デフォルトでは、彼らはまた、ユーザが許可されているルーティングソース、種類を設定することができかもしれませんが、追加のルーティングを指定したIPパケットをトンネリングさ捨てるべき。すべての既存のソース・ルーティングのコントロールは、同様にトンネル化IPパケットにこれらのコントロールを適用するためにアップグレードする必要があります。
3. Challenges in Inspecting and Filtering Content of Tunneled Data Packets
トンネルデータパケットの点検とフィルタリング、コンテンツ3.課題
3.1. Inefficiency of Selective Network Filtering of All Tunneled Packets
3.1. すべてのトンネルパケットの選択的ネットワークフィルタの非効率性
There is no mechanism that both efficiently and immediately filters all tunneled packets (other than the obviously faulty method of filtering all packets). This limits the ability to prevent tunnel use on a network.
（すべてのパケットをフィルタリングする、明らかに故障した方法以外の）の両方を効率的かつ即時にすべてのトンネリングパケットをフィルタリングするメカニズムはありません。これは、ネットワーク上のトンネルの使用を防止する能力を制限します。
Given concerns about tunnel security or a network's lack of preparedness for tunnels, a network administrator may wish to simply block all use of tunnels that bypass security policies. He or she may wish to do so using network controls; this could be either due to not having the capability to disable tunneling on all hosts attached to the network or due to wanting an extra layer of prevention.
トンネルセキュリティやトンネルのための準備のネットワークの欠如について懸念を考えると、ネットワーク管理者は、単純にセキュリティポリシーをバイパストンネルのすべての使用をブロックすることもできます。彼または彼女は、ネットワークコントロールを使用して、そうすることを望むかもしれません。これは、ネットワークまたは原因予防の余分な層を望むに接続されているすべてのホスト上でトンネリングを無効にする機能を持っていないが原因である可能性があります。
One simple method of doing this easily for many tunnel protocols is to block outbound packets to the UDP or TCP port used (e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for L2TP, etc.). This prevents a tunnel client from establishing a new tunnel. However, existing tunnels will not necessarily be affected if the blocked port is used only for initial setup. In addition, if the blocking is applied on the outside of the client's NAT device, the NAT device will retain the port mapping for the client. In some cases, however, blocking all traffic to a given outbound port (e.g., port 80) may interfere with non-tunneled traffic so this should be used with caution.
多くのトンネルプロトコルの簡単これを行う1つの簡単な方法が使用されるUDPまたはTCPポートへのアウトバウンドパケットをブロックすることである（例えば、宛先UDPポートのTeredo、L2TPのためのUDPポート1701などのために3544です）。これは、新しいトンネルを確立するトンネルクライアントを防ぎます。ブロックされたポートは、初期設定のためにのみ使用されている場合は、既存のトンネルは必ずしも影響を受けません。ブロッキングは、クライアントのNATデバイスの外側に適用された場合また、NATデバイスは、クライアントのためのポートマッピングを保持します。しかし、場合によっては、所与の送信ポート（例えば、ポート80）へのすべてのトラフィックをブロックするので、これは注意して使用する必要があり、非トンネルトラフィックを妨害し得ます。
Another simple alternative, if the tunnel server addresses are well-known, is to filter out all traffic to/from such addresses.
別の簡単な代替、トンネルサーバのアドレスは、よく知られている場合は、そのようなアドレスから/へのすべてのトラフィックをフィルタリングすることです。
The other approach is to find all packets to block in the same way as would be done for inspecting all packets (Section 3.2). However, this presents difficulties in terms of efficiency of filtering, as is discussed in Section 3.2.
他のアプローチは、すべてのパケット（セクション3.2）を検査するために行われるだろうと同じようにブロックするすべてのパケットを見つけることです。 3.2節で議論されているようしかし、これは、フィルタリングの効率の点で困難をもたらします。
Developers of protocols that tunnel over UDP or TCP (including HTTP) to reach the Internet should disable their protocols in networks that wish to enforce security policies on the user traffic. (Windows, for example, disables Teredo by default if it detects that it is within an enterprise network that contains a Windows domain controller.)
トンネル（HTTPを含む）、UDPまたはTCP上でインターネットに到達するためのプロトコルの開発者は、ユーザトラフィックのセキュリティポリシーを適用したいネットワークで自分のプロトコルを無効にする必要があります。 （それがWindowsドメインコントローラが含まれている企業ネットワーク内にあることを検出した場合、Windowsは、例えば、デフォルトでのTeredoを無効にします。）
Administrators of such networks may wish to filter all tunneled traffic at the boundaries of their networks. It is sufficient to filter out the tunneled connection requests (if they can be identified) to stop further tunneled traffic. The easiest mechanism for this would be to filter out outgoing traffic sent to the destination port defined by the tunneling protocol and incoming traffic with that source port. Similarly, in certain cases, it is also possible to use the IP protocol field to identify and filter tunneled packets. For example, 6to4 [RFC3056] is a tunneling mechanism that uses IPv4 packets to carry encapsulated IPv6 packets and can be identified by the IPv4 protocol type 41.
このようなネットワークの管理者は、ネットワークの境界ですべてのトンネルトラフィックをフィルタリングすることもできます。 （彼らが特定できる場合）には、さらに、トンネルトラフィックを停止するようにトンネル接続要求をフィルタリングするのに十分です。このための最も簡単なメカニズムは、ソースポートとトンネリングプロトコルと着信トラフィックによって定義された宛先ポートに送信された発信トラフィックをフィルタリングすることであろう。同様に、特定の場合には、識別しフィルタがパケットをトンネリングするためにIPプロトコルフィールドを使用することも可能です。例えば、6to4の[RFC3056]は、カプセル化IPv6パケットを運ぶためにIPv4パケットを使用し、IPv4プロトコルタイプ41によって同定することができるトンネリングメカニズムです。
There is no efficient mechanism for network-based devices, which are not the tunnel endpoint, to inspect the contents of all tunneled data packets the way they can for native packets. This makes it difficult to apply the same controls as they do to native IP.
それらはネイティブパケットのためすることができる方法を、すべてのトンネルデータパケットの内容を検査するトンネルエンドポイントではないネットワークベースのデバイスのための効率的なメカニズムは、存在しません。これは、彼らがネイティブIPにそうであるように、それは難しいと同じ制御を適用することができます。
Some tunnel protocols are easy to identify, such as if all data packets are encapsulated using a well-known UDP or TCP port that is unique to the protocol.
すべてのデータパケットは、プロトコルに固有の周知のUDPまたはTCPポートを使用してカプセル化されているかのようにいくつかのトンネルプロトコルは、例えば、識別が容易です。
Other protocols, however, either use dynamic ports for data traffic or else share ports with other protocols (e.g., tunnels over HTTP).
しかしながら、他のプロトコル、いずれか他のプロトコル（例えば、HTTP上のトンネル）でデータトラフィックあるいは共有ポートの動的ポートを使用します。
The implication of this is that network-based devices that wish to passively inspect (and perhaps selectively apply policy to) all encapsulated traffic must inspect all TCP or UDP packets (or at least all packets not part of a session that is known not to be a tunnel). This is imperfect since a heuristic must then be applied to determine if a packet is indeed part of a tunnel. This may be too slow to make use of in practice, especially if it means that all TCP or UDP packets must be taken off of the device's "fast path".
これの意味するところは、すべてのカプセル化されたトラフィックがすべてのTCPまたはUDPパケット（あるいは、少なくとも、すべてのパケットではないではないことが知られているセッションの一部を検査しなければならない受動的検査（おそらく選択的にポリシーを適用）するネットワークベースのデバイスということですトンネル）。ヒューリスティックは、パケットが実際にトンネルの一部であるかどうかを決定するために適用されなければならないので、これは不完全です。これは、すべてのTCPまたはUDPパケットは、デバイスの「ファストパス」のオフに取らなければならないことを意味し、特に場合、実際にはを利用するにはあまりにも遅くなることがあります。
One heuristic that can be used on packets to determine if they are tunnel-related or not is as follows. For each known tunnel protocol, attempt parsing the packet as if it were a packet of that protocol destined to the local host (i.e., where the local host has the destination address in the inner IP header, if any). If all syntax checks pass, up to and including the inner IP header (if the tunnel does not use encryption), then treat the packet as if it were a tunneled packet of that protocol.
次のようにそれらがトンネルに関連しているかどうかを決定するために、パケットに使用できる1つのヒューリスティックです。それはローカルホスト宛てそのプロトコルのパケットであるかのように既知の各トンネルプロトコルの場合、パケットを解析しようとする（すなわち、もしあれば、ローカルホストは、内側のIPヘッダ内の宛先アドレスを有する場合）。すべての構文チェックが合格した場合、それは、そのプロトコルのトンネリングされたパケットであるかのように、および内側のIPヘッダ（トンネルが暗号化を使用しない場合）を含むまで、そのパケットを扱います。
It is possible that non-tunneled packets will be treated as if they were tunneled packets using this heuristic, but tunneled packets (of the known types of tunnels) should not escape inspection, absent implementation bugs.
非トンネルパケットを検査、不在の実装のバグを逃れるべきではありません（トンネルの既知のタイプの）パケットを、彼らは、このヒューリスティックを使用してパケットをトンネリングされたかのように扱われますが、トンネル化される可能性があります。
For some protocols, it may be possible to monitor setup exchanges to know to expect that data will be exchanged on certain ports later. (Note that this does not necessarily apply to Teredo, for example, since communicating with another Teredo client behind a cone NAT [RFC5389] device does not require such signaling. In such cases this control will not work. However, deprecation of the cone bit as discussed in [RFC5991] means this technique may indeed work with updated Teredo implementations.)
いくつかのプロトコルでは、データが後で特定のポート上で交換されることを期待するために知ってセットアップ交換を監視することが可能です。 （これは必ずしもそのようなシグナリングを必要としないコーンNAT [RFC5389]デバイスの背後にある別のTeredoクライアントと通信するため、例えば、のTeredoには適用されないことに留意されたい。このような場合には、この制御は機能しないであろう。しかし、円錐ビットの廃止を[RFC5991]で説明したように、この技術が実際に更新されたのTeredo実装で動作できることを意味します。）
As illustrated above, it should be clear that inspecting the contents of tunneled data packets is highly complex and often impractical. For this reason, if a network wishes to monitor IP traffic, tunneling across, as opposed to tunneling to, the security boundary is not recommended. For example, to provide an IPv6 transition solution, the network should provide native IPv6 connectivity or a tunnel solution (e.g., ISATAP or 6over4 [RFC2529]) that encapsulates data packets between hosts and a router within the network.
上に示したように、トンネルデータパケットの内容を検査することは非常に複雑でしばしば非実用的であることは明らかです。ネットワークは、IPトラフィックにトンネリングとは対照的に、全体のトンネルを監視したい場合には、このような理由から、セキュリティ境界はお勧めしません。例えば、IPv6移行ソリューションを提供するために、ネットワークは、ネイティブIPv6接続またはホストとネットワーク内のルータとの間でデータ・パケットをカプセル化するトンネル溶液（例えば、ISATAPまたは6over4は[RFC2529]）を提供すべきです。
If the tunnel allows inbound access from the public Internet, the opening created in a NAT device due to a tunnel client increases its Internet attack surface area. If vulnerabilities are present, this increased exposure can be used by attackers and their programs.
トンネルは公共のインターネットからのインバウンドアクセスを許可する場合は、原因トンネルクライアントにNATデバイスで作成された開口部は、そのインターネット攻撃表面積が増大します。脆弱性が存在している場合は、この増加した暴露は、攻撃者とそのプログラムで使用することができます。
If the tunnel allows inbound access only from a private network (e.g., a remote network to which one has VPNed), the opening created in the NAT device still increases its attack surface area, although not as much as in the public Internet case.
トンネルのみプライベートネットワークからのインバウンドアクセスを許可する場合（例えば、一方はVPNedを有するリモートネットワーク）、開口部は、NATデバイスがまだない限り公共のインターネットと同様にするが、その攻撃の表面積を増大させるに作成します。
When a tunnel is active, a mapped port is maintained on the NAT device through which remote hosts can send packets and perhaps establish connections. The following sequence is intended to sketch out the processing on the tunnel client host that can be reached through this mapped port; the actual processing for a given host may be somewhat different.
トンネルがアクティブである場合、マップされたポートは、リモートホストがパケットを送信し、おそらく接続を確立することができ、それを通してNATデバイス上で維持されます。以下のシーケンスは、このポートを介してマッピングされた到達可能トンネルクライアントホスト上で処理をスケッチすることを意図しています。所与のホストの実際の処理は多少異なっていてもよいです。
The inner firewall (and other security) processing may or may not be present, but if it is, some of the inner IP processing may be filtered. (For example, [RFC4380], Section 7.1 recommends that an IPv6 host firewall be used on all Teredo clients.)
内側ファイアウォール（および他のセキュリティ）処理があってもなくてもよいが、そうである場合、内部IP処理の一部をフィルタリングすることができます。 （例えば、[RFC4380]、セクション7.1は、IPv6ホストは、すべてのTeredoクライアントで使用することがファイアウォールすることをお勧めします。）
(By the virtue of the tunnel being active, we can infer that the inner host firewall is unlikely to do any filtering based on the outer IP.) Any of this processing may expose vulnerabilities an attacker can exploit; similarly, these may expose information to an attacker. Thus, even if firewall filtering is in place (as is prudent) and filters all incoming packets, the exposed area is larger than if a native IP Internet connection were in place, due to the processing that takes place before the inner IP is reached (specifically, the UDP/TCP processing, the tunnel client processing, and additional IP processing, especially if one is IPv4 and the other is IPv6).
この処理のいずれかが、攻撃者が利用することができる脆弱性を公開してもよい（トンネルがアクティブであることのおかげで、我々は、内部ホストファイアウォールは、外側IPに基づく任意のフィルタリングを実行しにくいことを推論することができます）。同様に、これらは、攻撃者に情報を公開してもよいです。したがって、ファイアウォールフィルタリングは（賢明であるように）、すべての着信パケットをフィルタリングし、露出された領域が原因内部IPに到達する前に行われる処理を、ネイティブIPインターネット接続が適所にあった場合よりも大きくなっている場所であっても（具体的には、UDP / TCP処理、トンネルクライアント処理、及び追加のIP処理一つは、IPv4であり、他方がIPv6の場合は特に）。
One possibility is that a layer 3 (L3) targeted worm makes use of a vulnerability in the exposed processing. The main benefit tunneling provides to worms is enabling L3 reachability to the end host. Even a thoroughly firewalled host could be subject to a worm that spreads with a single UDP packet if the right remote code vulnerability is present.
一つの可能性は、レイヤ3（L3）標的ワームが露出処理の脆弱性を利用することです。主な利点トンネリングは、エンドホストにL3の到達可能性を可能にされているワームを提供します。でも徹底的にファイアウォールホストは、右のリモートでコードの脆弱性が存在する場合、単一のUDPパケットで拡散するワームを受ける可能性があります。
This problem seems inherent in tunneling being active on a host, so the solution seems to be to minimize tunneling use.
この問題は、ホスト上でアクティブでトンネリングに固有のようですので、解決策は、トンネルの使用を最小限に抑えることのようです。
For example, tunneling can be active only when it is really needed and only for as long as needed. So, the tunnel interface can be initially not configured and only used when it is entirely the last resort. The interface should then be deactivated (ideally, automatically) again as soon as possible. Note, however, that the hole will remain in the NAT device for some amount of time after this, so some processing of incoming packets is inevitable unless the client's native IP address behind the NAT device is changed.
たとえば、トンネリングは、それが本当に唯一限り、必要に応じてのために必要とされるときにのみアクティブにすることができます。だから、トンネルインターフェイスは、最初に設定されていないと、それは完全に最後の手段である場合にのみ使用することができます。インターフェイスは、その後、できるだけ早く再び（理想的には、自動的に）無効にする必要があります。穴は、この後の時間のいくつかの量のためにNATデバイスのままになりますので、NATデバイスの背後にあるクライアントのネイティブIPアドレスが変更されない限り、着信パケットの一部の処理が避けられないこと、しかし、注意してください。
Attackers are more likely to know about a tunnel client's NAT hole than a typical hole in the NAT device. If they know about the hole, they could try to use it.
攻撃者は、NATデバイスにおける典型的な穴よりトンネルクライアントのNATの穴について知っている可能性が高くなります。彼らは穴を知っている場合、彼らはそれを使用しようとすることができます。
There are at least three reasons why an attacker may be more likely to learn of the tunnel client's exposed port than a typical NAT exposed port:
攻撃者は、一般的なNATさらさポートよりもトンネルクライアントの公開ポートを知る可能性が高いかもしれなぜ、少なくとも3つの理由があります。
1. The NAT mapping for a tunnel is typically held open for a significant period of time and kept stable. This increases the chance of it being discovered.
1.トンネルのNATマッピングは、典型的には、かなりの時間のために開いたままと安定に保たれます。これは、それが発見される可能性が高くなります。
2. In some protocols (e.g., Teredo), the external IP address and port are contained in the client's address that is used end-to-end and possibly even advertised in a name resolution system. While the tunnel protocol itself might only distribute this address in IP headers, peers, routers, and other on-path nodes still see the client's IP address. Although this point does not apply directly to protocols that do not construct the inner IP address based on the outer IP address (e.g., L2TP), the inner IP address is still known to peers, routers, etc., and can still be reached by attackers without their knowing the external IP address or port.
いくつかのプロトコル2.（例えば、Teredoの）、外部IPアドレスおよびポートは、エンドツーエンドに使用され、可能性も名前解決システムで広告されているクライアントのアドレスに含まれています。トンネルプロトコル自体が唯一のIPヘッダ、ピア、ルータ、およびその他のパスのノードにこのアドレスを配布するかもしれませんが、まだ、クライアントのIPアドレスを参照してください。この点は外側のIPアドレス（例えば、L2TP）に基づいた内部IPアドレスを作成していないプロトコルに直接適用されませんが、内部IPアドレスは依然などのピア、ルータに知られており、まだで行くことができます彼らは、外部IPアドレスやポートを知らなくても、攻撃者。
3. Sending packets over a tunnel often results in more message exchanges due to the tunneling protocol, as well as messages being seen by more parties (e.g., due to a longer path length), than sending packets natively, offering more chances for visibility into the port and address in use.
3.トンネルを介してパケットを送信することは、多くの場合に、視認性のためのより多くの機会を提供し、ネイティブパケットを送信するよりも、原因トンネリングプロトコルに複数のメッセージ交換をもたらす、ならびにメッセージが（より長い経路長に起因例えば、）複数の当事者によって見られます使用中のポートとアドレス。
The recommendation from Section 4.1 seems to apply here as well: minimize tunnel use.
トンネルの使用を最小限に抑えます。セクション4.1からの推薦はここにも適用されているようです。
Tunnels that allow inbound connectivity from the Internet (e.g., Teredo, tunnel brokers, etc.) essentially disable the filtering behavior of the NAT for all tunnel client ports. This eliminates NAT devices filtering for such ports and may eliminate the need for an attacker to spoof an address.
インターネットからの着信接続を許可するトンネルは、（例えば、Teredoは、トンネルブローカー等）は、本質的にすべてのトンネルクライアントポートのNATのフィルタリングの動作を無効にします。これは、ポートのNATデバイスのフィルタリングを排除し、アドレスを偽装するために、攻撃者のための必要性を排除することができます。
NATs that implement Address-Dependent or Address and Port-Dependent Filtering [RFC4787] limit the source of incoming packets to just those that are a previous destination. This poses a problem for tunnels that intend to allow inbound connectivity from the Internet.
アドレス依存性またはアドレス及びポート依存フィルタリング[RFC4787]を実装NATは着信パケット以前の宛先であるとちょうどそれらのソースを制限します。これは、インターネットからの着信接続を許可するつもりトンネルの問題を提起します。
Various protocols (e.g., Teredo, Session Traversal Utilities for NAT (STUN) [RFC5389], etc.) provide a facility for peers, upon request, to become a previous destination. This works by sending a "bubble" packet via a server, which is passed to the client and then sent by the client (through the NAT) to the originator.
様々なプロトコル（例えば、Teredoは、等NAT（STUN）[RFC5389]のためのセッショントラバーサルユーティリティ）は、要求に応じて、ピアの機能を提供する前の目的地になること。これは、クライアントに渡された後、元に（NAT経由）クライアントから送信されているサーバーを経由して「バブル」のパケットを送信することで動作します。
This removes any NAT-based barrier to attackers sending packets in through the client's service port. In particular, an attacker would no longer need to either be an actual previous destination or forge its addresses as a previous destination. When forging, the attacker would have had to learn of a previous destination and then would face more challenges in seeing any returned traffic.
これは、クライアントのサービスポート経由でパケットを送信する攻撃者に任意のNATベースの障壁を取り除きます。具体的には、攻撃者は、もはや実際の前の目的地であるか、または以前の宛先としてそのアドレスを偽造するか必要ないだろう。鍛造すると、攻撃者は、前の目的地で学ばなければならなかっただろうし、任意のトラフィックを返さ見て多くの課題に直面するだろう。
If the tunnel can provide connectivity to the Internet, the tunnel client should run a host firewall on the tunnel interface. Also, minimizing public tunnel use (see Section 4.1.3) would lower the attack opportunity related to this exposure.
トンネルは、インターネットへの接続を提供することができた場合は、トンネルクライアントは、トンネルインターフェイス上のホストファイアウォールを実行する必要があります。また、（4.1.3項を参照）、公共トンネルの使用を最小限に抑えることが、このエクスポージャーに関連する攻撃の機会を下げてしまいます。
For some types of tunneling protocols, it may be feasible to guess IP addresses assigned to tunnels, either when looking for a specific client or when looking for an arbitrary client. This is in contrast to native IPv6 addresses in general but is no worse than for native IPv4 addresses today.
トンネリングプロトコルの種類によっては、特定のクライアントを探している場合や、任意のクライアントを探していたときのいずれか、トンネルに割り当てられたIPアドレスを推測することは可能かもしれません。これは、一般的にはネイティブのIPv6アドレスとは対照的であるが、今日に対処ネイティブのIPv4の場合よりも悪くないではありません。
For example, some protocols (e.g., 6to4 and Teredo) use well-defined address ranges. As another example, using well-known public servers for Teredo or tunnel brokers also implies using a well-known address range.
例えば、いくつかのプロトコル（例えば、の6to4とTeredo）は、明確に定義されたアドレス範囲を使用します。別の例として、のTeredoまたはトンネルブローカーのための周知の公開サーバを使用することもよく知られているアドレス範囲を使用して意味しています。
Several tunnel protocols use endpoint addresses that can be algorithmically derived from some known values. These addresses are structured, and the fields contained in them can be fairly predictable. This reduces the search space for an attacker and reduces the resistance of the address to scanning attacks.
いくつかのトンネルプロトコルは、アルゴリズムいくつかの既知の値から導出することができるエンドポイントアドレスを使用します。これらのアドレスは、構造化されており、それらに含まれるフィールドはかなり予測することができます。これは、攻撃者のための探索空間を低減し、スキャン攻撃へのアドレスの抵抗を低減します。
It is recommended that tunnel protocol developers use tunnel endpoint addresses that are not easily guessable. When the tunnel endpoint addresses are structured and fairly guessable, it is recommended that the implementation use any unused fields in the address to provide additional entropy to the address in order to reduce the address-scanning risks. For example, this could be done by setting these unused fields to some random values.
トンネルプロトコルの開発者が容易に推測されないトンネルエンドポイントのアドレスを使用することをお勧めします。トンネルエンドポイントアドレスは、構造とかなり推測可能である場合には、実装は、アドレス走査リスクを低減するために、アドレスに追加のエントロピーを提供するために、アドレス中の任意の未使用のフィールドを使用することをお勧めします。たとえば、これはいくつかのランダムな値にこれらの未使用のフィールドを設定することによって行うことができます。
An attacker encountering an address associated with a particular tunneling protocol or well-known tunnel server has the opportunity to infer certain relevant pieces of information that can be used to profile the host before sending any packets. This can reduce the attacker's footprint and increase the attacker's efficiency.
特定のトンネリングプロトコルまたは周知のトンネルサーバーに関連するアドレスに遭遇攻撃者が任意のパケットを送信する前にホストをプロファイルするために使用することができる情報の特定の関連部分を推測する機会を有します。これは、攻撃者のフットプリントを削減し、攻撃者の効率を向上させることができます。
The tunnel address reveals some information about the nature of the client:
トンネルアドレスは、クライアントの性質についていくつかの情報を明らかに：
o That a host has a tunnel address associated with a given protocol means that the client is running on some platform for which there exists a tunnel client implementation of that protocol. In addition, if some platforms have that protocol installed by default and if the host's default rules for using it make it susceptible to being in use, then the protocol is more likely to be running on such a platform than on one where it is not used by default. For example, as of this writing, seeing a Teredo address suggests that the host it is on is probably running Windows.
ホストが特定のプロトコルに関連付けられたトンネルアドレスを持っていることoをクライアントがそのプロトコルのトンネルクライアントの実装が存在するため、いくつかのプラットフォーム上で実行されていることを意味します。それを使用するためのホストのデフォルトルールが使用中であることにそれが受けやすくなる場合、一部のプラットフォームでは、デフォルトではインストールされているプロトコルを持っているとあればまた、その後、プロトコルは、それが使用されていない1に比べて、このようなプラットフォーム上で実行されている可能性が高いですデフォルトでは。たとえば、これを書いている時点では、Teredoアドレスを見ることは、それが上にあるホストは、おそらくWindowsを実行していることを示唆しています。
o Similarly, the use of an address associated with a particular tunnel server also suggests some information. Tunnel client software is often deployed, installed, and/or configured using some degree of automation. It seems likely that the majority of the time, the tunnel server that results from the initial configuration will go unchanged from the initial setting. Moreover, the server that is configured for use may be associated with a particular means of installation, which often suggests the platform. For example, if the server field in a Teredo address is one of the IPv4 addresses to which teredo.ipv6.microsoft.com resolves, the host is likely running Windows.
O同様に、特定のトンネルサーバーに関連するアドレスの使用はまた、いくつかの情報を示唆しています。トンネルクライアントソフトウェアは、多くの場合、配備インストール、および/または自動化をある程度使用して構成されています。それは時間の大半は、初期設定から得られるトンネルサーバが初期設定から変更しない行く可能性が高いようです。また、使用するように構成されているサーバは、多くの場合、プラットフォームを示唆している、インストールの特定の手段に関連付けられてもよいです。たとえば、TeredoアドレスでサーバーフィールドがIPv4のいずれかである場合teredo.ipv6.microsoft.comが解決され、ホストがそうでWindowsを実行しているために対処しています。
o The external IPv4 address of a NAT device can, of course, be readily associated with a particular organization or at least an ISP; hence, putting this address in an IPv6 address reveals this information. However, this is no different than using a native IP address and is therefore not new with tunneling.
NATデバイスの外部IPv4アドレスO、当然のことながら、容易に特定の組織又は少なくともISPに関連付けることができます。したがって、IPv6アドレスで、このアドレスを置くことは、この情報を明らかにします。しかし、これはネイティブのIPアドレスを使用するよりも違いはありませんので、トンネリングと新しいものではありません。
o It is also possible that external client port numbers may be more often associated with particular client software or the platform on which it is running. The usefulness of this for platform determination is, however, reduced by the different NAT port number assignment behaviors. In addition, the same observations would apply to use of UDP or TCP over native IP as well; hence, this is not new with tunneling.
O外部クライアントのポート番号は、より多くの場合、特定のクライアントソフトウェアまたはそれが実行されているプラットフォームと関連し得ることも可能です。プラットフォーム決意用この有用性は、しかし、異なるNATのポート番号の割り当ての動作によって低減されます。また、同じ観察は、同様のネイティブIP上のUDPまたはTCPの使用に適用されます。したがって、これはトンネリングと新しいものではありません。
The platform, tunnel client software, or organization information can be used by an attacker to target attacks more carefully. For example, an attacker may decide to attack an address only if it is likely to be associated with a particular platform or tunnel client software with a known vulnerability. (This is similar to the ability to guess some platforms based on the Organizationally Unique Identifier (OUI) in the Extended Unique Identifier (EUI)-64 portion of an IPv6 address generated from a Media Access Control (MAC) address, since some platforms are commonly used with interface cards from particular vendors.)
プラットフォーム、トンネルクライアントソフトウェア、または組織情報は、より慎重な攻撃を対象とする攻撃者によって使用することができます。例えば、攻撃者は、既知の脆弱性を持つ特定のプラットフォームまたはトンネルクライアントソフトウェアに関連している可能性が高い場合にのみ、アドレスを攻撃することを決定することができます。いくつかのプラットフォームであるため（これは、メディアアクセス制御（MAC）アドレスから生成されたIPv6アドレスの拡張固有識別子（EUI）-64部分に）組織固有識別子（OUIに基づいて、いくつかのプラットフォームを推測する能力に類似しています一般的に、特定のベンダーからのインターフェイスカードで使用されます。）
If installation programs randomize the server setting, they would reduce the extent to which they can be profiled. Similarly, administrators can choose to change the default setting to reduce the degree to which they can be profiled ahead of time.
インストールプログラムは、サーバーの設定をランダム化した場合、彼らはプロファイリングできる程度を減少させるであろう。同様に、管理者は、事前にプロファイリングすることができますどの程度を削減するために、デフォルトの設定を変更することを選択できます。
Randomizing the tunnel client port in use would mitigate any profiling that can be done based on the external port, especially if multiple tunnel clients did this. Further discussion on randomizing ports can be found at [RFC6056].
使用中のトンネルクライアントポートをランダム化すると、複数のトンネルクライアントはこれをした場合は特に、外部ポートに基づいて行うことができます任意のプロファイリングを軽減するでしょう。ランダムポートのさらなる議論は[RFC6056]で見ることができます。
It is recommended that tunnel protocols minimize the propagation of knowledge about whether the NAT is a cone NAT.
トンネルプロトコルは、NATがコーンNATであるか否かについての知識の伝播を最小限に抑えることが推奨されます。
If an attacker could change either a tunnel client's server setting or the IP addresses to which a configured host name resolves (e.g., by intercepting DNS queries) AND if the tunnel is not authenticated, the attacker would become a man in the middle. This would allow them to at least monitor peer communication and at worst to impersonate the remote peer.
攻撃者は、（例えば、DNSクエリを傍受することによって）ANDトンネルが認証されていない場合は設定されたホスト名が解決さは、攻撃者が途中で男になるためにどのトンネルクライアントのサーバー設定またはIPアドレスを変更することができれば。これは、少なくともモニタピア通信にそれらを可能にし、最悪のリモートピアを偽装します。
A client's server has good visibility into the client's communication with IP peers. If the server were switched to one that records this information and makes it available to third parties (e.g., advertisers, competitors, spouses, etc.), then sensitive information would be disclosed, especially if the client's host prefers the tunnel over native IP. Assuming the server provides good service, the user would not have reason to suspect the change.
クライアントのサーバーは、IPピアとクライアントの通信に良好な視認性を持っています。サーバはこの情報を記録し、第三者（例えば、広告主、競合他社、配偶者など）にそれを利用できるように一つに切り替えた場合には、機密情報がクライアントのホストは、ネイティブIP経由のトンネルを好む場合は特に、開示されることになります。サーバーと仮定すると良いサービスを提供し、ユーザーが変更を疑う理由を持っていません。
Full interception of IP traffic could also be arranged (including pharming), which would allow any number of deception or monitoring attacks, including phishing. We illustrate this with an example phishing attack scenario.
IPトラフィックの完全な傍受はまた、詐欺やフィッシングなどの監視攻撃、任意の数のを許すことになる、（ファーミングを含む）に配置することができます。私たちは、攻撃シナリオをフィッシングの例でこれを説明します。
It is often assumed that the tunnel server is a trusted entity. It may be possible for malware or a malicious user to quietly change the client's tunnel server setting and have the user be unaware that their trust has been misplaced for an indefinite period of time. However, malware or a malicious user can do much worse than this, so this is not a significant concern. Hence, it is only important that an attacker on the network cannot change the client's server setting.
多くの場合、トンネルサーバは、信頼できるエンティティであることが想定されます。マルウェアや悪意のあるユーザーが、静かに、クライアントのトンネルサーバーの設定を変更し、ユーザーが自分の信頼関係が無期限に置き忘れてきたことに気づかないこと有することが可能です。しかし、マルウェアや悪意のあるユーザーがこれよりもはるかに悪化を行うことができますので、これは大きな問題ではありません。したがって、ネットワーク上の攻撃者がクライアントのサーバーの設定を変更することはできませんということだけが重要です。
1. A phisher sets up a malicious tunnel server (or tampers with a legitimate one). This server, for the most part, provides correct service.
1.フィッシャー悪意のあるトンネルサーバを設定（または正当なものと改ざん）。このサーバは、ほとんどの部分は、正確なサービスを提供しています。
2. An attacker, by some means, switches the host's tunnel server setting or spoofs a DNS reply to point to the above server. If neither DNS nor the tunnel setup is secured (i.e., if the client does not authenticate the information), then the attacker's tunnel server is seen as legitimate.
2.攻撃者は、いくつかの手段によって、ホストのトンネルサーバの設定を切り替える以上のサーバを指すようにDNS応答を偽装します。どちらのDNSもトンネルセットアップが（つまり、クライアントが情報を認証しない場合）が確保されている場合、攻撃者のトンネルサーバーは正当と見られています。
3. A user on the victim host types their bank's URL into his/her browser.
3.彼/彼女のブラウザに被害者のホストタイプ銀行のURLにユーザー。
4. The bank's hostname resolves to one or more IP addresses, and the tunnel is selected for socket connection for whatever reason (e.g., the tunnel provides IPv6 connectivity, and the bank has an IPv6 address).
4.銀行のホスト名は、1つまたは複数のIPアドレスに解決し、トンネル（例えば、トンネルは、IPv6接続性を提供し、銀行は、IPv6アドレスを持つ）何らかの理由でソケット接続のために選択されます。
5. The tunnel client uses the server for help in connecting to the bank's IP address. Some tunneling protocols use a separate channel for signaling versus data, but this still allows the server to place itself in the data path by an appropriate signal to the client. For example, in Teredo, the client sends a ping request through a server, which is expected to come back through a data relay, and a malicious server can simply send it back itself to indicate that is a data relay for the communication.
5.トンネルクライアントは、銀行のIPアドレスに接続するのに助けのためのサーバーを使用しています。いくつかのトンネリングプロトコルは、データ対シグナリング用に別々のチャンネルを使用していますが、これはまだ、サーバーがクライアントに適切な信号によってデータパスに自分自身を配置することができます。たとえば、Teredoの中で、クライアントは、データ中継を通じて戻ってくることが予想されているサーバを介して、ping要求を送信し、悪意のあるサーバは、単にそれが通信のためのデータ中継であることを示すために自分自身をそれを送り返すことができます。
6. The rest works pretty much like any normal phishing transaction, except that the attacker acts as a tunnel server (or data relay, for protocols such as Teredo) and a host with the bank's IP address.
6.残りの部分は、攻撃者がトンネルサーバ（またはデータ中継などのTeredoなどのプロトコル用）および銀行のIPアドレスを持つホストとして動作することを除いて、ほとんどすべての通常のフィッシング詐欺の取引のように動作します。
This pharming-type attack is not unique to tunneling. Switching DNS server settings to a malicious DNS server or DNS cache poisoning in a recursive DNS resolver could have a similar effect.
このファーミング型攻撃は、トンネリングに固有のものではありません。再帰的なDNSリゾルバで悪質なDNSサーバやDNSキャッシュポイズニングにDNSサーバーの設定を切り替えると、同様の効果を持つことができます。
In general, anti-phishing and anti-fraud provisions should help with aspects of this, as well as software that specifically monitors for tunnel server changes.
一般に、アンチフィッシングや不正防止条項は、特にトンネルサーバの変更を監視し、このの側面だけでなく、ソフトウェアを支援すべきです。
Perhaps the best way to mitigate tunnel-specific attacks is to have the client authenticate either the tunnel server or at least the means by which the tunnel server's IP address is determined. For example, SSL VPNs use https URLs and hence authenticate the server as being the expected one. When IPv6 Router Advertisements are sent over the tunnel, another mechanism is to use SEcure Neighbor Discovery (SEND) [RFC3971] to verify that the client trusts the server.
おそらく、トンネル特有の攻撃を軽減するための最良の方法は、クライアントがトンネルサーバまたはトンネルサーバーのIPアドレスが決定されることによって、少なくとも手段のいずれかを認証することです。例えば、SSL VPNは、HTTPS URLを使用し、したがって期待一つであるとしてサーバを認証します。 IPv6ルーター広告がトンネルを介して送信される場合、別の機構は、クライアントがサーバを信頼していることを確認するために、セキュア近隣探索（SEND）[RFC3971]を使用することです。
On the host, it should require an appropriate level of privilege in order to change the tunnel server setting (as well as other non-tunnel-specific settings such as the DNS server setting, etc.). Making it easy to see the current tunnel server setting (e.g., not requiring privilege for this) should help detection of changes.
ホスト上で、それが（例えば、DNSサーバ設定、等として並びに他の非トンネル固有の設定）トンネルサーバの設定を変更するために特権の適切なレベルを必要とするべきです。それは簡単に現在のトンネルサーバの設定を確認すること（例えば、このための権限を必要としないこと）変化の検出を助けるべきです。
The scope of the attack can also be reduced by limiting tunneling use in general but especially in preferring native IPv4 to tunneled IPv6 when connecting to peers who are accessible over IPv4, as doing so helps mitigate attacks that are facilitated by changing the tunnel server setting. Please refer to Section 3 of [TUNNEL-LOOPS] for a detailed description and mitigation measures for a class of attacks based on IPv6 automatic tunnels.
攻撃の範囲は、一般的には、トンネルの使用を制限することではなく、特にそうするトンネルサーバの設定を変更することによって促進される攻撃の緩和に役立ちますように、IPv4の上でアクセスされているピアへの接続時にIPv6をトンネル化するためにネイティブのIPv4を好んで減少させることができます。 IPv6の自動トンネルに基づいた攻撃のクラスについての詳細な説明と緩和策のために[トンネルLOOPS]のセクション3を参照してください。
This document described several security issues with tunnels. This does not mean that tunnels need to be avoided at any cost. On the contrary, tunnels can be very useful if deployed, operated, and used properly. The threats against IP tunnels are documented here. If the threats can be mitigated, network administrators can efficiently and securely use tunnels in their network. Several measures can be taken in order to secure the operation of IPv6 tunnels: o Operating on-premise tunnel servers/relays so that the tunneled traffic does not cross border routers.
この文書では、トンネルで複数のセキュリティ問題を説明しました。これはトンネルが任意のコストで回避する必要があることを意味するものではありません。逆に、トンネルが展開されている場合、非常に便利に操作し、適切に使用することができます。 IPトンネルに対する脅威がここに記載されています。脅威を緩和することができる場合は、ネットワーク管理者は、効率的かつ安全にネットワークにトンネルを使用することができます。営業オンプレミストンネルサーバ/リレートンネルトラフィックがないように、クロスボーダールータ○：いくつかの対策がIPv6トンネルの動作を確保するために撮影することができます。
o Setting up internal routing to steer traffic to these servers/ relays
これらのサーバ/リレーにトラフィックを導くために内部ルーティングを設定するO
o Setting up of firewalls [RFC2979] to allow known and controllable tunneling mechanisms and disallow unknown tunnels.
既知の制御トンネリングメカニズムを可能にし、未知のトンネルを許可しないファイアウォール[RFC2979]の設定O。
The authors would like to thank Remi Denis-Courmont, Fred Templin, Jordi Palet Martinez, James Woodyatt, Christian Huitema, Brian Carpenter, Nathan Ward, Kurt Zeilenga, Joel Halpern, Erik Kline, Alfred Hoenes, and Fernando Gont for reviewing earlier versions of the document and providing comments to make this document better.
著者は、以前のバージョンを見直すためレミデニス・Courmont、フレッド・テンプリン、ジョルディPaletマルティネス、ジェームズWoodyatt、クリスチャンのHuitema、ブライアン・カーペンター、ネイサンウォード、クルトZeilenga、ジョエル・ハルパーン、エリック・クライン、アルフレッドHoenes、そしてフェルナンドGontに感謝したいと思います文書とよりよいこの文書を作るために、コメントを提供します。
This entire document discusses security concerns with tunnels.
この文書全体ではトンネルでセキュリティ上の問題について説明します。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529]カーペンター、B.及びC.チョン、 "明示的なトンネルなしでのIPv4ドメイン上のIPv6の送信"、RFC 2529、1999年3月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979]フリード、N.、 "の行動とインターネットファイアウォールの要件"、RFC 2979、2000年10月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]ラウ、J.、エド、Townsley、M.、エド、およびI. Goyret、エド、 "レイヤ2トンネリングプロトコル - バージョン3（L2TPv3の）"。。。、RFC 3931、2005年3月。
[RFC3971] Arkko, J., Ed., 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月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]のHuitema、C.、 "のTeredo：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、RFC 4380、2006年2月。
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.、エド。、およびC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
[RFC5095] Abley、J.、Savola、P.、およびG.ネビル・ニール、 "ルーティングヘッダIPv6におけるタイプ0の廃止"、RFC 5095、2007年12月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]テンプリン、F.、グリーソン、T.、およびD.ターラーは、 "イントラサイト自動トンネルは、プロトコル（ISATAP）をアドレス指定"、RFC 5214、2008年3月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
[RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo Security Updates", RFC 5991, September 2010.
[RFC5991]ターラー、D.、クリシュナン、S.、およびJ.ホーグランド、 "Teredoのセキュリティアップデート"、RFC 5991、2010年9月。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056]ラーセン、M.とF. Gont、BCP 156、RFC 6056、2011年1月 "トランスポート・プロトコルポートランダム化のための提言"。
[SECA-IP] Gont, F., "Security Assessment of the Internet Protocol version 4", Work in Progress, April 2011.
[SECA-IP] Gont、F.、 "インターネットプロトコルバージョン4のセキュリティ評価"、進歩、2011年4月の作業。
[TUNNEL-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", Work in Progress, March 2011.
[トンネルLOOPS] Nakibly、G.およびF.テンプリン、「IPv6の自動トンネルを使用してルーティングループ攻撃：問題文と提案た軽減」、進歩、2011年3月に作業。
Authors' Addresses
著者のアドレス
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
スレシュクリシュナンエリクソン8400 Decarie大通りマウントロイヤル、QCカナダの町
Phone: +1 514 345 7900 x42871 EMail: suresh.krishnan@ericsson.com
電話：+1 514 345 7900 x42871メール：suresh.krishnan@ericsson.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
デーブターラーマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
電話：+1 425 703 8835 Eメール：dthaler@microsoft.com
James Hoagland Symantec Corporation 350 Ellis St. Mountain View, CA 94043 USA
ジェームズ・ホーグランドSymantec Corporationの350エリス聖マウンテンビュー、CA 94043 USA
EMail: Jim_Hoagland@symantec.com URI: http://symantec.com/
電子メール：Jim_Hoagland@symantec.com URI：http://symantec.com/