Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, opsec mailing list <firstname.lastname@example.org>, opsec chair <email@example.com> Subject: Document Action: 'Layer-3 Virtual Private Network (VPN) tunnel traffic leakages in dual- stack hosts/networks' to Informational RFC (draft-ietf-opsec-vpn-leakages-06.txt) The IESG has approved the following document: - 'Layer-3 Virtual Private Network (VPN) tunnel traffic leakages in dual- stack hosts/networks' (draft-ietf-opsec-vpn-leakages-06.txt) as Informational RFC This document is the product of the Operational Security Capabilities for IP Network Infrastructure Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/
Technical Summary Due to the lack of proper IPv6 support in some popular Virtual Private Network (VPN) products, traffic meant to be transferred over a VPN connection may leak out of such connection and be transferred in the clear from the local network to the final destination. This document discusses some scenarios in which such leakages may occur and discusses possible mitigations. Working Group Summary There was no drama in the WG regarding this draft. The document is well written and easy to understand. There was good support in the WG for progressing this document. Merike Kaeo in particular provided good review and comments. There was decent feedback that resulted in changes during IETF LC. Document Quality The document is well written and easy to understand. There was good support in the WG for progressing this document. Merike Kaeo in particular provided good review and comments. Personnel Warren Kumari is the Document Shepherd. Joel Jaeggli is Responsible AD. RFC Editor Note Note, please add the IESG note. 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.