[要約] 要約：RFC 6169は、IPトンネリングに関連するセキュリティ上の懸念点を議論しています。 目的：このRFCの目的は、IPトンネリングのセキュリティリスクを理解し、適切な対策を講じるためのガイダンスを提供することです。
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
IPトンネリングに関するセキュリティの懸念
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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. 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]すべてのトンネルIPパケットを層レイヤーします。同様に、HTTP（したがってTCPを介して）上にIPパケットをトンネルする多くのセキュアソケットレイヤー（SSL）VPNソリューションが現在展開されています。
This document discusses security concerns with tunneling IP packets and includes recommendations where relevant.
このドキュメントでは、Tunneling 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トラフィックは、そのようなデバイスが特にトンネルを認識していない限り、ネットワークベースのセキュリティデバイスによる意図したレベルの検査またはポリシーアプリケーションを受け取っていない場合があります。これにより、防御が詳細に削減され、セキュリティギャップが発生する可能性があります。これは、すべてのネットワークに位置するデバイスと、既存のフックメカニズムがトンネルクライアントが脱カプセル化を行った後、またはカプセル化を行う前に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.
この遅延を削減する1つの方法は、セキュリティ開発者が新しい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レイヤーが含まれていることを認識しません。ネイティブパケットに同じコントロールを適用する必要があります。（もちろん、不明なプロトコルを参照するなど、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.
セキュリティ制御バイパスの意味の1つは、[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.
トンネルを受け入れられるリスクのトンネルを検討していないセキュリティ管理者は、エンドノード（ホスト）またはネットワークの周囲のネットワークノードのいずれかでトンネル機能を無効にする必要があります。ただし、認識のギャップがあるかもしれません。したがって、負のセキュリティ結果の可能性があるため、トンネリング機能は、ホストで、および提供されている場合は中央管理施設を介して簡単に無効にする必要があります。
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が5の優先順位を持ち、TeredoよりもネイティブIPv4が優先される可能性があります。
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.
攻撃を軽減し、パケットのソースを識別しやすくし、良い習慣と見なされるために、イングレスフィルタリング（正気回復先アドレス）と出力フィルタリング（Sanity-Checking Outing sourceアドレス）が行われます。たとえば、ネットワークの境界線でのイングレスフィルタリングは、ネットワークに属するソースアドレスを備えたパケットを許可しないようにして、ネットワークの外部からネットワークに入ります。この関数は、ネットワーク境界で行われる最も自然に（および一般的な場合、要件によって）。このネットワークコントロールをバイパスするトンネル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アドレス。ルーターアドレスは、安全な近隣発見（送信）[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パケットにも適用する必要があります。
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の場合は3544、L2TPの場合はUDPポート1701など）。これにより、トンネルクライアントが新しいトンネルを確立することを防ぎます。ただし、ブロックされたポートが初期セットアップにのみ使用される場合、既存のトンネルが必ずしも影響を受けるとは限りません。さらに、ブロッキングがクライアントの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.)
UDPまたはTCP（HTTPを含む）を介してインターネットに到達するプロトコルの開発者は、ユーザートラフィックのセキュリティポリシーを実施したいネットワークでプロトコルを無効にするはずです。（たとえば、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]は、IPv4パケットを使用してカプセル化されたIPv6パケットを運ぶトンネルメカニズムであり、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.)
一部のプロトコルでは、セットアップ交換を監視して、特定のポートでデータが交換されることを期待するために知ることができる場合があります。（たとえば、これは必ずしもTeredoに適用されないことに注意してください。たとえば、Cone Nat [RFC5389]デバイスの背後にある別の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または6OVOR4 [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.
トンネルがプライベートネットワークからのみインバウンドアクセスを許可している場合（たとえば、VPがあるリモートネットワークなど）、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デバイスにマッピングされたポートが維持されます。次のシーケンスは、このマッピングされたポートを介して到達できるトンネルクライアントホストの処理をスケッチすることを目的としています。特定のホストの実際の処理は多少異なる場合があります。
1. Link-layer protocol processing
1. リンク層プロトコル処理
2. (Outer) IP host firewall processing
2. （外側）IPホストファイアウォール処理
3. (Outer) IP processing by stack
3. （外側）スタックによるIP処理
4. UDP/TCP processing by stack
4. STACKによるUDP/TCP処理
5. Tunnel client processing
5. トンネルクライアント処理
6. (Inner) IP host firewall processing
6. （内側）IPホストファイアウォール処理
7. (Inner) IP processing by stack
7. （内側）スタックによるIP処理
8. Various upper layer processing may follow
8. さまざまな上層処理が続く場合があります
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では、すべてのTeredoクライアントにIPv6ホストファイアウォールを使用することを推奨しています。）
(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インターネット接続が整っている場合よりも露出領域が大きくなります（具体的には、特に1つがIPv4であり、もう1つがIPv6である場合、UDP/TCP処理、トンネルクライアント処理、および追加のIP処理。
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.
1つの可能性は、レイヤー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. 一部のプロトコル（テレドなど）では、外部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.
インターネットからのインバウンド接続を可能にするトンネル（テレド、トンネルブローカーなど）は、すべてのトンネルクライアントポートの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など）は、明確に定義されたアドレス範囲を使用しています。別の例として、テレドまたはトンネルブローカーによく知られているパブリックサーバーを使用することは、よく知られているアドレス範囲を使用することも意味します。
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 ホストが特定のプロトコルに関連付けられたトンネルアドレスを持っていることは、クライアントがそのプロトコルのトンネルクライアントの実装が存在するプラットフォームで実行していることを意味します。さらに、一部のプラットフォームにそのプロトコルがデフォルトでインストールされており、ホストの使用のデフォルトルールが使用されている場合、プロトコルは使用されていない場合よりもそのようなプラットフォームで実行されている可能性が高くなります。デフォルトで。たとえば、この執筆時点では、テレドの住所を見ると、ホストがおそらく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アドレスのサーバーフィールドが、teredo.ipv6.microsoft.comが解決するIPv4アドレスの1つである場合、ホストがウィンドウを実行している可能性があります。
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.
o もちろん、NATデバイスの外部IPv4アドレスは、特定の組織または少なくとも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.
攻撃者がトンネルクライアントのサーバー設定または構成されたホスト名が解決するIPアドレス（例：DNSクエリを傍受することにより）を変更し、トンネルが認証されていない場合、攻撃者は中央の男になります。これにより、少なくともピアコミュニケーションを監視し、最悪の場合はリモートピアになりすまします。
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. Phisherは、悪意のあるトンネルサーバー（または正当なものを備えたタンパー）を設定します。このサーバーは、ほとんどの場合、正しいサービスを提供します。
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 VPNSはHTTPS URLを使用するため、サーバーを予想されるものとして認証します。IPv6ルーター広告がトンネル上に送信されると、別のメカニズムは、セキュアネイバーディスカバリー（送信）[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を介してアクセス可能なピアに接続するときにネイティブIPv4よりもトンネルIPv6を好むことで削減することもできます。IPv6自動トンネルに基づく攻撃のクラスの詳細な説明と緩和策については、[トンネルループ]のセクション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オンプレミストンネルサーバー/リレーの動作により、トンネルトラフィックがボーダールーターを通過しないようにします。
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.
o ファイアウォール[RFC2979]のセットアップは、既知の制御可能なトンネルメカニズムを可能にし、未知のトンネルを許可します。
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.
著者は、レミ・デニス・コールモント、フレッド・テンプリン、ジョルディ・パレット・マルティネス、ジェームズ・ウッディヤット、クリスチャン・フイテマ、ブライアン・カーペンター、ネイサン・ウォード、カート・ゼイレンガ、ジョエル・ハルパーン、エリック・クライン、アルフレッド・ホエンズ、フェルナンド・ゴントの初期のレビューのためのフェルナンド・ゴントに感謝したいと思います。このドキュメントをより良くするためのコメントを提供します。
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] Carpenter、B。およびC. Jung、「明示的なトンネルなしの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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、 "層2トンネリングプロトコル" L2TP ""、RFC 2661、1999年8月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979] Freed、N。、「インターネットファイアウォールの行動と要件」、RFC 2979、2000年10月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、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] Lau、J.、ed。、Ed。、Townsley、M.、ed。、およびI. Goyret、ed。、「レイヤー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.、Ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（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：ネットワークアドレス翻訳（NAT）を介してUDPを介したIPv6のトンネル」、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.、ed。、およびC. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、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] Eabley、J.、Savola、P。、およびG. Neville-Neil、「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] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（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] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NATのセッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo Security Updates", RFC 5991, September 2010.
[RFC5991] Thaler、D.、Krishnan、S。、およびJ. Hoagland、「Teredo Security Updates」、RFC 5991、2010年9月。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056] Larsen、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.
[Tunnel-Loops] Nakibly、G。およびF. Templin、「IPv6自動トンネルを使用したルーティングループ攻撃：問題声明と提案された緩和」、2011年3月、進行中の作業。
Authors' Addresses
著者のアドレス
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
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
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/