RFC 7359 - Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7359
タイトル : RFC 7359 - デュアルスタックホスト/ネットワークでのレイヤー3仮想プライベートネットワーク（VPN）トンネルトラフィックリーケージ
翻訳編集 : 自動生成

[要約] 要約： RFC 7359は、デュアルスタックホスト/ネットワークにおけるレイヤー3仮想プライベートネットワーク（VPN）トンネルトラフィックの漏洩に関する情報を提供しています。目的：このRFCの目的は、デュアルスタック環境でのVPNトンネルトラフィックの漏洩に関する問題を特定し、解決策を提案することです。

Internet Engineering Task Force (IETF)                           F. Gont
Request for Comments: 7359                           Huawei Technologies
Category: Informational                                      August 2014
ISSN: 2070-1721

Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks

デュアルスタックホスト/ネットワークでのレイヤー3仮想プライベートネットワーク（VPN）トンネルトラフィックリーケージ

Abstract

概要

The subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages. That is, traffic meant to be transferred over an encrypted and integrity-protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue.

一般的な仮想プライベートネットワーク（VPN）トンネル製品ではIPv6が適切にサポートされていないため、一般的なネットワークでIPv6およびIPv4プロトコルが共存する巧妙な方法により、VPNトンネルトラフィックリークが発生する可能性があります。つまり、暗号化され整合性が保護されたVPNトンネルを介して転送されるトラフィックは、そのようなトンネルから漏洩し、ローカルネットワーク上で平文で最終的な宛先に送信される可能性があります。このドキュメントでは、IPv6非対応のVPNソフトウェアを使用した結果として、このようなVPNトンネルトラフィックリークが発生する可能性があるいくつかのシナリオについて説明します。さらに、このドキュメントでは、この問題の可能な緩和策を提供します。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

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（Internet Engineering Task Force）の製品です。これは、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/rfc7359.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7359で入手できます。

IESG Note

This document describes a problem of information leakage in VPN software and attributes that problem to the software's inability to deal with IPv6. We do not think this is an appropriate characterization of the problem. It is true that when a device supports more than one address family, the inability to apply policy to more than one address family on that device is a defect. Despite that, inadvertent or maliciously induced information leakage may also occur due to the existence of any unencrypted interface allowed on the system, including the configuration of split tunnels in the VPN software itself. While there are some attacks that are unique to an IPv6 interface, the sort of information leakage described by this document is a general problem that is not unique to the situation of IPv6-unaware VPN software. We do not think this document sufficiently describes the general issue.

このドキュメントでは、VPNソフトウェアでの情報漏えいの問題と、その問題がソフトウェアのIPv6を処理できないことに起因するものについて説明します。これは問題の適切な特徴付けとは考えていません。デバイスが複数のアドレスファミリをサポートしている場合、そのデバイスの複数のアドレスファミリにポリシーを適用できないことは欠陥です。それにもかかわらず、VPNソフトウェア自体のスプリットトンネルの構成など、システムで許可されている暗号化されていないインターフェイスが存在するために、不注意または悪意により引き起こされた情報漏洩が発生する可能性があります。 IPv6インターフェースに特有の攻撃がいくつかありますが、このドキュメントで説明されているような情報漏えいは、IPv6非対応VPNソフトウェアの状況に特有の一般的な問題です。このドキュメントは一般的な問題を十分に説明しているとは考えていません。

著作権表示

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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  IPv4 and IPv6 Coexistence . . . . . . . . . . . . . . . . . .   5
   4.  Virtual Private Networks in IPv4/IPv6 Dual-Stack
       Hosts/Networks  . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Inadvertent VPN Tunnel Traffic Leakages in Legitimate
       Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  VPN Tunnel Traffic Leakage Attacks  . . . . . . . . . . . . .   7
   7.  Mitigations to VPN Tunnel Traffic Leakage Vulnerabilities . .   8
     7.1.  Fixing VPN Client Software  . . . . . . . . . . . . . . .   8
     7.2.  Operational Mitigations . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11

1. Introduction

1. はじめに

It is a very common practice for users to employ VPN software when employing a public (and possibly rogue) local network. This is typically done not only to gain access to remote resources that may not otherwise be accessible from the public Internet, but also to secure the host's traffic against attackers that might be connected to the same local network as the victim host. The latter case constitutes the problem space of this document. Indeed, it is sometimes assumed that employing a VPN tunnel makes the use of insecure protocols (e.g., that transfer sensitive information in the clear) acceptable, as a VPN tunnel provides security services (such as data integrity and/or confidentiality) for all communications made over it. However, this document illustrates that under certain circumstances, some traffic might not be mapped onto the VPN tunnel and thus might be sent in the clear on the local network.

ユーザーがパブリック（および場合によっては不正）ローカルネットワークを使用する場合、VPNソフトウェアを使用することは非常に一般的な方法です。これは通常、他の方法ではパブリックインターネットからアクセスできないリモートリソースにアクセスするためだけでなく、被害者のホストと同じローカルネットワークに接続されている可能性のある攻撃者からホストのトラフィックを保護するためにも行われます。後者のケースは、このドキュメントの問題空間を構成します。実際、VPNトンネルはすべての通信にセキュリティサービス（データの整合性や機密性など）を提供するため、VPNトンネルを使用すると、安全でないプロトコル（機密情報を平文で転送するなど）の使用が受け入れられると想定される場合があります。それを覆った。ただし、このドキュメントは、特定の状況下では、一部のトラフィックがVPNトンネルにマッピングされず、ローカルネットワーク上にそのまま送信される可能性があることを示しています。

Many VPN products that are typically employed for the aforementioned VPN tunnels only support the IPv4 protocol: that is, they perform the necessary actions such that IPv4 traffic is sent over the VPN tunnel, but they do nothing to secure IPv6 traffic originated from (or being received at) the host employing the VPN client. However, the hosts themselves are typically dual-stacked: they support (and enable by default) both IPv4 and IPv6 (even if such IPv6 connectivity is simply "dormant" when they connect to IPv4-only networks). When the IPv6 connectivity of such hosts is enabled, they may end up employing an IPv6-unaware VPN client in a dual-stack network. This may have "unexpected" consequences, as explained below.

前述のVPNトンネルで一般的に採用されている多くのVPN製品は、IPv4プロトコルのみをサポートしています。つまり、IPv4トラフィックがVPNトンネルを介して送信されるように必要なアクションを実行しますが、発信元（またはVPNクライアントを使用するホストで受信されます。ただし、ホスト自体は通常、デュアルスタックです。ホストはIPv4とIPv6の両方をサポート（およびデフォルトで有効化）します（IPv4のみのネットワークに接続するときに、このようなIPv6接続が単に「休止」している場合でも）。このようなホストのIPv6接続が有効になっている場合、それらは最終的にデュアルスタックネットワークでIPv6非対応VPNクライアントを採用する可能性があります。以下で説明するように、これは「予期しない」結果をもたらす可能性があります。

The subtle way in which the IPv4 and IPv6 protocols interact and coexist in dual-stacked networks might, either inadvertently or as a result of a deliberate attack, result in VPN tunnel traffic leakages -- that is, traffic meant to be transferred over a VPN tunnel could leak out of the VPN tunnel and be transmitted in the clear from the local network to the final destination, without employing the VPN services at all.

デュアルスタックネットワークでIPv4およびIPv6プロトコルが相互作用して共存する巧妙な方法は、不注意にまたは意図的な攻撃の結果として、VPNトンネルトラフィックリーク、つまりVPN経由で転送されるトラフィックをもたらす可能性がありますVPNサービスをまったく使用せずに、トンネルがVPNトンネルからリークし、ローカルネットワークから最終的な宛先に平文で送信される可能性があります。

Since this issue is specific to VPN solutions that route Layer 3 traffic, it is applicable to the following types of VPN technologies:

この問題はレイヤ3トラフィックをルーティングするVPNソリューションに固有なので、次のタイプのVPNテクノロジーに該当します。

o IPsec-based VPN tunnels

o IPsecベースのVPNトンネル

o SSL/TLS VPN tunnels

o SSL / TLS VPNトンネル

NOTE: see Section 2 for a definition and description of these terms.

注：これらの用語の定義と説明については、セクション2を参照してください。

Section 2 clarifies the terminology employed throughout this document. Section 3 provides some background about IPv6 and IPv4 coexistence, summarizing how IPv6 and IPv4 interact on a typical dual-stacked network. Section 4 describes the underlying problem that leads to the aforementioned VPN traffic leakages. Section 5 describes legitimate scenarios in which such traffic leakages might occur, while Section 6 describes how VPN traffic leakages can be triggered by deliberate attacks. Finally, Section 7 discusses possible mitigations for the aforementioned issue.

セクション2では、このドキュメント全体で使用される用語を明確にします。セクション3では、IPv6とIPv4の共存に関する背景情報を提供し、一般的なデュアルスタックネットワークでIPv6とIPv4がどのように相互作用するかを要約します。セクション4では、前述のVPNトラフィックリークにつながる根本的な問題について説明します。セクション5では、このようなトラフィックリークが発生する可能性のある正当なシナリオについて説明し、セクション6では、意図的な攻撃によってVPNトラフィックリークがどのようにトリガーされるかについて説明します。最後に、セクション7では、前述の問題に対して考えられる緩和策について説明します。

2. Terminology

2. 用語

When employing the term "Virtual Private Network tunnel" (or "VPN tunnel"), this document refers to VPN tunnels based on IPsec or SSL/ TLS, where Layer 3 packets are encapsulated and sent from a client to a middlebox, to access multiple network services (possibly employing different transport and/or application protocols).

「仮想プライベートネットワークトンネル」（または「VPNトンネル」）という用語を使用する場合、このドキュメントでは、レイヤー3パケットがカプセル化されてクライアントからミドルボックスに送信され、複数にアクセスするIPsecまたはSSL / TLSに基づくVPNトンネルを指しますネットワークサービス（異なるトランスポートプロトコルやアプリケーションプロトコルを使用している可能性があります）。

IPsec-based VPN tunnels simply employ IPsec in tunnel mode to encapsulate and transfer Layer 3 packets over the VPN tunnel. On the other hand, the term "SSL/TLS-based VPN tunnels" warrants a clarification, since two different technologies are usually referred to as "SSL/TLS VPN":

IPsecベースのVPNトンネルは、トンネルモードでIPsecを使用するだけで、VPNトンネルを介してレイヤー3パケットをカプセル化して転送します。一方、「SSL / TLSベースのVPNトンネル」という用語は、2つの異なるテクノロジーが通常「SSL / TLS VPN」と呼ばれるため、明確にする必要があります。

SSL/TLS VPN tunnel: A technology that encapsulates traffic from a client to a middlebox. In essence, an SSL/TLS VPN tunnel acts just like an IPsec-based tunnel, but instead employs SSL/TLS for encryption and some proprietary/unspecified mechanism for encapsulation and routing.

SSL / TLS VPNトンネル：クライアントからミドルボックスへのトラフィックをカプセル化するテクノロジー。本質的に、SSL / TLS VPNトンネルはIPsecベースのトンネルと同じように機能しますが、代わりに暗号化にSSL / TLSを採用し、カプセル化とルーティングに独自の/未指定のメカニズムを採用しています。

SSL/TLS VPN portal: A front-end provided by the middlebox to add security to a normally unsecured site. An SSL/TLS VPN portal is typically application specific, wrapping the specific protocol, such as HTTP, to provide access to specific services on a network. In such a case, the SSL/TLS VPN portal would be accessed just like any HTTPS URL. SSL/TLS VPN portals are used when one wants to restrict access and only provide remote users to very specific services on the network. SSL/TLS VPN portals do not require an agent, and the policy is typically more liberal from organizations allowing access from anywhere via this access method. All other traffic on the system may be routed directly to the destination, whether it is IPv4, IPv6, or even other service level (HTTP) destination addresses.

SSL / TLS VPNポータル：通常はセキュリティ保護されていないサイトにセキュリティを追加するためにミドルボックスによって提供されるフロントエンド。 SSL / TLS VPNポータルは通常、アプリケーション固有であり、HTTPなどの特定のプロトコルをラップして、ネットワーク上の特定のサービスへのアクセスを提供します。このような場合、SSL / TLS VPNポータルには、HTTPS URLと同じようにアクセスします。 SSL / TLS VPNポータルは、アクセスを制限し、リモートユーザーにネットワーク上の特定のサービスのみを提供する場合に使用されます。 SSL / TLS VPNポータルはエージェントを必要とせず、このポリシーは通常、このアクセス方法を介してどこからでもアクセスを許可する組織からより寛大です。システム上の他のすべてのトラフィックは、IPv4、IPv6、または他のサービスレベル（HTTP）宛先アドレスであっても、直接宛先にルーティングされます。

Our document focuses on Layer 3 VPNs that employ IPsec-based or SSL/ TLS-based tunnels, and excludes the so-called SSL/TLS VPN portals. Both IPsec-based and SSL/TLS-based VPN tunnels are designed to route Layer 3 traffic via the VPN tunnel through to the VPN tunnel server. Typically, these solutions are agent based, meaning that software is required on the client endpoint to establish the VPN tunnel and manage access control or routing rules. This provides an opportunity for controls to be managed through that application as well as on the client endpoint.

このドキュメントでは、IPsecベースのトンネルまたはSSL / TLSベースのトンネルを採用するレイヤー3 VPNに焦点を当て、いわゆるSSL / TLS VPNポータルを除外します。 IPsecベースとSSL / TLSベースの両方のVPNトンネルは、VPNトンネル経由でVPNトンネルサーバーにレイヤ3トラフィックをルーティングするように設計されています。通常、これらのソリューションはエージェントベースです。つまり、VPNトンネルを確立し、アクセス制御またはルーティングルールを管理するには、クライアントエンドポイントにソフトウェアが必要です。これにより、そのアプリケーションおよびクライアントエンドポイント上でコントロールを管理する機会が提供されます。

NOTE: Further discussion of SSL-based VPNs can be found in [SSL-VPNs].

注：SSLベースのVPNの詳細については、[SSL-VPNs]を参照してください。

We note that, in addition to the general case of "send all traffic through the VPN", this document considers the so-called "split-tunnel" case, where some subset of the traffic is sent through the VPN, while other traffic is sent to its intended destination with a direct routing path (i.e., without employing the VPN tunnel). We note that many organizations will prevent split-tunneling in their VPN configurations if they would like to make sure the users data goes through a gateway with protections (malware detection, URL filtering, etc.), but others are more interested in performance of the user's access or the ability for researchers to have options to access sites they may not be able to through the gateway.

このドキュメントでは、「VPN経由ですべてのトラフィックを送信する」という一般的なケースに加えて、トラフィックの一部がVPN経由で送信され、他のトラフィックが直接ルーティングパスを使用して目的の宛先に送信されます（つまり、VPNトンネルを使用せずに）。多くの組織では、ユーザーデータが確実に保護されたゲートウェイ（マルウェア検出、URLフィルタリングなど）を通過するようにしたい場合、VPN構成でのスプリットトンネリングを防止しますが、他の組織は、ユーザーのアクセス、または研究者がゲートウェイを介してアクセスできない可能性があるサイトにアクセスするオプションを持つ能力。

3. IPv4 and IPv6 Coexistence

3. IPv4とIPv6の共存

The coexistence of the IPv4 and IPv6 protocols has a number of interesting and subtle aspects that may have "surprising" consequences. While IPv6 is not backwards-compatible with IPv4, the two protocols are "glued" together by the Domain Name System (DNS).

IPv4プロトコルとIPv6プロトコルの共存には、「驚くべき」結果をもたらす可能性のある、興味深い微妙な側面が数多くあります。 IPv6はIPv4との下位互換性はありませんが、2つのプロトコルはドメインネームシステム（DNS）によって「接着」されています。

For example, consider a site (say, www.example.com) that has both IPv4 and IPv6 support. The corresponding domain name (www.example.com, in our case) will contain both A and AAAA DNS resource records (RRs). Each A record will contain one IPv4 address, while each AAAA record will contain one IPv6 address -- and there might be more than one instance of each of these record types. Thus, when a dual-stacked client application means to communicate with www.example.com, it can request both A and AAAA records and use any of the available addresses. The preferred address family (IPv4 or IPv6) and the specific address that will be used (assuming more than one address of each family is available) varies from one protocol implementation to another, with many host implementations preferring IPv6 addresses over IPv4 addresses.

たとえば、IPv4とIPv6の両方をサポートしているサイト（たとえば、www.example.com）について考えてみます。対応するドメイン名（この例ではwww.example.com）には、AとAAAAの両方のDNSリソースレコード（RR）が含まれます。各Aレコードには1つのIPv4アドレスが含まれ、各AAAAレコードには1つのIPv6アドレスが含まれます。これらの各レコードタイプのインスタンスが複数存在する場合があります。したがって、デュアルスタッククライアントアプリケーションがwww.example.comと通信することを意味する場合、AおよびAAAAレコードの両方を要求し、使用可能なアドレスのいずれかを使用できます。優先アドレスファミリ（IPv4またはIPv6）と使用される特定のアドレス（各ファミリの複数のアドレスが使用可能であると想定）は、プロトコルの実装によって異なります。多くのホストの実装では、IPv4アドレスよりもIPv6アドレスが優先されます。

NOTE: [RFC6724] specifies an algorithm for selecting a destination address from a list of IPv6 and IPv4 addresses. [RFC6555] discusses the challenge of selecting the most appropriate destination address, along with a proposed implementation approach that mitigates connection-establishment delays.

注：[RFC6724]は、IPv6およびIPv4アドレスのリストから宛先アドレスを選択するためのアルゴリズムを指定します。 [RFC6555]は、接続確立の遅延を軽減する提案された実装アプローチとともに、最も適切な宛先アドレスを選択する課題について説明します。

As a result of this "coexistence" between IPv6 and IPv4, when a dual-stacked client means to communicate with some other system, the availability of A and AAAA DNS resource records will typically affect which protocol is employed to communicate with that system.

IPv6とIPv4のこの「共存」の結果として、デュアルスタッククライアントが他のシステムと通信することを意味する場合、AおよびAAAA DNSリソースレコードの可用性は、通常、そのシステムとの通信に使用されるプロトコルに影響します。

4. Virtual Private Networks in IPv4/IPv6 Dual-Stack Hosts/Networks

4. IPv4 / IPv6デュアルスタックホスト/ネットワークの仮想プライベートネットワーク

Many VPN tunnel implementations do not support the IPv6 protocol -- or, what is worse, they completely ignore IPv6. This typically means that, once a VPN tunnel has been established, the VPN software takes care of the IPv4 connectivity by, e.g., inserting an IPv4 default route that causes all IPv4 traffic to be sent over the VPN tunnel (as opposed to sending the traffic in the clear, employing the local router). However, if IPv6 is not supported (or completely ignored), any packets destined to an IPv6 address will be sent in the clear using the local IPv6 router. That is, the VPN software will do nothing about the IPv6 traffic.

多くのVPNトンネル実装は、IPv6プロトコルをサポートしていません。さらに悪いことに、IPv6を完全に無視しています。これは通常、VPNトンネルが確立されると、VPNソフトウェアがIPv4接続を処理することを意味します。たとえば、すべてのIPv4トラフィックがVPNトンネルを介して送信されるようにするIPv4デフォルトルートを挿入します（トラフィックを送信するのではなく）平文で、ローカルルータを使用します）。ただし、IPv6がサポートされていない（または完全に無視されている）場合、IPv6アドレス宛のパケットは、ローカルIPv6ルーターを使用して平文で送信されます。つまり、VPNソフトウェアはIPv6トラフィックに対して何もしません。

The underlying reason for which these VPN leakages may occur is that, for dual-stacked systems, it is not possible to secure the communication with another system without securing both protocols (IPv6 and IPv4). Therefore, as long as the traffic for one of these protocols is not secured, there is the potential for VPN traffic leakages.

これらのVPNリークが発生する根本的な理由は、デュアルスタックシステムでは、両方のプロトコル（IPv6とIPv4）を保護しないと別のシステムとの通信を保護できないためです。したがって、これらのプロトコルのいずれかのトラフィックが保護されていない限り、VPNトラフィックリークが発生する可能性があります。

5. Inadvertent VPN Tunnel Traffic Leakages in Legitimate Scenarios

5. 正当なシナリオでの不注意によるVPNトンネルトラフィックの漏洩

Consider a dual-stacked host that employs IPv4-only VPN software to establish a VPN tunnel with a VPN server, and that said host now connects to a dual-stacked network (that provides both IPv6 and IPv4 connectivity). If some application on the client means to communicate with a dual-stacked destination, the client will typically query both A and AAAA DNS resource records. Since the host will have both IPv4 and IPv6 connectivity, and the intended destination will have both A and AAAA DNS resource records, one of the possible outcomes is that the host will employ IPv6 to communicate with the intended destination. Since the VPN software does not support IPv6, the IPv6 traffic will not employ the VPN tunnel; hence, it will have neither integrity nor confidentiality protection from the source host to the final destination.

IPv4専用VPNソフトウェアを使用してVPNサーバーとのVPNトンネルを確立し、このホストがデュアルスタックネットワークに接続する（IPv6とIPv4の両方の接続を提供する）デュアルスタックホストについて考えてみます。クライアント上の一部のアプリケーションがデュアルスタックの宛先と通信することを意味する場合、クライアントは通常、AおよびAAAA DNSリソースレコードの両方をクエリします。ホストにはIPv4とIPv6の両方の接続があり、目的の宛先にはAとAAAAの両方のDNSリソースレコードがあるため、考えられる結果の1つは、ホストがIPv6を使用して目的の宛先と通信することです。 VPNソフトウェアはIPv6をサポートしていないため、IPv6トラフィックはVPNトンネルを使用しません。したがって、ソースホストから最終的な宛先までの整合性も機密性も保護されません。

This could inadvertently expose sensitive traffic that was assumed to be secured by the VPN software. In this particular scenario, the resulting VPN tunnel traffic leakage is a side effect of employing IPv6-unaware VPN software in a dual-stacked host/network.

これにより、VPNソフトウェアによって保護されていると想定される機密トラフィックが誤って公開される可能性があります。この特定のシナリオでは、結果として生じるVPNトンネルトラフィックリークは、デュアルスタックのホスト/ネットワークでIPv6非対応VPNソフトウェアを採用することの副作用です。

6. VPN Tunnel Traffic Leakage Attacks

6. VPNトンネルトラフィックリーク攻撃

A local attacker could deliberately trigger IPv6 connectivity on the victim host by sending forged ICMPv6 Router Advertisement messages [RFC4861]. Such packets could be sent by employing standard software such as rtadvd [RTADVD], or by employing packet-crafting tools such as SI6 Network's IPv6 Toolkit [SI6-Toolkit] or THC's IPv6 Attack Toolkit [THC-IPv6]. Once IPv6 connectivity has been enabled, communications with dual-stacked systems could result in VPN tunnel traffic leakages, as previously described.

ローカルの攻撃者は、偽造されたICMPv6ルーターアドバタイズメッセージ[RFC4861]を送信することにより、犠牲ホストのIPv6接続を意図的にトリガーする可能性があります。このようなパケットは、rtadvd [RTADVD]などの標準ソフトウェアを使用するか、SI6 NetworkのIPv6ツールキット[SI6-Toolkit]またはTHCのIPv6 Attack Toolkit [THC-IPv6]などのパケット作成ツールを使用して送信できます。 IPv6接続が有効になると、前述のように、デュアルスタックシステムとの通信でVPNトンネルトラフィックリークが発生する可能性があります。

While this attack may be useful enough (due to the increasing number of IPv6-enabled sites), it will only lead to traffic leakages when the destination system is dual-stacked. However, it is usually trivial for an attacker to trigger such VPN tunnel traffic leakages for any destination system: an attacker could simply advertise himself as the local recursive DNS server by sending forged Router Advertisement messages [RFC4861] that include the corresponding Recursive DNS Server (RDNSS) option [RFC6106], and then perform a DNS spoofing attack such that he can become a "man in the middle" and intercept the corresponding traffic. As with the previous attack scenario, packet-crafting tools such as [SI6-Toolkit] and [THC-IPv6] can readily perform this attack.

この攻撃は（IPv6対応サイトの数が増えるため）十分に役立ちますが、宛先システムがデュアルスタックの場合にのみトラフィックリークが発生します。ただし、攻撃者が任意の宛先システムに対してこのようなVPNトンネルトラフィックリークをトリガーすることは、通常は取るに足らないことです。攻撃者は、対応する再帰DNSサーバー（ RDNSS）オプション[RFC6106]を選択し、DNSスプーフィング攻撃を実行して、「中間者」になり、対応するトラフィックを傍受できるようにします。以前の攻撃シナリオと同様に、[SI6-Toolkit]や[THC-IPv6]などのパケット作成ツールは、この攻撃を簡単に実行できます。

NOTE: Some systems are known to prefer IPv6-based recursive DNS servers over IPv4-based ones; hence, the "malicious" recursive DNS servers would be preferred over the legitimate ones advertised by the VPN server.

注：一部のシステムは、IPv4ベースのサーバーよりもIPv6ベースの再帰DNSサーバーを優先することが知られています。したがって、「悪意のある」再帰DNSサーバーは、VPNサーバーによって公示される正当なDNSサーバーよりも優先されます。

7. Mitigations to VPN Tunnel Traffic Leakage Vulnerabilities

7. VPNトンネルトラフィックリークの脆弱性の緩和策

At the time of this writing, a large number of VPN implementations have not yet addressed the issue of VPN tunnel traffic leakages. Most of these implementations simply ignore IPv6; hence, IPv6 traffic leaks out of the VPN tunnel. Some VPN tunnel implementations handle IPv6, but not properly. For example, they may be able to prevent inadvertent VPN tunnel traffic leakages arising in legitimate dual-stack networks, but they may fail to properly handle the myriad of vectors available to an attacker for injecting "more specific routes", such as ICMPv6 Router Advertisement messages with Prefix Information Options and/or Route Information Options, and ICMPv6 Redirect messages.

この記事の執筆時点では、多数のVPN実装がまだVPNトンネルトラフィックリークの問題に対処していません。これらの実装のほとんどは、単にIPv6を無視します。したがって、IPv6トラフィックがVPNトンネルからリークします。一部のVPNトンネル実装はIPv6を処理しますが、適切に処理しません。たとえば、正当なデュアルスタックネットワークで発生する不注意なVPNトンネルトラフィックリークを防ぐことはできますが、ICMPv6ルーターアドバタイズメントなどの「より具体的なルート」を注入するために攻撃者が利用できる無数のベクトルを適切に処理できない場合があります。プレフィックス情報オプションまたはルート情報オプション、あるいはその両方を含むメッセージ、およびICMPv6リダイレクトメッセージ。

Clearly, the issue of VPN tunnel traffic leakages warrants proper IPv6 support in VPN tunnel implementations.

明らかに、VPNトンネルトラフィックリークの問題は、VPNトンネル実装での適切なIPv6サポートを保証します。

7.1. Fixing VPN Client Software

7.1. VPNクライアントソフトウェアの修正

There are a number of possible mitigations for the VPN tunnel traffic leakage vulnerability discussed in this document.

このドキュメントで説明されているVPNトンネルトラフィックリークの脆弱性に対するいくつかの可能な緩和策があります。

If the VPN client is configured by administrative decision to redirect all IPv4 traffic to the VPN, it should:

VPNクライアントが管理上の決定により、すべてのIPv4トラフィックをVPNにリダイレクトするように構成されている場合は、次のようにする必要があります。

1. If IPv6 is not supported in the VPN software, disable IPv6 support in all network interfaces.

1. VPNソフトウェアでIPv6がサポートされていない場合は、すべてのネットワークインターフェイスでIPv6サポートを無効にします。

NOTE: For IPv6-unaware VPN clients, the most simple mitigation would be to disable IPv6 support in all network interface cards when a VPN tunnel is meant to be employed. Thus, applications on the host running the VPN client software will have no other option than to employ IPv4; hence, they will simply not even try to send/process IPv6 traffic. We note that this should only be regarded as a temporary workaround, since the proper mitigation would be to correctly handle IPv6 traffic.

注：IPv6非対応VPNクライアントの場合、最も簡単な緩和策は、VPNトンネルを使用する場合、すべてのネットワークインターフェイスカードでIPv6サポートを無効にすることです。したがって、VPNクライアントソフトウェアを実行しているホスト上のアプリケーションは、IPv4を使用する以外に選択肢がありません。したがって、IPv6トラフィックを送信/処理しようとはしません。適切な緩和策はIPv6トラフィックを正しく処理することであるため、これは一時的な回避策としてのみ見なされるべきであることに注意します。

2. If IPv6 is supported in the VPN software, ensure that all IPv6 traffic is also sent via the VPN.

2. VPNソフトウェアでIPv6がサポートされている場合は、すべてのIPv6トラフィックもVPN経由で送信されることを確認してください。

NOTE: This would imply, among other things, properly handling any vectors that might be employed by an attacker to install IPv6 routes at the victim system (such as ICMPv6 Router Advertisement messages with Prefix Information Options or Route information Options [RFC4191], ICMPv6 Redirect messages, etc.). We note that properly handling all the aforementioned vectors may prove to be nontrivial.

注：これは、とりわけ、攻撃者が被害者のシステムにIPv6ルートをインストールするために使用する可能性のあるベクトルを適切に処理することを意味します（プレフィックス情報オプションまたはルート情報オプション[RFC4191]を含むICMPv6ルーターアドバタイズメントメッセージ、ICMPv6リダイレクトなど）メッセージなど）。前述のすべてのベクターを適切に処理することは、重要なことです。

If the VPN client is configured to only send a subset of IPv4 traffic to the VPN tunnel (split-tunnel mode), then:

VPNクライアントがIPv4トラフィックのサブセットのみをVPNトンネルに送信するように構成されている場合（スプリットトンネルモード）、次のようになります。

1. If the VPN client does not support IPv6, it should disable IPv6 support in all network interfaces.

1. VPNクライアントがIPv6をサポートしていない場合は、すべてのネットワークインターフェイスでIPv6サポートを無効にする必要があります。

NOTE: As noted above, this should only be regarded as a temporary workaround, since the proper mitigation would be to correctly handle IPv6 traffic.

注：上記のように、IPv6トラフィックを正しく処理することが適切な緩和策であるため、これは一時的な回避策と見なす必要があります。

2. If the VPN client supports IPv6, it is the administrators responsibility to ensure that the correct corresponding sets of IPv4 and IPv6 networks get routed into the VPN tunnel.

2. VPNクライアントがIPv6をサポートしている場合、対応する正しいIPv4およびIPv6ネットワークのセットがVPNトンネルにルーティングされるようにするのは、管理者の責任です。

NOTE: As noted above, this would imply, among other things, properly handling any vectors that might be employed by an attacker to install IPv6 routes at the victim system. This may prove to be a nontrivial task.

注：上記のように、これはとりわけ、攻撃者が被害者のシステムにIPv6ルートをインストールするために使用する可能性のあるベクトルを適切に処理することを意味します。これは簡単な作業ではないかもしれません。

A network may prevent local attackers from successfully performing the aforementioned attacks against other local hosts by implementing First-Hop Security solutions such as Router Advertisement Guard (RA-Guard) [RFC6105] and DHCPv6-Shield [DHCPv6-SHIELD]. However, for obvious reasons, a host cannot and should not rely on this type of mitigations when connecting to an open network (cybercafe, etc.).

ネットワークは、ルーターアドバタイズメントガード（RA-Guard）[RFC6105]やDHCPv6-Shield [DHCPv6-SHIELD]などのファーストホップセキュリティソリューションを実装することにより、ローカルの攻撃者が他のローカルホストに対して前述の攻撃を実行するのを防ぐことができます。ただし、明らかな理由により、ホストは、オープンネットワーク（cybercafeなど）に接続するときに、この種の緩和策に依存することはできません。

NOTE: Besides, popular implementations of RA-Guard are known to be vulnerable to evasion attacks [RFC7113].

注：さらに、RA-Guardの一般的な実装は、回避攻撃に対して脆弱であることが知られています[RFC7113]。

Finally, we note that if (eventually) IPv6-only VPN implementations become available, similar issues to the ones discussed in this document could arise if these IPv6-only VPN implementations do nothing about the IPv4 traffic.

最後に、（最終的に）IPv6のみのVPN実装が利用可能になった場合、これらのIPv6のみのVPN実装がIPv4トラフィックに対して何もしない場合、このドキュメントで説明したものと同様の問題が発生する可能性があります。

7.2. Operational Mitigations

7.2. 運用上の緩和

While the desired mitigation for the issues discussed in this document is for VPN clients to be IPv6 aware, we note that in scenarios where this would be unfeasible, an administrator may want to disable IPv6 connectivity on all network interfaces of the node employing the IPv6-unaware VPN client.

このドキュメントで説明する問題の望ましい緩和策はVPNクライアントがIPv6対応であることですが、これが実行不可能なシナリオでは、管理者がIPv6を使用するノードのすべてのネットワークインターフェイスでIPv6接続を無効にしたい場合があることに注意してください。認識していないVPNクライアント。

8. Security Considerations

8. セキュリティに関する考慮事項

This document discusses how traffic meant to be transferred over a VPN tunnel can leak out of such a tunnel and, hence, appear in the clear on the local network. This is the result of employing IPv6-unaware VPN client software on dual-stacked hosts.

このドキュメントでは、VPNトンネルを介して転送されるはずのトラフィックが、そのようなトンネルからリークし、ローカルネットワーク上で平文で表示される方法について説明します。これは、デュアルスタックホストでIPv6非対応VPNクライアントソフトウェアを採用した結果です。

The proper mitigation of this issue is to correctly handle IPv6 traffic in the VPN client software. However, in scenarios in which such a mitigation is unfeasible, an administrator may choose to disable IPv6 connectivity on all network interfaces of the host employing the VPN client.

この問題を適切に緩和するには、VPNクライアントソフトウェアでIPv6トラフィックを正しく処理します。ただし、このような緩和策が実行不可能な状況では、管理者は、VPNクライアントを使用するホストのすべてのネットワークインターフェイスでIPv6接続を無効にすることを選択できます。

9. Acknowledgements

9. 謝辞

The author would like to thank Kathleen Moriarty and Paul Hoffman who contributed text that was readily incorporated into Section 2 of this document.

著者は、このドキュメントのセクション2にすぐに組み込まれたテキストを提供してくれたKathleen MoriartyとPaul Hoffmanに感謝します。

The author of this document would like to thank (in alphabetical order) Cameron Byrne, Spencer Dawkins, Gert Doering, Stephen Farrell, Seth Hall, Paul Hoffman, Tor Houghton, Russ Housley, Joel Jaeggli, Alastair Johnson, Merike Kaeo, Panos Kampanakis, Stephen Kent, Henrik Lund Kramshoj, Warren Kumari, Barry Leiba, Kathleen Moriarty, Thomas Osterried, Jim Small, Martin Vigoureux, and Andrew Yourtchenko for providing valuable comments on earlier draft versions of this document.

このドキュメントの著者は、感謝の意を表します（アルファベット順）Cameron Byrne、Spencer Dawkins、Gert Doering、Stephen Farrell、Seth Hall、Paul Hoffman、Tor Houghton、Russ Housley、Joel Jaeggli、Alastair Johnson、Merike Kaeo、Panos Kampanakis、このドキュメントの以前のドラフトバージョンに貴重なコメントを提供してくださったStephen Kent、Henrik Lund Kramshoj、Warren Kumari、Barry Leiba、Kathleen Moriarty、Thomas Osterried、Jim Small、Andrew Yourtchenko。

The author wishes to express deep and heartfelt gratitude to Enrique Garcia and Vicenta Tejedo, for their precious love and support.

著者は、エンリケガルシアとビセンタテヘドの貴重な愛とサポートに深い心からの感謝の意を表したいと思います。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.

[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーター設定とより具体的なルート」、RFC 4191、2005年11月。

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.

[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。

[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.

[RFC6106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 6106、2010年11月。

[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.

[RFC6555] Wing、D。、およびA. Yourtchenko、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、2012年4月。

[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.

[RFC6724] Thaler、D.、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、2012年9月。

10.2. Informative References

10.2. 参考引用

[DHCPv6-SHIELD] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", Work in Progress, July 2014.

[DHCPv6-SHIELD] Gont、F.、Liu、W。、およびG. Van de Velde、「DHCPv6-Shield：Protecting Against Rogue DHCPv6 Servers」、Work in Progress、2014年7月。

[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.

[RFC6105] Levy-Abegnoli、E.、Van de Velde、G.、Popoviciu、C.、J。Mohacsi、「IPv6 Router Advertisement Guard」、RFC 6105、2011年2月。

[RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, February 2014.

[RFC7113] Gont、F。、「IPv6ルーターアドバタイズメントガード（RA-Guard）の実装に関するアドバイス」、RFC 7113、2014年2月。

[RTADVD] "rtadvd(8) manual page", <http://www.freebsd.org/cgi/ man.cgi?query=rtadvd&sektion=8>.

[RTADVD] "rtadvd（8）manual page"、<http://www.freebsd.org/cgi/ man.cgi？query = rtadvd＆sektion = 8>。

[SI6-Toolkit] SI6 Networks, "SI6 Networks' IPv6 Toolkit", <http://www.si6networks.com/tools/ipv6toolkit>.

[SI6-Toolkit] SI6 Networks、「SI6 Networks 'IPv6 Toolkit」、<http://www.si6networks.com/tools/ipv6toolkit>。

[SSL-VPNs] Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72, SAAG Meeting, 2008, <http://www.ietf.org/proceedings/72/slides/saag-4.pdf>.

[SSL-VPNs] Hoffman、P。、「SSL VPNs：An IETF Perspective」、IETF 72、SAAG Meeting、2008、<http://www.ietf.org/proceedings/72/slides/saag-4.pdf> 。

[THC-IPv6] The Hacker's Choice, "THC-IPV6 - attacking the IPV6 protocol suite", <http://www.thc.org/thc-ipv6/>.

[THC-IPv6]ハッカーの選択、「THC-IPV6-IPV6プロトコルスイートへの攻撃」、<http://www.thc.org/thc-ipv6/>。

Author's Address

著者のアドレス

Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina

Fernando Gont Huawei Technologies Evaristo Carriego 2644ブエノスアイレス州ハエド1706アルゼンチン

   Phone: +54 11 4650 8472
   EMail: fgont@si6networks.com
   URI:   http://www.si6networks.com