Browse Prior Art Database

Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks (RFC7359) Disclosure Number: IPCOM000238446D
Original Publication Date: 2014-Aug-01
Included in the Prior Art Database: 2014-Aug-27
Document File: 24 page(s) / 27K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People



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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 10% of the total text.

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


   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.

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.

   Information about the current status of this document, any errata,    and how to provide feedback on it may be obtained at

Gont                          Informational                     [Page 1]
 RFC 7359                  VPN Traffic Leakages               August 2014

 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 probl...