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 <iesg-secretary@ietf.org> Thu, 10 July 2014 15:49 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266351A043D; Thu, 10 Jul 2014 08:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d--0WFP7ewX5; Thu, 10 Jul 2014 08:49:11 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 190821A0ABB; Thu, 10 Jul 2014 08:48:51 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
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)
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.0.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140710154851.16234.30741.idtracker@ietfa.amsl.com>
Date: Thu, 10 Jul 2014 08:48:51 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-announce/gd8eeC9Q2GcSKxuyV5bnUWns9W0
Cc: opsec mailing list <opsec@ietf.org>, opsec chair <opsec-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jul 2014 15:49:13 -0000
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.