From aservin@lacnic.net Sat Dec 1 13:04:59 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A989C11E80A5 for ; Sat, 1 Dec 2012 13:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzEvOyWMX8-t for ; Sat, 1 Dec 2012 13:04:59 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7BB11E8099 for ; Sat, 1 Dec 2012 13:04:59 -0800 (PST) Received: from [IPv6:2800:af:ba30:e6c3:f508:7fc8:e0b1:35ef] (unknown [IPv6:2800:af:ba30:e6c3:f508:7fc8:e0b1:35ef]) by mail.lacnic.net.uy (Postfix) with ESMTP id EB650308444 for ; Sat, 1 Dec 2012 19:04:55 -0200 (UYST) Message-ID: <50BA70F6.4040209@lacnic.net> Date: Sat, 01 Dec 2012 19:04:54 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: opsec@ietf.org References: <67832B1175062E48926BF3CB27C49B240C8326B7@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B240C8326B7@xmb-aln-x12.cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [OPSEC] Poll for WG adoption of "draft-gont-opsec-dhcpv6-shield" X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 21:04:59 -0000 I have read and support. Regards, as On 27/11/2012 10:34, Gunter Van de Velde (gvandeve) wrote: > Hi folks, > > > > During IETF85 meeting this draft was found useful as WG document by the > OPSEC WG. > > > > This is a call for WG adoption of this work. Please voice your comments > in OPSEC WG email alias. > > > > Latest document: > http://datatracker.ietf.org/doc/draft-gont-opsec-dhcpv6-shield/ > > > > Kind Regards, > > OPSEC chairs > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From fgont@si6networks.com Mon Dec 3 08:06:50 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE1721F8593 for ; Mon, 3 Dec 2012 08:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwdehvSkD6cG for ; Mon, 3 Dec 2012 08:06:50 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id CD06121F8599 for ; Mon, 3 Dec 2012 08:06:49 -0800 (PST) Received: from 187-135-17-190.fibertel.com.ar ([190.17.135.187] helo=[192.168.123.124]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TfYWh-00018R-DS; Mon, 03 Dec 2012 17:06:18 +0100 Message-ID: <50BA4407.8040701@si6networks.com> Date: Sat, 01 Dec 2012 14:53:11 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20121108155344.21609.69598.idtracker@ietfa.amsl.com> <50B60F63.90800@gmail.com> In-Reply-To: <50B60F63.90800@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-opsec-v6.all@tools.ietf.org, opsec@ietf.org Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-01.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 16:06:50 -0000 Hi, Brian, On 11/28/2012 10:19 AM, Brian E Carpenter wrote: >> 2.1.4. Privacy Extension Addresses > > I think it is better to use the correct terminology from > RFC 4941: "Temporary Addresses". > >> Since MAC addresses for specific >> vendor equipment can be know, it may be easy for a potential attacker >> to perform a more directed intelligent scan to try and ascertain >> specific vendor device reachability for exploitation. Privacy >> extensions attempts to mitigate this threat. > > That is misleading. This mitigation is a side-effect of temporary > addresses; the design motivation was to protect user privacy. Well, actually, privacy/temporary addresses do not provide any mitigation for address scanning attacks, since they are employed *in addition* to traditional SLAAC addresses. -- e.g., see the appendix in draft-ietf-6man-stable-privacy-addresses Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Tina.Tsou.Zouting@huawei.com Tue Dec 4 21:46:37 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD7C21F85EA for ; Tue, 4 Dec 2012 21:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaKWUt4v1t4a for ; Tue, 4 Dec 2012 21:46:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFB621F8484 for ; Tue, 4 Dec 2012 21:46:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AME57175; Wed, 05 Dec 2012 05:46:34 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 05:45:25 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 05:45:52 +0000 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.39]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Tue, 4 Dec 2012 21:45:47 -0800 From: Tina TSOU To: Arturo Servin Thread-Topic: [OPSEC] Poll for WG adoption of "draft-gont-opsec-dhcpv6-shield" Thread-Index: Ac3Mmyvmk7+I5HczQcyRUdYsnOR6pwDr2T0AAJhNUOA= Date: Wed, 5 Dec 2012 05:45:46 +0000 Message-ID: References: <67832B1175062E48926BF3CB27C49B240C8326B7@xmb-aln-x12.cisco.com>, <50BA70F6.4040209@lacnic.net> In-Reply-To: <50BA70F6.4040209@lacnic.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Poll for WG adoption of "draft-gont-opsec-dhcpv6-shield" X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 05:46:37 -0000 Dear all, I have read draft-gont-opsec-dhcpv6-shield-01 and believe the DHCP signalin= g issue pointed here is significant. The draft provides a simple but applic= able strategy to filter DHCP msg from vicious servers, thereby protect the = host. With the manual configuration and layer-2 deployment, the method is e= asy-to-use and the draft has the guiding significance for DHCPv6 deployment= scenario.=20 I support the adoption of this document as WG document. Thank you, Tina On Dec 1, 2012, at 1:05 PM, "Arturo Servin" wrote: >=20 > I have read and support. >=20 > Regards, > as >=20 > On 27/11/2012 10:34, Gunter Van de Velde (gvandeve) wrote: >> Hi folks, >>=20 >>=20 >>=20 >> During IETF85 meeting this draft was found useful as WG document by the >> OPSEC WG. >>=20 >>=20 >>=20 >> This is a call for WG adoption of this work. Please voice your comments >> in OPSEC WG email alias. >>=20 >>=20 >>=20 >> Latest document: >> http://datatracker.ietf.org/doc/draft-gont-opsec-dhcpv6-shield/ >>=20 >>=20 >>=20 >> Kind Regards, >>=20 >> OPSEC chairs >>=20 >>=20 >>=20 >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >>=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From internet-drafts@ietf.org Wed Dec 12 02:10:34 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C0021F89B2; Wed, 12 Dec 2012 02:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmx51TUkTSfZ; Wed, 12 Dec 2012 02:10:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED9C21F89A8; Wed, 12 Dec 2012 02:10:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121212101033.30907.97361.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 02:10:33 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 10:10:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers Author(s) : Fernando Gont Will Liu Gunter Van de Velde Filename : draft-ietf-opsec-dhcpv6-shield-00.txt Pages : 13 Date : 2012-12-12 Abstract: This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-dhcpv6-shield-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Dec 12 07:59:38 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893C621E8054; Wed, 12 Dec 2012 07:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZAAh1K72HlB; Wed, 12 Dec 2012 07:59:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24A921F8983; Wed, 12 Dec 2012 07:59:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121212155937.22777.22457.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 07:59:37 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:59:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : Virtual Private Network (VPN) traffic leakages in dual-s= tack hosts/ networks Author(s) : Fernando Gont Filename : draft-ietf-opsec-vpn-leakages-00.txt Pages : 14 Date : 2012-12-12 Abstract: The subtle way in which the IPv6 and IPv4 protocols co-exist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) products, may inadvertently result in VPN traffic leaks. That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be transferred in the clear on the local network. This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. Additionally, it discusses possible mitigations for the aforementioned issue. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-vpn-leakages-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Dec 12 14:03:23 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EC821E8090; Wed, 12 Dec 2012 14:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivOj25FMIFKl; Wed, 12 Dec 2012 14:03:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D9A21E804B; Wed, 12 Dec 2012 14:03:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121212220301.6998.71266.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 14:03:01 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 22:03:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : Network Reconnaissance in IPv6 Networks Author(s) : Fernando Gont Tim Chown Filename : draft-ietf-opsec-ipv6-host-scanning-00.txt Pages : 33 Date : 2012-12-12 Abstract: IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than their IPv4 counterparts. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and therefore IPv6 address scanning attacks have long been considered unfeasible. This document analyzes how traditional address scanning techniques apply to IPv6 networks, and also explores a number of other techniques that can be employed for IPv6 network reconnaissance. Additionally, this document formally obsoletes RFC 5157. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Dec 12 15:28:09 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A2D21F881C; Wed, 12 Dec 2012 15:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBlR+rjb8gBz; Wed, 12 Dec 2012 15:28:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C880921F8824; Wed, 12 Dec 2012 15:28:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121212232808.2524.17336.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 15:28:08 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-01.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 23:28:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : Security Implications of IPv6 on IPv4 Networks Author(s) : Fernando Gont Will Liu Filename : draft-ietf-opsec-ipv6-implications-on-ipv4-nets-01.txt Pages : 19 Date : 2012-12-12 Abstract: This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4= -nets There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-= 01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ipv6-implications-on-ip= v4-nets-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gvandeve@cisco.com Thu Dec 13 06:36:25 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE1E21F8B07 for ; Thu, 13 Dec 2012 06:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_31=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkzvqAiX4Ohk for ; Thu, 13 Dec 2012 06:36:24 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 26BC021F88F4 for ; Thu, 13 Dec 2012 06:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23106; q=dns/txt; s=iport; t=1355409384; x=1356618984; h=from:to:subject:date:message-id:mime-version; bh=2CGe+/pEtJY4HrWMuePoyMRbHsbAmTCD5VhMGOxItVA=; b=cZXtxT9Jgb4IUpWKbTqznHM1Citf0KSYFQGp3NZV9/pOoYDVP9effEMm k0DDc2bcNAFCbAIzmZnQiuywrqT10chy7G1lmSs3On80AMHCZCJcetJqs GqSm/13QWQGcTmUe4+fGjd5GQrbsTXMuj6C8xufcteEPByIN9IW9jpN3X E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD/nyVCtJV2b/2dsb2JhbABFgkm8KBZzgiABBC1eASoCFEAmAQQbAYgKDJwRoWOQOWEDplGCc4FkBDo X-IronPort-AV: E=Sophos;i="4.84,273,1355097600"; d="scan'208,217";a="152605744" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 13 Dec 2012 14:36:23 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBDEaN5t018213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Dec 2012 14:36:23 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.128]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 08:36:23 -0600 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: Important Dates for IETF86 Thread-Index: Ac3ZPynkBxa8PBeVTI6tsH6zFXBHNQ== Date: Thu, 13 Dec 2012 14:36:22 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240C84EDA7@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.67.86] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240C84EDA7xmbalnx12ciscoc_" MIME-Version: 1.0 Subject: [OPSEC] Important Dates for IETF86 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:36:25 -0000 --_000_67832B1175062E48926BF3CB27C49B240C84EDA7xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find details online at: https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF86 IETF 86: March 10-15, 2013, Orlando, Florida, USA Download .ICS file = of important dates for IETF 86 Subscribe to important dates calendar for IETF 86: http://www.ietf.org/meet= ing/86/86-important-dates.ics * 2012-12-10 (Week of): IETF Online Registration opens. * 2012-12-10 (Monday): Working Group and BOF scheduling begins. To requ= est a Working Group session, use the IETF Meeting Session Request Tool. * 2013-01-14 (Monday): Cutoff date for requests to schedule Working Gro= up meetings at UTC 24:00. To request a Working Group session, use the IETF = Meeting Session Request Tool. * 2013-01-28 (Monday): Cutoff date for BOF proposal requests to Area Di= rectors at UTC 24:00. To request a BOF, please see instructions on Requesti= ng a BOF. * 2013-01-31 (Thursday): Cutoff date for Area Directors to approve BOFs= at UTC 24:00. * 2013-02-07 (Thursday): Preliminary agenda published for comment. * 2013-02-11 (Monday): Cutoff date for requests to reschedule Working G= roup and BOF meetings UTC 24:00. * 2013-02-11 (Monday): Working Group Chair approval for initial documen= t (Version -00) submissions appreciated by UTC 24:00. * 2013-02-15 (Friday): Final agenda to be published. * 2013-02-18 (Monday): Internet Draft Cut-off for initial document (-00= ) submission by UTC 24:00, upload usingIETF ID Submission Tool. * 2013-02-25 (Monday): Internet Draft final submission cut-off by UTC 2= 4:00, upload using IETF ID Submission Tool. * 2013-02-27 (Wednesday): Draft Working Group agendas due by UTC 24:00,= upload using IETF Meeting Materials Management Tool. * 2013-03-01 (Friday): Early Bird registration and payment cut-off at U= TC 24:00. * 2013-03-04 (Monday): Revised Working Group agendas due by UTC 24:00, = upload using IETF Meeting Materials Management Tool. * 2013-03-04 (Monday): Registration cancellation cut-off at UTC 24:00. * 2013-03-08 (Friday): Final Pre-Registration and Pre-Payment cut-off a= t 17:00 local meeting time. * 2013-03-10 - 2013-03-15: 86th IETF Meeting in Orlando, Florida, USA. * 2013-04-12 (Friday): Proceedings submission cutoff date by UTC 24:00,= upload using IETF Meeting Materials Management Tool. * 2013-05-01 (Wednesday): Proceedings submission corrections cutoff dat= e by UTC 24:00, upload using IETF Meeting Materials Management Tool. --_000_67832B1175062E48926BF3CB27C49B240C84EDA7xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please find details online at:

https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF= 86

 

IETF 86:=  March 10-15, 2013, Orlando, Florida, USA

Download .I= CS file of important dates for IETF 86
Subscribe to important dates calendar for IETF 86: http://www.ietf.org/meet= ing/86/86-important-dates.ics

  • 2012-12-10 (Week of): IETF Online Registration opens.
  • 2012-12-10 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use t= he IETF Meeting Session= Request Tool.
  • 2013-01-14 (Monday): Cutoff date for requests to schedule Working Group meetings at UTC 24:00. To requ= est a Working Group session, use the&= nbsp;IETF Meeting Session Request Tool.
  • 2013-01-28 (Monday): Cutoff date for BOF proposal requests to Area Directors at UTC 24:00. To request = a BOF, please see instructions on&nbs= p;Requesti= ng a BOF.
  • 2013-01-31 (Thursday): Cutoff date for Area Directors to approve BOFs at UTC 24:00.
  • 2013-02-07 (Thursday): Prelimi= nary agenda published for comment.
  • 2013-02-11 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings UTC 24:00.<= o:p>
  • 2013-02-11 (Monday): Working Group Chair approval for initial document (Version -00) submissions apprec= iated by UTC 24:00.
  • 2013-02-15 (Friday): Final agenda to be published.
  • 2013-02-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload u= singIETF ID Submission Too= l.
  • 2013-02-25 (Monday): Internet Draft final submission cut-off by UTC 24:00, upload using IETF ID Submission Tool.
  • 2013-02-27 (Wednesday): Draft Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool.
  • 2013-03-01 (Friday): Early Bird registration and payment cut-off at UTC 24:00.
    • =
  • 2013-03-04 (Monday): Revised Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool.
  • 2013-03-04 (Monday): Registrat= ion cancellation cut-off at UTC 24:00.
  • 2013-03-08 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 local meeting time.=
  • 2013-03-10 - 2013-03-15: 86th IETF Meeting in Orlando,= Florida, USA.
  • 2013-04-12 (Friday): Proceedin= gs submission cutoff date by UTC 24:00, upload using IETF Meeting Materials Management Tool.
  • 2013-05-01 (Wednesday): Procee= dings submission corrections cutoff date by UTC 24:00, upload using IETF Meeting Materials Management Tool<= /a>.

 

--_000_67832B1175062E48926BF3CB27C49B240C84EDA7xmbalnx12ciscoc_-- From wesley.george@twcable.com Thu Dec 13 10:29:41 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455C321F8AD1 for ; Thu, 13 Dec 2012 10:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.107 X-Spam-Level: X-Spam-Status: No, score=0.107 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm0t7JahawkA for ; Thu, 13 Dec 2012 10:29:38 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A464B21F8A99 for ; Thu, 13 Dec 2012 10:29:37 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,275,1355115600"; d="scan'208,217";a="468196737" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Dec 2012 13:27:40 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 13 Dec 2012 13:28:23 -0500 From: "George, Wes" To: "opsec@ietf.org" Date: Thu, 13 Dec 2012 13:28:24 -0500 Thread-Topic: Security Implications of IPv6 on IPv4 Networks Thread-Index: Ac3ZX59+8xjBLVCASteziGkBOQVNxQ== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033907350D@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD5923033907350DPRVPEXVS15cor_" MIME-Version: 1.0 Cc: "draft-ietf-opsec-ipv6-implications-on-ipv4-nets@tools.ietf.org" Subject: [OPSEC] Security Implications of IPv6 on IPv4 Networks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:29:41 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD5923033907350DPRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've reviewed draft-ietf-opsec-ipv6-implications-on-ipv4-nets. First a comment about your filtering recommendations: I believe that you need to recommend filtering AAAA records and discuss the= risk of IPv6 breakage if these security controls are not implemented prope= rly on internet-connected networks. It'd be good for us to make sure that t= his doesn't become another example of the problems created when an overzeal= ous or incompetent security person filters indiscriminately (e.g. filtering= all ICMP because they don't realize that not all ICMP is bad). A large sou= rce of IPv6 brokenness today comes from nodes that believe that they have f= unctional IPv6 connectivity, but the path to their destination fails somewh= ere upstream. Upstream filtering of transition technologies or native IPv6 = without also filtering AAAA records may result in end hosts attempting to r= each IPv6 hosts, and depending on the absence or presence of happy eyeballs= , there may be a non-trivial timeout period before the host falls back to I= Pv4. Depending on the network and DNS configuration, it may be enough to si= mply configure the recursive DNS to not answer any AAAA queries (in the cas= e where all DNS is forced to a set of managed servers). If DNS traffic is p= ermitted from other hosts in the network, it may be necessary to examine al= l port 53 traffic and block AAAAs at the entrance to the network. It may ev= en be appropriate to recommend something like sending resets to any attempt= s to establish connections to IPv6 hosts. I believe that there are a few ne= tworks in Japan that had to do this on their private IPv6 networks to preve= nt major brokenness as more websites went dual-stack. We have enough major = destinations and applications IPv6-enabled that it's important to make it c= lear how bad of an idea it is to just break IPv6 under the assumption that = no one uses it yet anyway. I also have a concern about the general tone of the document that I believe= should be addressed. What I mean is that this document currently treats IPv4-only networks as so= mething that will be relatively commonplace, but assumes that the same netw= ork administrators who are un[willing|able] to expend the effort to deploy = IPv6 will also be concerned enough about it to worry about its security imp= acts, even concerned enough to expend energy to disable it or defeat it rat= her than deploying it and implementing proper security controls or simply f= orcibly disabling it on the end hosts. I'm not convinced about that choice = of audience. 5 years ago, maybe, but not in 2013. I think the document should be stating up front that the primary recommenda= tion for addressing the security considerations of unauthorized use of IPv6= in an IPv4-only network is to deploy IPv6 with proper security controls. T= his usually results in any transition technologies shutting down in favor o= f the native connectivity, and even if it doesn't, the act of disabling IPv= 6 transition technologies will not result in shutting down IPv6 access as n= oted in my comments above. This also could underscore the point that part o= f the reason why there may be tunneled IPv6 traffic or other transition tec= hnologies in use on the network is *because* there is no official IPv6 supp= ort and one or more of the users of the network have decided that IPv6 supp= ort is necessary enough to take matters into their own hands. Reiterating a= strong recommendation to deploy IPv6 to solve this problem also complement= s IETF's guidance in RFC6540 (IPv6 is no longer optional) nicely. I think that the last sentence in section 2.1 should probably set the tone = for the document - that is, there are going to be legitimate reasons for ha= ving IPv4-only networks, and those networks should consider IPv6 when build= ing their security profile because it is enabled by default now, but an IPv= 4-only network should be the exception rather than the rule. As a result, d= isabling or otherwise interfering with IPv6 traffic should be a last resort= , probably based on the knowledge that this network will *never* support or= require IPv6, rather than simply to delay use of IPv6 because the network = [administrator] "isn't ready" for IPv6 yet. While I don't think that it's a= ppropriate for IETF to identify specific "legitimate" reasons or use cases = for a network remaining IPv4-only, I think we could perhaps pose a few gene= ral questions to guide the thought process between whether to deploy IPv6 o= r disable it as an answer to its potential security risks. Thanks, Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_2671C6CDFBB59E47B64C10B3E0BD5923033907350DPRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve reviewed draft-ietf-opsec-ipv6-implicatio= ns-on-ipv4-nets.

 

First a comment about your filtering recommendations= :

I believe that you need to recommend filtering AAAA = records and discuss the risk of IPv6 breakage if these security controls ar= e not implemented properly on internet-connected networks. It’d be go= od for us to make sure that this doesn’t become another example of the problems created when an overzealous or inco= mpetent security person filters indiscriminately (e.g. filtering all ICMP b= ecause they don’t realize that not all ICMP is bad). A large source o= f IPv6 brokenness today comes from nodes that believe that they have functional IPv6 connectivity, but the path to = their destination fails somewhere upstream. Upstream filtering of transitio= n technologies or native IPv6 without also filtering AAAA records may resul= t in end hosts attempting to reach IPv6 hosts, and depending on the absence or presence of happy eyeballs, th= ere may be a non-trivial timeout period before the host falls back to IPv4.= Depending on the network and DNS configuration, it may be enough to simply= configure the recursive DNS to not answer any AAAA queries (in the case where all DNS is forced to a set = of managed servers). If DNS traffic is permitted from other hosts in the ne= twork, it may be necessary to examine all port 53 traffic and block AAAAs a= t the entrance to the network. It may even be appropriate to recommend something like sending resets to any = attempts to establish connections to IPv6 hosts. I believe that there are a= few networks in Japan that had to do this on their private IPv6 networks t= o prevent major brokenness as more websites went dual-stack. We have enough major destinations and applicatio= ns IPv6-enabled that it’s important to make it clear how bad of an id= ea it is to just break IPv6 under the assumption that no one uses it yet an= yway.

 

I also have a concern about the general tone of the = document that I believe should be addressed.

What I mean is that this document currently treats I= Pv4-only networks as something that will be relatively commonplace, but ass= umes that the same network administrators who are un[willing|able] to expen= d the effort to deploy IPv6 will also be concerned enough about it to worry about its security impacts, even con= cerned enough to expend energy to disable it or defeat it rather than deplo= ying it and implementing proper security controls or simply forcibly disabl= ing it on the end hosts. I’m not convinced about that choice of audience. 5 years ago, maybe, but not in 20= 13.

 

I think the document should be stating up front that= the primary recommendation for addressing the security considerations of u= nauthorized use of IPv6 in an IPv4-only network is to deploy IPv6 with prop= er security controls. This usually results in any transition technologies shutting down in favor of the nativ= e connectivity, and even if it doesn’t, the act of disabling IPv6 tra= nsition technologies will not result in shutting down IPv6 access as noted = in my comments above. This also could underscore the point that part of the reason why there may be tunneled IPv= 6 traffic or other transition technologies in use on the network is *bec= ause* there is no official IPv6 support and one or more of the users of= the network have decided that IPv6 support is necessary enough to take matters into their own hands. Reiterat= ing a strong recommendation to deploy IPv6 to solve this problem also compl= ements IETF’s guidance in RFC6540 (IPv6 is no longer optional) nicely= .

 

I think that the last sentence in section 2.1 should= probably set the tone for the document – that is, there are going to= be legitimate reasons for having IPv4-only networks, and those networks sh= ould consider IPv6 when building their security profile because it is enabled by default now, but an IPv4-only network sho= uld be the exception rather than the rule. As a result, disabling or otherw= ise interfering with IPv6 traffic should be a last resort, probably based o= n the knowledge that this network will *never* support or require IPv6, rather than simply to delay u= se of IPv6 because the network [administrator] “isn’t readyR= 21; for IPv6 yet. While I don’t think that it’s appropriate for= IETF to identify specific “legitimate” reasons or use cases fo= r a network remaining IPv4-only, I think we could perhaps pose a few general= questions to guide the thought process between whether to deploy IPv6 or d= isable it as an answer to its potential security risks.

 

 

Thanks,

 

Wes George


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_2671C6CDFBB59E47B64C10B3E0BD5923033907350DPRVPEXVS15cor_-- From internet-drafts@ietf.org Thu Dec 13 17:35:24 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9F621F8C0B; Thu, 13 Dec 2012 17:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49kRoYR8A6JT; Thu, 13 Dec 2012 17:35:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B55D21F8C03; Thu, 13 Dec 2012 17:35:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121214013524.17225.69959.idtracker@ietfa.amsl.com> Date: Thu, 13 Dec 2012 17:35:24 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ip-options-filtering-01.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 01:35:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : Recommendations on filtering of IPv4 packets containing = IPv4 options Author(s) : Fernando Gont RJ Atkinson Carlos Pignataro Filename : draft-ietf-opsec-ip-options-filtering-01.txt Pages : 29 Date : 2012-12-13 Abstract: This document document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filtering-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fgont@si6networks.com Mon Dec 17 08:05:04 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA3721F8B45 for ; Mon, 17 Dec 2012 08:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtM85NE44OOO for ; Mon, 17 Dec 2012 08:05:03 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0637721F8B44 for ; Mon, 17 Dec 2012 08:05:03 -0800 (PST) Received: from 187-135-17-190.fibertel.com.ar ([190.17.135.187] helo=[192.168.123.124]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TkdAF-0001k5-LL; Mon, 17 Dec 2012 17:04:55 +0100 Message-ID: <50CF423D.3000503@si6networks.com> Date: Mon, 17 Dec 2012 13:03:09 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "George, Wes" References: <2671C6CDFBB59E47B64C10B3E0BD5923033907350D@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923033907350D@PRVPEXVS15.corp.twcable.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "opsec@ietf.org" , "draft-ietf-opsec-ipv6-implications-on-ipv4-nets@tools.ietf.org" Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 16:05:04 -0000 Hi, Wes, Thanks so much for your feedback! -- Please find my responses inline.... On 12/13/2012 03:28 PM, George, Wes wrote: > I believe that you need to recommend filtering AAAA records Filtering AAAA records at the organizational recursive DNS server? > and discuss > the risk of IPv6 breakage if these security controls are not implemented > properly on internet-connected networks. Could you please elaborate on what you mean by "IPv6 breakage"? > It’d be good for us to make > sure that this doesn’t become another example of the problems created > when an overzealous or incompetent security person filters > indiscriminately (e.g. filtering all ICMP because they don’t realize > that not all ICMP is bad). FWIW, this I-D does not really advocate filtering, but rather argues that "you should do something about this". Filtering is just one of the possible things one might do. > A large source of IPv6 brokenness today comes > from nodes that believe that they have functional IPv6 connectivity, but > the path to their destination fails somewhere upstream. Upstream > filtering of transition technologies or native IPv6 without also > filtering AAAA records may result in end hosts attempting to reach IPv6 > hosts, and depending on the absence or presence of happy eyeballs, there > may be a non-trivial timeout period before the host falls back to IPv4. Ok, I see what you mean. I will add a paragraph about this. > Depending on the network and DNS configuration, it may be enough to > simply configure the recursive DNS to not answer any AAAA queries (in > the case where all DNS is forced to a set of managed servers). If DNS > traffic is permitted from other hosts in the network, it may be > necessary to examine all port 53 traffic and block AAAAs at the entrance > to the network. It may even be appropriate to recommend something like > sending resets to any attempts to establish connections to IPv6 hosts. Isn't that of sending RSTs like getting into too many details? Or, do you think I should add some text about this? > I > believe that there are a few networks in Japan that had to do this on > their private IPv6 networks to prevent major brokenness as more websites > went dual-stack. We have enough major destinations and applications > IPv6-enabled that it’s important to make it clear how bad of an idea it > is to just break IPv6 under the assumption that no one uses it yet anyway. For all the cases discussed in the document, hosts would not even get to configure an IPv6 address. e.g., if you're filtering 6to4, it's because you're not planning to send legitimate RAs on the local network. In the same way, when we discuss filtering Teredo, the host doesnt get to configure a Teredo address... > I also have a concern about the general tone of the document that I > believe should be addressed. > > What I mean is that this document currently treats IPv4-only networks as > something that will be relatively commonplace, but assumes that the same > network administrators who are un[willing|able] to expend the effort to > deploy IPv6 will also be concerned enough about it to worry about its > security impacts, even concerned enough to expend energy to disable it > or defeat it rather than deploying it and implementing proper security > controls or simply forcibly disabling it on the end hosts. I’m not > convinced about that choice of audience. 5 years ago, maybe, but not in > 2013. This document doesn't take a stance on whether you should deploy v6 or not. There are too many details and factors behind such decision. The document essentially argues "this v6 stuff is running on your network, and you should make an explicit decision on what you want to do with it". > I think the document should be stating up front that the primary > recommendation for addressing the security considerations of > unauthorized use of IPv6 in an IPv4-only network is to deploy IPv6 with > proper security controls. I'm personally not sure whether it's possible for us to make such recommendation, in the sense that for many networks, that's not an option. People is going to deploy v6 if they need it -- not to mitigate it's security implications. e.g., think about a network currently employing [put your favorite security technologies/devices here] that currently do not support v6. They are not going to buy new gear just to address these issues -- most likely, they are going to employ packet filtering. Put another way, being an ops document, I'd personally like to keep it as realistic as possible.... > This usually results in any transition > technologies shutting down in favor of the native connectivity, and even > if it doesn’t, the act of disabling IPv6 transition technologies will > not result in shutting down IPv6 access as noted in my comments above. > This also could underscore the point that part of the reason why there > may be tunneled IPv6 traffic or other transition technologies in use on > the network is **because** there is no official IPv6 support and one or > more of the users of the network have decided that IPv6 support is > necessary enough to take matters into their own hands. Well, here we're providing advice to network/security administrators, who are the ones expected to set the policy for their network. In these cases, users do not "decide", but rather comply with the policy set by the security/network admin. > Reiterating a > strong recommendation to deploy IPv6 to solve this problem also > complements IETF’s guidance in RFC6540 (IPv6 is no longer optional) nicely. I personally think that that would be kind of out of the scope for this document. However, I have no problem to go in that direction if wg agrees to do do. My take is that this is an *op*sec document. And while "you should deploy v6" sounds nice, for many networks that'd be unrealistic. (FWIW, we had a similar discussion at the last IETF meeting, where some folks argued that the way to go to mitigate vpn leakages was to add v6 support to the VPN software, but then it became clear that that was easier said than done -- please take a look at the minutes) > I think that the last sentence in section 2.1 should probably set the > tone for the document – that is, there are going to be legitimate > reasons for having IPv4-only networks, and those networks should > consider IPv6 when building their security profile because it is enabled > by default now, but an IPv4-only network should be the exception rather > than the rule. As a result, disabling or otherwise interfering with IPv6 > traffic should be a last resort, probably based on the knowledge that > this network will **never** support or require IPv6, rather than simply > to delay use of IPv6 because the network [administrator] “isn’t ready” > for IPv6 yet. As noted above, I personally think this is going too far. Example: I'm running a network that currently does not support v6. IN that network,I enforce the filtering policies described in this document. I know that sometime in the future I will deploy v6 on this network... at which point I'll remove the current filtering policies. > While I don’t think that it’s appropriate for IETF to > identify specific “legitimate” reasons or use cases for a network > remaining IPv4-only, I think we could perhaps pose a few general > questions to guide the thought process between whether to deploy IPv6 or > disable it as an answer to its potential security risks. I personally think that the question of whether to deploy v6 or not is, for the most part, unrelated to this document. You'll deploy v6 if you have reasons to do so. If you have decided to deploy v6, then you'll address v6 security implications by enforcing v6 security controls. OTOH, if for some reason you haver decided not to deploy v6 (yet), then (most likely) you'll address many of the v6 security implications by enforcing packet filtering. FWIW, that's *my* take... I'm all ears for others to weigh in.... Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From wesley.george@twcable.com Mon Dec 17 14:29:29 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313D921F8939 for ; Mon, 17 Dec 2012 14:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScxN+W83b+op for ; Mon, 17 Dec 2012 14:29:27 -0800 (PST) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 3B55C21F8938 for ; Mon, 17 Dec 2012 14:29:27 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,305,1355115600"; d="scan'208";a="3875482" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 17 Dec 2012 17:28:21 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 17 Dec 2012 17:29:26 -0500 From: "George, Wes" To: Fernando Gont Date: Mon, 17 Dec 2012 17:29:29 -0500 Thread-Topic: [OPSEC] Security Implications of IPv6 on IPv4 Networks Thread-Index: Ac3ccM8aQju/EwJ5QpKZX+QFmGmWhQAEjDIg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230339D95F50@PRVPEXVS15.corp.twcable.com> References: <2671C6CDFBB59E47B64C10B3E0BD5923033907350D@PRVPEXVS15.corp.twcable.com> <50CF423D.3000503@si6networks.com> In-Reply-To: <50CF423D.3000503@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" , "draft-ietf-opsec-ipv6-implications-on-ipv4-nets@tools.ietf.org" Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:29:29 -0000 > From: Fernando Gont [mailto:fgont@si6networks.com] > > Filtering AAAA records at the organizational recursive DNS server? > > [WEG] yes, to ensure that even if an end client thinks it has IPv6 connecti= vity, and the network is actively working to filter/disable IPv6, this will= ensure that the client doesn't receive responses for AAAA queries and atte= mpt to connect to an IPv6 host. > > > Depending on the network and DNS configuration, it may be enough to > > simply configure the recursive DNS to not answer any AAAA queries (in > > the case where all DNS is forced to a set of managed servers). If DNS > > traffic is permitted from other hosts in the network, it may be > > necessary to examine all port 53 traffic and block AAAAs at the > > entrance to the network. It may even be appropriate to recommend > > something like sending resets to any attempts to establish connections > to IPv6 hosts. > > Isn't that of sending RSTs like getting into too many details? Or, do > you think I should add some text about this? [WEG] The only reason I mention it is that AFAIK it's deployed in an operat= ional network as a means to prevent IPv6 brokenness because while IPv6 is p= resent and in use, it's not actually connected to the IPv6 Internet. In a n= etwork where there is no IPv6 at all, it ends up being a "belt and suspende= rs" approach that catches the cases where an end host attempts to connect t= o an IPv6 host using an IPv6 literal instead of a DNS AAAA response. Do I t= hink those are particularly common? No, and I think that most times if you'= re trying to use an IPv6 literal, you'll know when it doesn't work that you= need to try IPv4. I just raised the issue for completeness, and I'd be int= erested in others feedback on whether it's important to include. > > > We have enough major destinations and > > applications IPv6-enabled that it's important to make it clear how bad > > of an idea it is to just break IPv6 under the assumption that no one > uses it yet anyway. > > For all the cases discussed in the document, hosts would not even get to > configure an IPv6 address. e.g., if you're filtering 6to4, it's because > you're not planning to send legitimate RAs on the local network. In the > same way, when we discuss filtering Teredo, the host doesnt get to > configure a Teredo address... [WEG] I'm not sure I understand your rationale here. There is nothing that = prevents an end host from configuring a 6to4 address (eg 2002::[foo]) and a= ttempting to send packets to the IPv4 6to4 anycast gateway. From the host's= perspective, that is a functional IPv6 connection. Only if the host has so= mething implemented to validate the connectivity before attempting to use i= t will it realize that it's faulty if/when the 6to4 packets are being filte= red upstream. Likewise, teredo has a little better behavior in that it is s= upposed to make checks for connectivity to the teredo server before assumin= g that it's functional. Similarly, a locally-defined 6in4 tunnel may not in= clude connectivity verification. While many implementations have either dep= referenced these technologies for all but forced IPv6 connections (attempts= to connect to a literal, for example), or have started using something lik= e Happy Eyeballs to detect brokenness and fall back to IPv4 quicker, not al= l have. The point is that there are many ways to implement broken IPv6 conn= ectivity with the use of these transition technologies, and filtering often= makes that brokenness more likely. > > > This document doesn't take a stance on whether you should deploy v6 or > not. There are too many details and factors behind such decision. The > document essentially argues "this v6 stuff is running on your network, > and you should make an explicit decision on what you want to do with > it". [WEG] I'm not proposing that this document get into the specific details an= d factors behind a decision to deploy IPv6. What I am proposing is that it = make the generic statement that absent a reason to the contrary, the path f= orward should be to deploy IPv6, rather than making it seem like this recom= mendation is a suitable indefinite solution for a network that doesn't tech= nically *need* to remain IPv4-only. > > > > I think the document should be stating up front that the primary > > recommendation for addressing the security considerations of > > unauthorized use of IPv6 in an IPv4-only network is to deploy IPv6 > > with proper security controls. > > I'm personally not sure whether it's possible for us to make such > recommendation, in the sense that for many networks, that's not an > option. People is going to deploy v6 if they need it -- not to mitigate > it's security implications. > > e.g., think about a network currently employing [put your favorite > security technologies/devices here] that currently do not support v6. > They are not going to buy new gear just to address these issues -- most > likely, they are going to employ packet filtering. [WEG] Yes, except that for the same reason, they may not be able to impleme= nt packet filtering for IPv6 traffic because their current [security widget= ] doesn't know what an IPv6 packet is. My view has always been that the rec= ommendation should be somewhat like the way that building codes read - if y= ou don't touch it, you aren't required to update things to comply with curr= ent building code, only the one in force when construction was done. But if= you tear open the wall, you have to bring anything that is exposed up to c= urrent building code. Unless the security person views IPv6 as a real threa= t enough to justify upgrading hardware to support proper IPv6 security cont= rols, the more likely thing is that it will just be ignored. If they're goi= ng to the trouble of purchasing hardware that supports IPv6 for filtering, = why not go the rest of the way? There may be legitimate reasons not to, but= that line of logic should be discussed here. > > Put another way, being an ops document, I'd personally like to keep it > as realistic as possible.... > > > This also could underscore the point that part of the reason why there > > may be tunneled IPv6 traffic or other transition technologies in use > > on the network is **because** there is no official IPv6 support and > > one or more of the users of the network have decided that IPv6 support > > is necessary enough to take matters into their own hands. > > Well, here we're providing advice to network/security administrators, > who are the ones expected to set the policy for their network. In these > cases, users do not "decide", but rather comply with the policy set by > the security/network admin. [WEG] now who's talking about keeping an ops document as realistic as possi= ble? ;-) Seriously, except in some of the most draconian of user environments (where= network security violations are a zero-tolerance termination offense and 1= 00% of devices on the network are centrally managed/locked down against una= uthorized changes or both), I think that it's unrealistic to assume that th= ere are no users "deciding" that the security/network admin's policy either= doesn't apply to them or is otherwise stupid and "deciding" to find a way = to circumvent it. This is the classic tussle between ensuring proper securi= ty and making it so onerous to the userbase that it is defeated so that the= y can get work done. If IPv6 traffic is detected on a network that does not have IPv6 deployed y= et, it's either a misconfigured host trying to do something automatically, = or it's a host purposely configured to attempt some sort of IPv6 connectivi= ty. There's value in discussing how to determine one vs the other, because = that may also lead to a course of action (e.g. push an update to disable th= e automatic/misconfiguration vs setting up filtering to prevent purposeful = attempts to force IPv6 traffic through). > > > > Reiterating a > > strong recommendation to deploy IPv6 to solve this problem also > > complements IETF's guidance in RFC6540 (IPv6 is no longer optional) > nicely. > > I personally think that that would be kind of out of the scope for this > document. However, I have no problem to go in that direction if wg > agrees to do do. [WEG] I'm not recommending it be a major focus. There are plenty of IPv6 ev= angelism drafts already. I'm mainly suggesting that it be discussed briefly= to round out the recommendations of the draft. > > My take is that this is an *op*sec document. And while "you should > deploy v6" sounds nice, for many networks that'd be unrealistic. [WEG] While I agree that it's unlikely that a security person reviewing thi= s document will have this sudden epiphany where they slap themselves on the= forehead and say "right, I should be deploying IPv6!" and run to convince = everyone else of this, I'm mainly looking for a consistent message when it = comes to getting away from the notion that IPv6 is going to remain optional= indefinitely for generic cases. There are exceptions to every rule, but th= e message we should be sending is that IPv6 is here, it's not going away, a= nd therefore you should be making a conscious decision to deploy or justify= delaying deployment based on your own circumstances, but the default answe= r should be deploy. That's why I made reference to 6540. > > (FWIW, we had a similar discussion at the last IETF meeting, where some > folks argued that the way to go to mitigate vpn leakages was to add v6 > support to the VPN software, but then it became clear that that was > easier said than done -- please take a look at the minutes) [WEG] I'll have a look, but at some point the "math is hard, let's go shopp= ing" [1] justification for delaying IPv6 deployment really stops being rele= vant, and I think we do a disservice to those reviewing documents like this= to make it seem like that's really an option to consider indefinitely. As = I said above, either the potential security risk presented by "rogue" IPv6 = deployments in the presence of software and hardware that doesn't fully sup= port them is big enough to justify spending time and money to fix it, or it= is a small enough risk to be safely ignored until the legacy software/hard= ware ages out on its own. Thanks Wes George [1] http://itre.cis.upenn.edu/~myl/languagelog/archives/002919.html This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From simoneng56@gmail.com Mon Dec 17 17:29:19 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAB821F84D3 for ; Mon, 17 Dec 2012 17:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7daJViPkVov for ; Mon, 17 Dec 2012 17:29:14 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4EF21F84CA for ; Mon, 17 Dec 2012 17:28:58 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id l22so90961vbn.14 for ; Mon, 17 Dec 2012 17:28:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=H44Hz1EO1/+LNhERaWLPKErKEegi9/1agM12ryFJdsY=; b=Jxx+EhI37vEEDb9cQw8g7LB7JNfcSpiZAV19Gb4KZPTQGIOVIMVLVc0h9J4b6+8jp3 I2cwZo1qdBOQWzyZaWciqFSVoByXYEqxAreZ5dffEI54Oq657kM+C9MIGQwXqO0UU5ll EHWl8Uhgb9aNQEMcBkq6+4cK3okeCOj0gCuY4c/vFK8Kg6eOXgb8JykCFX+XdKsKCIMr ISF7lo2Zuzt9ifAXhpo/9lDuYimHYJsW8b/y7B7ys8DhpjkFi6ppKu6c2h10/34SdKsl 97iwPWjaZ5RgPN+Ml3uJjZ6l2DShQKNFjmnztv9+RT7wfV7Ii2yJWJSo5q6RQUdGIlt7 65Qg== MIME-Version: 1.0 Received: by 10.221.2.11 with SMTP id ns11mr544802vcb.3.1355794138182; Mon, 17 Dec 2012 17:28:58 -0800 (PST) Received: by 10.58.186.170 with HTTP; Mon, 17 Dec 2012 17:28:58 -0800 (PST) In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230339D95F50@PRVPEXVS15.corp.twcable.com> References: <2671C6CDFBB59E47B64C10B3E0BD5923033907350D@PRVPEXVS15.corp.twcable.com> <50CF423D.3000503@si6networks.com> <2671C6CDFBB59E47B64C10B3E0BD59230339D95F50@PRVPEXVS15.corp.twcable.com> Date: Tue, 18 Dec 2012 09:28:58 +0800 Message-ID: From: Simon Eng To: opsec@ietf.org Content-Type: multipart/alternative; boundary=bcaec54ee7d8feb4a504d1166b0a Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 01:29:19 -0000 --bcaec54ee7d8feb4a504d1166b0a Content-Type: text/plain; charset=ISO-8859-1 Hi, If I am not wrong, the 3 key parts for draft-ietf-opsec-ipv6-implications-on-ipv4-nets-01 are: Section 1 Introduction/Problem Statement Section 2 Filtering Native IPv6 Section 3 Filtering Transition Hence, from Wes's suggestion, DNS filtering should be added (maybe Section 3??). Another scenario to consider for DNS is a malicious host on the IPv4 network acting as an IPv6 Router-cum-DNS64 => spoof DNS AAAA replies so that dual-stack hosts will route IPv6 traffic to malicious host => Man-In-Middle attack?? In Section 2, only DHCPv6 & RA are mentioned. I'd like to suggest filtering of ICMPv6 too. Regards. Simon On Tue, Dec 18, 2012 at 6:29 AM, George, Wes wrote: > > > From: Fernando Gont [mailto:fgont@si6networks.com] > > > > Filtering AAAA records at the organizational recursive DNS server? > > > > > [WEG] yes, to ensure that even if an end client thinks it has IPv6 > connectivity, and the network is actively working to filter/disable IPv6, > this will ensure that the client doesn't receive responses for AAAA queries > and attempt to connect to an IPv6 host. > > > > > > Depending on the network and DNS configuration, it may be enough to > > > simply configure the recursive DNS to not answer any AAAA queries (in > > > the case where all DNS is forced to a set of managed servers). If DNS > > > traffic is permitted from other hosts in the network, it may be > > > necessary to examine all port 53 traffic and block AAAAs at the > > > entrance to the network. It may even be appropriate to recommend > > > something like sending resets to any attempts to establish connections > > to IPv6 hosts. > > > > Isn't that of sending RSTs like getting into too many details? Or, do > > you think I should add some text about this? > [WEG] The only reason I mention it is that AFAIK it's deployed in an > operational network as a means to prevent IPv6 brokenness because while > IPv6 is present and in use, it's not actually connected to the IPv6 > Internet. In a network where there is no IPv6 at all, it ends up being a > "belt and suspenders" approach that catches the cases where an end host > attempts to connect to an IPv6 host using an IPv6 literal instead of a DNS > AAAA response. Do I think those are particularly common? No, and I think > that most times if you're trying to use an IPv6 literal, you'll know when > it doesn't work that you need to try IPv4. I just raised the issue for > completeness, and I'd be interested in others feedback on whether it's > important to include. > > > > > We have enough major destinations and > > > applications IPv6-enabled that it's important to make it clear how bad > > > of an idea it is to just break IPv6 under the assumption that no one > > uses it yet anyway. > > > > For all the cases discussed in the document, hosts would not even get to > > configure an IPv6 address. e.g., if you're filtering 6to4, it's because > > you're not planning to send legitimate RAs on the local network. In the > > same way, when we discuss filtering Teredo, the host doesnt get to > > configure a Teredo address... > [WEG] I'm not sure I understand your rationale here. There is nothing that > prevents an end host from configuring a 6to4 address (eg 2002::[foo]) and > attempting to send packets to the IPv4 6to4 anycast gateway. From the > host's perspective, that is a functional IPv6 connection. Only if the host > has something implemented to validate the connectivity before attempting to > use it will it realize that it's faulty if/when the 6to4 packets are being > filtered upstream. Likewise, teredo has a little better behavior in that it > is supposed to make checks for connectivity to the teredo server before > assuming that it's functional. Similarly, a locally-defined 6in4 tunnel may > not include connectivity verification. While many implementations have > either depreferenced these technologies for all but forced IPv6 connections > (attempts to connect to a literal, for example), or have started using > something like Happy Eyeballs to detect brokenness and fall back to IPv4 > quicker, not all have. The poi > nt is that there are many ways to implement broken IPv6 connectivity with > the use of these transition technologies, and filtering often makes that > brokenness more likely. > > > > > > This document doesn't take a stance on whether you should deploy v6 or > > not. There are too many details and factors behind such decision. The > > document essentially argues "this v6 stuff is running on your network, > > and you should make an explicit decision on what you want to do with > > it". > [WEG] I'm not proposing that this document get into the specific details > and factors behind a decision to deploy IPv6. What I am proposing is that > it make the generic statement that absent a reason to the contrary, the > path forward should be to deploy IPv6, rather than making it seem like this > recommendation is a suitable indefinite solution for a network that doesn't > technically *need* to remain IPv4-only. > > > > > > > I think the document should be stating up front that the primary > > > recommendation for addressing the security considerations of > > > unauthorized use of IPv6 in an IPv4-only network is to deploy IPv6 > > > with proper security controls. > > > > I'm personally not sure whether it's possible for us to make such > > recommendation, in the sense that for many networks, that's not an > > option. People is going to deploy v6 if they need it -- not to mitigate > > it's security implications. > > > > e.g., think about a network currently employing [put your favorite > > security technologies/devices here] that currently do not support v6. > > They are not going to buy new gear just to address these issues -- most > > likely, they are going to employ packet filtering. > > [WEG] Yes, except that for the same reason, they may not be able to > implement packet filtering for IPv6 traffic because their current [security > widget] doesn't know what an IPv6 packet is. My view has always been that > the recommendation should be somewhat like the way that building codes read > - if you don't touch it, you aren't required to update things to comply > with current building code, only the one in force when construction was > done. But if you tear open the wall, you have to bring anything that is > exposed up to current building code. Unless the security person views IPv6 > as a real threat enough to justify upgrading hardware to support proper > IPv6 security controls, the more likely thing is that it will just be > ignored. If they're going to the trouble of purchasing hardware that > supports IPv6 for filtering, why not go the rest of the way? There may be > legitimate reasons not to, but that line of logic should be discussed here. > > > > Put another way, being an ops document, I'd personally like to keep it > > as realistic as possible.... > > > > > This also could underscore the point that part of the reason why there > > > may be tunneled IPv6 traffic or other transition technologies in use > > > on the network is **because** there is no official IPv6 support and > > > one or more of the users of the network have decided that IPv6 support > > > is necessary enough to take matters into their own hands. > > > > Well, here we're providing advice to network/security administrators, > > who are the ones expected to set the policy for their network. In these > > cases, users do not "decide", but rather comply with the policy set by > > the security/network admin. > [WEG] now who's talking about keeping an ops document as realistic as > possible? ;-) > Seriously, except in some of the most draconian of user environments > (where network security violations are a zero-tolerance termination offense > and 100% of devices on the network are centrally managed/locked down > against unauthorized changes or both), I think that it's unrealistic to > assume that there are no users "deciding" that the security/network admin's > policy either doesn't apply to them or is otherwise stupid and "deciding" > to find a way to circumvent it. This is the classic tussle between ensuring > proper security and making it so onerous to the userbase that it is > defeated so that they can get work done. > If IPv6 traffic is detected on a network that does not have IPv6 deployed > yet, it's either a misconfigured host trying to do something automatically, > or it's a host purposely configured to attempt some sort of IPv6 > connectivity. There's value in discussing how to determine one vs the > other, because that may also lead to a course of action (e.g. push an > update to disable the automatic/misconfiguration vs setting up filtering to > prevent purposeful attempts to force IPv6 traffic through). > > > > > > > Reiterating a > > > strong recommendation to deploy IPv6 to solve this problem also > > > complements IETF's guidance in RFC6540 (IPv6 is no longer optional) > > nicely. > > > > I personally think that that would be kind of out of the scope for this > > document. However, I have no problem to go in that direction if wg > > agrees to do do. > [WEG] I'm not recommending it be a major focus. There are plenty of IPv6 > evangelism drafts already. I'm mainly suggesting that it be discussed > briefly to round out the recommendations of the draft. > > > > My take is that this is an *op*sec document. And while "you should > > deploy v6" sounds nice, for many networks that'd be unrealistic. > [WEG] While I agree that it's unlikely that a security person reviewing > this document will have this sudden epiphany where they slap themselves on > the forehead and say "right, I should be deploying IPv6!" and run to > convince everyone else of this, I'm mainly looking for a consistent message > when it comes to getting away from the notion that IPv6 is going to remain > optional indefinitely for generic cases. There are exceptions to every > rule, but the message we should be sending is that IPv6 is here, it's not > going away, and therefore you should be making a conscious decision to > deploy or justify delaying deployment based on your own circumstances, but > the default answer should be deploy. That's why I made reference to 6540. > > > > (FWIW, we had a similar discussion at the last IETF meeting, where some > > folks argued that the way to go to mitigate vpn leakages was to add v6 > > support to the VPN software, but then it became clear that that was > > easier said than done -- please take a look at the minutes) > [WEG] I'll have a look, but at some point the "math is hard, let's go > shopping" [1] justification for delaying IPv6 deployment really stops being > relevant, and I think we do a disservice to those reviewing documents like > this to make it seem like that's really an option to consider indefinitely. > As I said above, either the potential security risk presented by "rogue" > IPv6 deployments in the presence of software and hardware that doesn't > fully support them is big enough to justify spending time and money to fix > it, or it is a small enough risk to be safely ignored until the legacy > software/hardware ages out on its own. > > Thanks > Wes George > > [1] http://itre.cis.upenn.edu/~myl/languagelog/archives/002919.html > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified that > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > --bcaec54ee7d8feb4a504d1166b0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

If I am not wrong, the 3 key parts for draft-ietf-op= sec-ipv6-implications-on-ipv4-nets-01 are:

Section= 1 =A0Introduction/Problem Statement
Section 2 =A0Filtering Nativ= e IPv6
Section 3 =A0Filtering Transition

Hence, from= Wes's suggestion, DNS filtering should be added (maybe Section 3??). = =A0Another scenario to consider for DNS is a malicious host on the IPv4 net= work acting as an IPv6 Router-cum-DNS64 =3D> spoof DNS AAAA replies so t= hat dual-stack hosts will route IPv6 traffic to malicious host =3D> Man-= In-Middle attack??

In Section 2, only DHCPv6 & RA are mentioned. =A0I&= #39;d like to suggest filtering of ICMPv6 too.

Reg= ards.

Simon


On Tue, Dec 18, 2012 at 6:29 AM, George, Wes <wesley.george@twcab= le.com> wrote:

> From: Fernando Gont [mailto:f= gont@si6networks.com]
>
> Filtering AAAA records at the organizational recursive DNS server?
>
>
[WEG] yes, to ensure that even if an end client thinks it has IPv6 co= nnectivity, and the network is actively working to filter/disable IPv6, thi= s will ensure that the client doesn't receive responses for AAAA querie= s and attempt to connect to an IPv6 host.

>
> > Depending on the network and DNS configuration, it may be enough = to
> > simply configure the recursive DNS to not answer any AAAA queries= (in
> > the case where all DNS is forced to a set of managed servers). If= DNS
> > traffic is permitted from other hosts in the network, it may be > > necessary to examine all port 53 traffic and block AAAAs at the > > entrance to the network. It may even be appropriate to recommend<= br> > > something like sending resets to any attempts to establish connec= tions
> to IPv6 hosts.
>
> Isn't that of sending RSTs like getting into too many details? Or,= do
> you think I should add some text about this?
[WEG] The only reason I mention it is that AFAIK it's deployed in= an operational network as a means to prevent IPv6 brokenness because while= IPv6 is present and in use, it's not actually connected to the IPv6 In= ternet. In a network where there is no IPv6 at all, it ends up being a &quo= t;belt and suspenders" approach that catches the cases where an end ho= st attempts to connect to an IPv6 host using an IPv6 literal instead of a D= NS AAAA response. Do I think those are particularly common? No, and I think= that most times if you're trying to use an IPv6 literal, you'll kn= ow when it doesn't work that you need to try IPv4. I just raised the is= sue for completeness, and I'd be interested in others feedback on wheth= er it's important to include.
>
> > We have enough major destinations and
> > applications IPv6-enabled that it's important to make it clea= r how bad
> > of an idea it is to just break IPv6 under the assumption that no = one
> uses it yet anyway.
>
> For all the cases discussed in the document, hosts would not even get = to
> configure an IPv6 address. e.g., if you're filtering 6to4, it'= s because
> you're not planning to send legitimate RAs on the local network. I= n the
> same way, when we discuss filtering Teredo, the host doesnt get to
> configure a Teredo address...
[WEG] I'm not sure I understand your rationale here. There is not= hing that prevents an end host from configuring a 6to4 address (eg 2002::[f= oo]) and attempting to send packets to the IPv4 6to4 anycast gateway. From = the host's perspective, that is a functional IPv6 connection. Only if t= he host has something implemented to validate the connectivity before attem= pting to use it will it realize that it's faulty if/when the 6to4 packe= ts are being filtered upstream. Likewise, teredo has a little better behavi= or in that it is supposed to make checks for connectivity to the teredo ser= ver before assuming that it's functional. Similarly, a locally-defined = 6in4 tunnel may not include connectivity verification. While many implement= ations have either depreferenced these technologies for all but forced IPv6= connections (attempts to connect to a literal, for example), or have start= ed using something like Happy Eyeballs to detect brokenness and fall back t= o IPv4 quicker, not all have. The poi
=A0nt is that there are many ways to implement broken IPv6 connectivity wit= h the use of these transition technologies, and filtering often makes that = brokenness more likely.
>
>
> This document doesn't take a stance on whether you should deploy v= 6 or
> not. There are too many details and factors behind such decision. The<= br> > document essentially argues "this v6 stuff is running on your net= work,
> and you should make an explicit decision on what you want to do with > it".
[WEG] I'm not proposing that this document get into the specific = details and factors behind a decision to deploy IPv6. What I am proposing i= s that it make the generic statement that absent a reason to the contrary, = the path forward should be to deploy IPv6, rather than making it seem like = this recommendation is a suitable indefinite solution for a network that do= esn't technically *need* to remain IPv4-only.
>
>
> > I think the document should be stating up front that the primary<= br> > > recommendation for addressing the security considerations of
> > unauthorized use of IPv6 in an IPv4-only network is to deploy IPv= 6
> > with proper security controls.
>
> I'm personally not sure whether it's possible for us to make s= uch
> recommendation, in the sense that for many networks, that's not an=
> option. People is going to deploy v6 if they need it -- not to mitigat= e
> it's security implications.
>
> e.g., think about a network currently employing [put your favorite
> security technologies/devices here] that currently do not support v6.<= br> > They are not going to buy new gear just to address these issues -- mos= t
> likely, they are going to employ packet filtering.

[WEG] Yes, except that for the same reason, they may not be able to i= mplement packet filtering for IPv6 traffic because their current [security = widget] doesn't know what an IPv6 packet is. My view has always been th= at the recommendation should be somewhat like the way that building codes r= ead - if you don't touch it, you aren't required to update things t= o comply with current building code, only the one in force when constructio= n was done. But if you tear open the wall, you have to bring anything that = is exposed up to current building code. Unless the security person views IP= v6 as a real threat enough to justify upgrading hardware to support proper = IPv6 security controls, the more likely thing is that it will just be ignor= ed. If they're going to the trouble of purchasing hardware that support= s IPv6 for filtering, why not go the rest of the way? There may be legitima= te reasons not to, but that line of logic should be discussed here.
>
> Put another way, being an ops document, I'd personally like to kee= p it
> as realistic as possible....
>
> > This also could underscore the point that= part of the reason why there
> > may be tunneled IPv6 traffic or other transition technologies in = use
> > on the network is **because** there is no official IPv6 support a= nd
> > one or more of the users of the network have decided that IPv6 su= pport
> > is necessary enough to take matters into their own hands.
>
> Well, here we're providing advice to network/security administrato= rs,
> who are the ones expected to set the policy for their network. In thes= e
> cases, users do not "decide", but rather comply with the pol= icy set by
> the security/network admin.
[WEG] now who's talking about keeping an ops document as realisti= c as possible? ;-)
Seriously, except in some of the most draconian of user environments (where= network security violations are a zero-tolerance termination offense and 1= 00% of devices on the network are centrally managed/locked down against una= uthorized changes or both), I think that it's unrealistic to assume tha= t there are no users "deciding" that the security/network admin&#= 39;s policy either doesn't apply to them or is otherwise stupid and &qu= ot;deciding" to find a way to circumvent it. This is the classic tussl= e between ensuring proper security and making it so onerous to the userbase= that it is defeated so that they can get work done.
If IPv6 traffic is detected on a network that does not have IPv6 deployed y= et, it's either a misconfigured host trying to do something automatical= ly, or it's a host purposely configured to attempt some sort of IPv6 co= nnectivity. There's value in discussing how to determine one vs the oth= er, because that may also lead to a course of action (e.g. push an update t= o disable the automatic/misconfiguration vs setting up filtering to prevent= purposeful attempts to force IPv6 traffic through).
>
>
> > Reiterating a
> > strong recommendation to deploy IPv6 to solve this problem also > > complements IETF's guidance in RFC6540 (IPv6 is no longer opt= ional)
> nicely.
>
> I personally think that that would be kind of out of the scope for thi= s
> document. However, I have no problem to go in that direction if wg
> agrees to do do.
[WEG] I'm not recommending it be a major focus. There are plenty = of IPv6 evangelism drafts already. I'm mainly suggesting that it be dis= cussed briefly to round out the recommendations of the draft.
>
> My take is that this is an *op*sec document. And while "you shoul= d
> deploy v6" sounds nice, for many networks that'd be unrealist= ic.
[WEG] While I agree that it's unlikely that a security person rev= iewing this document will have this sudden epiphany where they slap themsel= ves on the forehead and say "right, I should be deploying IPv6!" = and run to convince everyone else of this, I'm mainly looking for a con= sistent message when it comes to getting away from the notion that IPv6 is = going to remain optional indefinitely for generic cases. There are exceptio= ns to every rule, but the message we should be sending is that IPv6 is here= , it's not going away, and therefore you should be making a conscious d= ecision to deploy or justify delaying deployment based on your own circumst= ances, but the default answer should be deploy. That's why I made refer= ence to 6540.
>
> (FWIW, we had a similar discussion at the last IETF meeting, where som= e
> folks argued that the way to go to mitigate vpn leakages was to add v6=
> support to the VPN software, but then it became clear that that was > easier said than done -- please take a look at the minutes)
[WEG] I'll have a look, but at some point the "math is hard,= let's go shopping" [1] justification for delaying IPv6 deployment= really stops being relevant, and I think we do a disservice to those revie= wing documents like this to make it seem like that's really an option t= o consider indefinitely. As I said above, either the potential security ris= k presented by "rogue" IPv6 deployments in the presence of softwa= re and hardware that doesn't fully support them is big enough to justif= y spending time and money to fix it, or it is a small enough risk to be saf= ely ignored until the legacy software/hardware ages out on its own.

Thanks
Wes George

[1] http://itre.cis.upenn.edu/~myl/languagelog/archives/= 002919.html

This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.
_____________________________= __________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec

--bcaec54ee7d8feb4a504d1166b0a-- From fgont@si6networks.com Mon Dec 17 18:51:30 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAE621E804D for ; Mon, 17 Dec 2012 18:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFikF9g-Bz-M for ; Mon, 17 Dec 2012 18:51:29 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id D9E9D21E804C for ; Mon, 17 Dec 2012 18:51:28 -0800 (PST) Received: from [186.134.26.57] (helo=[192.168.123.126]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TknH3-00022J-Ql; Tue, 18 Dec 2012 03:51:18 +0100 Message-ID: <50CFDA1E.30408@si6networks.com> Date: Mon, 17 Dec 2012 23:51:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "George, Wes" References: <2671C6CDFBB59E47B64C10B3E0BD5923033907350D@PRVPEXVS15.corp.twcable.com> <50CF423D.3000503@si6networks.com> <2671C6CDFBB59E47B64C10B3E0BD59230339D95F50@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230339D95F50@PRVPEXVS15.corp.twcable.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" , "draft-ietf-opsec-ipv6-implications-on-ipv4-nets@tools.ietf.org" Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 02:51:30 -0000 On 12/17/2012 07:29 PM, George, Wes wrote: >> Filtering AAAA records at the organizational recursive DNS server? >> > [WEG] yes, to ensure that even if an end client thinks it has IPv6 > connectivity, and the network is actively working to filter/disable > IPv6, this will ensure that the client doesn't receive responses for > AAAA queries and attempt to connect to an IPv6 host. Should I include some text in the Intro (only), or should I include a note in each of the filtering sections ("If you filter these packets, you should probably also filter the corresponding AAAA records"). >>> Depending on the network and DNS configuration, it may be enough >>> to simply configure the recursive DNS to not answer any AAAA >>> queries (in the case where all DNS is forced to a set of managed >>> servers). If DNS traffic is permitted from other hosts in the >>> network, it may be necessary to examine all port 53 traffic and >>> block AAAAs at the entrance to the network. It may even be >>> appropriate to recommend something like sending resets to any >>> attempts to establish connections >> to IPv6 hosts. >> >> Isn't that of sending RSTs like getting into too many details? Or, >> do you think I should add some text about this? > [WEG] The only reason I mention it is that AFAIK it's deployed in an > operational network as a means to prevent IPv6 brokenness because > while IPv6 is present and in use, it's not actually connected to the > IPv6 Internet. In a network where there is no IPv6 at all, it ends up > being a "belt and suspenders" approach that catches the cases where > an end host attempts to connect to an IPv6 host using an IPv6 literal > instead of a DNS AAAA response. Do I think those are particularly > common? No, and I think that most times if you're trying to use an > IPv6 literal, you'll know when it doesn't work that you need to try > IPv4. I just raised the issue for completeness, and I'd be interested > in others feedback on whether it's important to include. It might make sense to add a note about this - although I recall that at least some version of Windows would keep resending the SYN even in the presence of an RST. -- i.e., the RST would not cause Windows to try "the next address in the list" - this might have changed nowadays, though. >>> We have enough major destinations and applications IPv6-enabled >>> that it's important to make it clear how bad of an idea it is to >>> just break IPv6 under the assumption that no one >> uses it yet anyway. >> >> For all the cases discussed in the document, hosts would not even >> get to configure an IPv6 address. e.g., if you're filtering 6to4, >> it's because you're not planning to send legitimate RAs on the >> local network. In the same way, when we discuss filtering Teredo, >> the host doesnt get to configure a Teredo address... > [WEG] I'm not sure I understand your rationale here. There is nothing > that prevents an end host from configuring a 6to4 address (eg > 2002::[foo]) and attempting to send packets to the IPv4 6to4 anycast > gateway. You're right -- I should have said "in all cases, modulo, 6to4...." > that it's functional. Similarly, a locally-defined 6in4 tunnel may > not include connectivity verification. While many implementations IMO, 6in4 is less of an issue, since it's manually configured. At which point, you're assumed to know what you're doing.... > have either depreferenced these technologies for all but forced IPv6 > connections (attempts to connect to a literal, for example), or have > started using something like Happy Eyeballs to detect brokenness and > fall back to IPv4 quicker, not all have. The point is that there are > many ways to implement broken IPv6 connectivity with the use of these > transition technologies, and filtering often makes that brokenness > more likely. I think you've raised a valid point. Please do let me know where (which sections) you think should include some words on the subject... and I'll come back with a proposed next-rev. >> This document doesn't take a stance on whether you should deploy v6 >> or not. There are too many details and factors behind such >> decision. The document essentially argues "this v6 stuff is running >> on your network, and you should make an explicit decision on what >> you want to do with it". > [WEG] I'm not proposing that this document get into the specific > details and factors behind a decision to deploy IPv6. What I am > proposing is that it make the generic statement that absent a reason > to the contrary, the path forward should be to deploy IPv6, rather > than making it seem like this recommendation is a suitable indefinite > solution for a network that doesn't technically *need* to remain > IPv4-only. Me, I never thought about filtering about an "indefinite solution". As noted in my previous email, my take is that networks will address these issues by "enforcing IPv6 security controls" only if they have already deployed v6 for some *other* reason. I don't think anyone would deploy v6 just for this. >>> I think the document should be stating up front that the primary >>> recommendation for addressing the security considerations of >>> unauthorized use of IPv6 in an IPv4-only network is to deploy >>> IPv6 with proper security controls. >> >> I'm personally not sure whether it's possible for us to make such >> recommendation, in the sense that for many networks, that's not an >> option. People is going to deploy v6 if they need it -- not to >> mitigate it's security implications. >> >> e.g., think about a network currently employing [put your favorite >> security technologies/devices here] that currently do not support >> v6. They are not going to buy new gear just to address these issues >> -- most likely, they are going to employ packet filtering. > > [WEG] Yes, except that for the same reason, they may not be able to > implement packet filtering for IPv6 traffic because their current > [security widget] doesn't know what an IPv6 packet is. Well, for all these cases, the filtering happens in v4, rather than v6 -- e.g., filter ip proto 41, or the Teredo IPv4-based UDP ports, etc. > code. Unless the security person views IPv6 as a real threat enough > to justify upgrading hardware to support proper IPv6 security > controls, the more likely thing is that it will just be ignored. If > they're going to the trouble of purchasing hardware that supports > IPv6 for filtering, why not go the rest of the way? Please see above. In all these cases, the filtering happens in v4, and not in v6. >>> This also could underscore the point that part of the reason why >>> there may be tunneled IPv6 traffic or other transition >>> technologies in use on the network is **because** there is no >>> official IPv6 support and one or more of the users of the network >>> have decided that IPv6 support is necessary enough to take >>> matters into their own hands. >> >> Well, here we're providing advice to network/security >> administrators, who are the ones expected to set the policy for >> their network. In these cases, users do not "decide", but rather >> comply with the policy set by the security/network admin. > [WEG] now who's talking about keeping an ops document as realistic as > possible? ;-) Seriously, except in some of the most draconian of user > environments (where network security violations are a zero-tolerance > termination offense and 100% of devices on the network are centrally > managed/locked down against unauthorized changes or both), I think > that it's unrealistic to assume that there are no users "deciding" > that the security/network admin's policy either doesn't apply to them > or is otherwise stupid and "deciding" to find a way to circumvent it. >From the security admin pov, that's an attack -- hence the admin doesn't need to allow such traffic. > This is the classic tussle between ensuring proper security and > making it so onerous to the userbase that it is defeated so that they > can get work done. If IPv6 traffic is detected on a network that does > not have IPv6 deployed yet, it's either a misconfigured host trying > to do something automatically, or it's a host purposely configured to > attempt some sort of IPv6 connectivity. If you're enforcing v4 controls in your network, but do not enforce any v6 controls, you probably don't want the v6 traffic there... >>> Reiterating a strong recommendation to deploy IPv6 to solve this >>> problem also complements IETF's guidance in RFC6540 (IPv6 is no >>> longer optional) >> nicely. >> >> I personally think that that would be kind of out of the scope for >> this document. However, I have no problem to go in that direction >> if wg agrees to do do. > [WEG] I'm not recommending it be a major focus. There are plenty of > IPv6 evangelism drafts already. I'm mainly suggesting that it be > discussed briefly to round out the recommendations of the draft. I'd like others to weigh in. Me, I just want to avoid v6-evangelism here.... >> My take is that this is an *op*sec document. And while "you should >> deploy v6" sounds nice, for many networks that'd be unrealistic. > [WEG] While I agree that it's unlikely that a security person > reviewing this document will have this sudden epiphany where they > slap themselves on the forehead and say "right, I should be deploying > IPv6!" and run to convince everyone else of this, I'm mainly looking > for a consistent message when it comes to getting away from the > notion that IPv6 is going to remain optional indefinitely for generic > cases. I don't necessarily see v6 as "optional" -- and I certainly do not see as optional in the future. That said when faced with these security implications, you've already deployed v6 (and should therefore enforce v6 security controls), or you're probably going to go the packet-filtering way. My take is that the decision about whether to deploy v6 is (and should) happen as a result of something else, and not just to address these issues. >> (FWIW, we had a similar discussion at the last IETF meeting, where >> some folks argued that the way to go to mitigate vpn leakages was >> to add v6 support to the VPN software, but then it became clear >> that that was easier said than done -- please take a look at the >> minutes) > [WEG] I'll have a look, but at some point the "math is hard, let's go > shopping" [1] justification for delaying IPv6 deployment really stops > being relevant, and I think we do a disservice to those reviewing > documents like this to make it seem like that's really an option to > consider indefinitely. Is there anything (in particular) that gives you such idea? -- I ask because that's not my idea, and not what I wanted to reflect in the document. > As I said above, either the potential security > risk presented by "rogue" IPv6 deployments in the presence of > software and hardware that doesn't fully support them is big enough > to justify spending time and money to fix it, or it is a small enough > risk to be safely ignored until the legacy software/hardware ages out > on its own. Well, it doesn't need to be "black or white". As noted above, simple v4-based packet filtering can mitigate many of these issues... Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Mon Dec 17 18:56:49 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1953621E804C for ; Mon, 17 Dec 2012 18:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWFHxZoANow0 for ; Mon, 17 Dec 2012 18:56:48 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 25CFB21E8040 for ; Mon, 17 Dec 2012 18:56:48 -0800 (PST) Received: from [186.134.26.57] (helo=[192.168.123.126]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TknMJ-00029w-OK; Tue, 18 Dec 2012 03:56:44 +0100 Message-ID: <50CFDB65.7010406@si6networks.com> Date: Mon, 17 Dec 2012 23:56:37 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Simon Eng References: <2671C6CDFBB59E47B64C10B3E0BD5923033907350D@PRVPEXVS15.corp.twcable.com> <50CF423D.3000503@si6networks.com> <2671C6CDFBB59E47B64C10B3E0BD59230339D95F50@PRVPEXVS15.corp.twcable.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 02:56:49 -0000 Hi, Simon, Thanks so much for your feedback! Please find my comments inline.... On 12/17/2012 10:28 PM, Simon Eng wrote: > Hi, > > If I am not wrong, the 3 key parts for > draft-ietf-opsec-ipv6-implications-on-ipv4-nets-01 are: > > Section 1 Introduction/Problem Statement > Section 2 Filtering Native IPv6 > Section 3 Filtering Transition > > Hence, from Wes's suggestion, DNS filtering should be added (maybe > Section 3??). Wes's suggestions seems to be to do DNS AAAA filtering *when* you do native/transition traffic filtering... > Another scenario to consider for DNS is a malicious host > on the IPv4 network acting as an IPv6 Router-cum-DNS64 => spoof DNS AAAA > replies so that dual-stack hosts will route IPv6 traffic to malicious > host => Man-In-Middle attack?? Yep. This should probaly be added to the intro -- if it's not already there.... > In Section 2, only DHCPv6 & RA are mentioned. I'd like to suggest > filtering of ICMPv6 too. You mean ICMPv6 errors, or what? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From simoneng56@gmail.com Mon Dec 17 19:44:37 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD0C21F85D8 for ; Mon, 17 Dec 2012 19:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQcZU9Fa3eTd for ; Mon, 17 Dec 2012 19:44:36 -0800 (PST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4805A21F85D3 for ; Mon, 17 Dec 2012 19:44:35 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id fr13so221988vbb.23 for ; Mon, 17 Dec 2012 19:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=H/AjfGpf/3G6HLFpUI29evRMZO8lJ5yPE+tbwPEDNNs=; b=JdgNIRe9x0y1hs2ZkrK07d7OT/2qMDAUxE5pK8D/A1sxz9RFm7pSEkQ1k+szGbs8cj xWkRlHstnIE2Erx4LFLHE1lt83TuKf9oSwBwrdOBd3P+O3NwArBIHRvEEjxYuJmiAHML 3HiP5bvvpNQNe057GkdtDyA9COM00kAuI0AGhzvcswWzigs/beGZYAlr4MwNWQJWpnMr u0C/hJVFjB1/znSdS9DU4Y+1b4+cG2AufW5IO/3swUGst62vtvLCAT6tN5vkuBFiIgPe 43VLAp53PmkpjtzNzKXMgX6oYAH1UYA8UMApcXSNIlzJfKwXdCZowXIAZQOLg9PUbiZr HkDA== MIME-Version: 1.0 Received: by 10.220.205.198 with SMTP id fr6mr788260vcb.63.1355802275359; Mon, 17 Dec 2012 19:44:35 -0800 (PST) Received: by 10.58.186.170 with HTTP; Mon, 17 Dec 2012 19:44:35 -0800 (PST) In-Reply-To: <50CFDB65.7010406@si6networks.com> References: <2671C6CDFBB59E47B64C10B3E0BD5923033907350D@PRVPEXVS15.corp.twcable.com> <50CF423D.3000503@si6networks.com> <2671C6CDFBB59E47B64C10B3E0BD59230339D95F50@PRVPEXVS15.corp.twcable.com> <50CFDB65.7010406@si6networks.com> Date: Tue, 18 Dec 2012 11:44:35 +0800 Message-ID: From: Simon Eng To: Fernando Gont , opsec@ietf.org Content-Type: multipart/alternative; boundary=14dae9cdc529022d7c04d1185118 Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 03:44:37 -0000 --14dae9cdc529022d7c04d1185118 Content-Type: text/plain; charset=ISO-8859-1 Hi, Pls see my comments as below: a) Yes, maybe DNS AAAA filtering can be mentioned in a separate new section. b) No, I do not mean ICMPv6 errors only, but all ICMPv6 messages (which should not be there in IPv4-only network right??). So a Network IDS/IPS can filter/block ICMPv6 traffic (similar to RA guard, detect-block DHCPv6, etc). I am not sure if this works. But suppose a malicious host knows a Dual Stack Host MAC address via ARP, can it uses ICMPv6 Neigh Solicit/Discovery to trick Dual Stack Host to connect/route IPv6 packets to it, which in turn can do a NAT64 send out to outside world? [Dual stack]<--IPv6-->[Malicious Host doing NAT64, DNS64, etc]<--IPv4-->[IPv4 only router]<-->(Outside world) If I am not wrong, most IETF suggestions are to try IPv6 first, then fall back to IPv4 (e.g. behaviour of DNS64?? Try AAAA then A??). Hence, in IPv4 only network, ICMPv6 (using ARP info) can be used for Man-In-Middle?? On Tue, Dec 18, 2012 at 10:56 AM, Fernando Gont wrote: > Hi, Simon, > > Thanks so much for your feedback! Please find my comments inline.... > > On 12/17/2012 10:28 PM, Simon Eng wrote: > > Hi, > > > > If I am not wrong, the 3 key parts for > > draft-ietf-opsec-ipv6-implications-on-ipv4-nets-01 are: > > > > Section 1 Introduction/Problem Statement > > Section 2 Filtering Native IPv6 > > Section 3 Filtering Transition > > > > Hence, from Wes's suggestion, DNS filtering should be added (maybe > > Section 3??). > > Wes's suggestions seems to be to do DNS AAAA filtering *when* you do > native/transition traffic filtering... > > > > > Another scenario to consider for DNS is a malicious host > > on the IPv4 network acting as an IPv6 Router-cum-DNS64 => spoof DNS AAAA > > replies so that dual-stack hosts will route IPv6 traffic to malicious > > host => Man-In-Middle attack?? > > Yep. This should probaly be added to the intro -- if it's not already > there.... > > > > > In Section 2, only DHCPv6 & RA are mentioned. I'd like to suggest > > filtering of ICMPv6 too. > > You mean ICMPv6 errors, or what? > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --14dae9cdc529022d7c04d1185118 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Pls see my comments as below:

a)=A0=A0Yes, maybe=A0DNS AAAA filtering can be mentioned in a separate n= ew section.

b) No, I do not mean ICMPv6 errors onl= y, but all ICMPv6 messages (which should not be there in IPv4-only network = right??). =A0So a Network IDS/IPS can filter/block ICMPv6 traffic (similar = to RA guard, detect-block DHCPv6, etc).

I am not sure if this works. But suppose a malicious ho= st knows a Dual Stack Host MAC address via ARP, can it uses ICMPv6 Neigh So= licit/Discovery to trick Dual Stack Host to connect/route IPv6 packets to i= t, which in turn can do a NAT64 send out to outside world? =A0

[Dual stack]<--IPv6-->[Malicious Host doing NAT64= , DNS64, etc]<--IPv4-->[IPv4 only router]<-->(Outside world)

If I am not wrong, most IETF suggestions are to try = IPv6 first, then fall back to IPv4 (e.g. behaviour of DNS64?? Try AAAA then= A??). =A0Hence, in IPv4 only network, ICMPv6 (using ARP info) can be used = for Man-In-Middle??=A0

On Tue, Dec 18, 2012 at 10:56 AM, Fernando G= ont <fgont@si6networks.com> wrote:
Hi, Simon,

Thanks so much for your feedback! Please find my comments inline....

On 12/17/2012 10:28 PM, Simon Eng wrote:
> Hi,
>
> If I am not wrong, the 3 key parts for
> draft-ietf-opsec-ipv6-implications-on-ipv4-nets-01 are:
>
> Section 1 =A0Introduction/Problem Statement
> Section 2 =A0Filtering Native IPv6
> Section 3 =A0Filtering Transition
>
> Hence, from Wes's suggestion, DNS filtering should be added (maybe=
> Section 3??).

Wes's suggestions seems to be to do DNS AAAA filtering *when* you= do
native/transition traffic filtering...



> Another scenario to consider for DNS is a malicious host
> on the IPv4 network acting as an IPv6 Router-cum-DNS64 =3D> spoof D= NS AAAA
> replies so that dual-stack hosts will route IPv6 traffic to malicious<= br> > host =3D> Man-In-Middle attack??

Yep. This should probaly be added to the intro -- if it's not alr= eady
there....



> In Section 2, only DHCPv6 & RA are mentioned. =A0I'd like to s= uggest
> filtering of ICMPv6 too.

You mean ICMPv6 errors, or what?

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--14dae9cdc529022d7c04d1185118-- From fgont@si6networks.com Tue Dec 18 04:36:14 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C812D21F8895 for ; Tue, 18 Dec 2012 04:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO5dDaCw2tRj for ; Tue, 18 Dec 2012 04:36:14 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 466E521F8897 for ; Tue, 18 Dec 2012 04:36:13 -0800 (PST) Received: from 187-135-17-190.fibertel.com.ar ([190.17.135.187] helo=[192.168.123.124]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TkwOg-0007Nu-CW; Tue, 18 Dec 2012 13:35:47 +0100 Message-ID: <50D01471.6060308@si6networks.com> Date: Tue, 18 Dec 2012 04:00:01 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Simon Eng References: <2671C6CDFBB59E47B64C10B3E0BD5923033907350D@PRVPEXVS15.corp.twcable.com> <50CF423D.3000503@si6networks.com> <2671C6CDFBB59E47B64C10B3E0BD59230339D95F50@PRVPEXVS15.corp.twcable.com> <50CFDB65.7010406@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 12:36:14 -0000 Hi, Simon, On 12/18/2012 12:44 AM, Simon Eng wrote: > a) Yes, maybe DNS AAAA filtering can be mentioned in a separate new > section. My take is that this kind of filtering is meant t complement the kind of filtering already discussed in the document. In such case, the corresponding text shuld be added to some of the existing section(s). > b) No, I do not mean ICMPv6 errors only, but all ICMPv6 messages (which > should not be there in IPv4-only network right??). So a Network IDS/IPS > can filter/block ICMPv6 traffic (similar to RA guard, detect-block > DHCPv6, etc). The discussion of RA-Guard and DHCPv6-Shield is meant to prevent an attacker from successfully triggerring v6-conectivity at the target hosts, and is a layer-2 filtering. For other packets, you proaby simply ant to filter IPv6 packets , with such a coarse granularity. > I am not sure if this works. But suppose a malicious host knows a Dual > Stack Host MAC address via ARP, can it uses ICMPv6 Neigh > Solicit/Discovery to trick Dual Stack Host to connect/route IPv6 packets > to it, which in turn can do a NAT64 send out to outside world? Except for linklocl traffi, this shoudl be performed in conjunction with other attacks 7e.g., forging RAs). > If I am not wrong, most IETF suggestions are to try IPv6 first, then > fall back to IPv4 (e.g. behaviour of DNS64?? Try AAAA then A??). Hence, > in IPv4 only network, ICMPv6 (using ARP info) can be used for > Man-In-Middle?? Yes. Although that implies you already have some v6 connectivity. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From wesley.george@twcable.com Tue Dec 18 10:44:02 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE8121F8ABB for ; Tue, 18 Dec 2012 10:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX4FCRYRH1Y1 for ; Tue, 18 Dec 2012 10:44:01 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9739021F8A9C for ; Tue, 18 Dec 2012 10:44:01 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,310,1355115600"; d="scan'208";a="211326" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 18 Dec 2012 13:44:00 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 18 Dec 2012 13:43:59 -0500 From: "George, Wes" To: Fernando Gont Date: Tue, 18 Dec 2012 13:44:02 -0500 Thread-Topic: [OPSEC] Security Implications of IPv6 on IPv4 Networks Thread-Index: Ac3cypVkh8MTi/ADSZCtn8cGsyqn8wAXlUDw Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230339D9655A@PRVPEXVS15.corp.twcable.com> References: <2671C6CDFBB59E47B64C10B3E0BD5923033907350D@PRVPEXVS15.corp.twcable.com> <50CF423D.3000503@si6networks.com> <2671C6CDFBB59E47B64C10B3E0BD59230339D95F50@PRVPEXVS15.corp.twcable.com> <50CFDA1E.30408@si6networks.com> In-Reply-To: <50CFDA1E.30408@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" , "draft-ietf-opsec-ipv6-implications-on-ipv4-nets@tools.ietf.org" Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:44:02 -0000 > From: Fernando Gont [mailto:fgont@si6networks.com] > >> Filtering AAAA records at the organizational recursive DNS server? > >> > > [WEG] yes, to ensure that even if an end client thinks it has IPv6 > > connectivity, and the network is actively working to filter/disable > > IPv6, this will ensure that the client doesn't receive responses for > > AAAA queries and attempt to connect to an IPv6 host. > > Should I include some text in the Intro (only), or should I include a > note in each of the filtering sections ("If you filter these packets, > you should probably also filter the corresponding AAAA records"). [WEG] I think that perhaps a section on IPv6 brokenness inserted before the= discussion of the specific filtering options, or at the end of the intro m= ight make sense. Something like: "IPv6 deployments in the Internet are continually increasing, and some host= s default to preferring IPv6 connectivity whenever it is available. This is= likely to cause IPv6-capable hosts to attempt to reach an ever-increasing = number of popular destinations via IPv6, even if this IPv6 is via a transit= ion technology over an IPv4-only network. A large source of IPv6 brokenness= today comes from nodes that believe that they have functional IPv6 connect= ivity, but the path to their destination fails somewhere upstream. [citatio= n to Huston's studies?] Upstream filtering of transition technologies or si= tuations where a misconfigured node attempts to "provide" native IPv6 servi= ce on a given network without proper upstream IPv6 connectivity may result = in end hosts attempting to reach IPv6 hosts, and depending on the absence o= r presence and specific implementation details of happy eyeballs [rfc 6555]= , there may be a non-trivial timeout period before the host falls back to I= Pv4. For this reason, networks attempting to prevent IPv6 traffic from trav= ersing their devices SHOULD consider configuring their local recursive DNS = servers to ignore queries for AAAA DNS records, or even consider filtering = AAAA records at the network ingress point to prevent end hosts from attempt= ing their own DNS resolution. This will ensure that end hosts which are on = an IPv4-only network will only receive DNS A records, and they will be unli= kely to attempt to use (likely broken) IPv6 connectivity to reach their des= ired destinations. " > > Well, for all these cases, the filtering happens in v4, rather than v6 > -- e.g., filter ip proto 41, or the Teredo IPv4-based UDP ports, etc. > [WEG] you make a valid point that I'm sort of ashamed that I missed, and th= at led to me conflating a couple of things in a way that was not helpful. M= y apologies. *blush* > > > Please see above. In all these cases, the filtering happens in v4, and > not in v6. > [WEG] Noted. However, you also discuss other security measures that are mor= e IPv6-specific, such as ways to block rogue RAs, DHCPv6, etc, or even any = link-local IPv6 traffic, which is more what I had in mind when I mentioned = IPv6 security control. How does one go about blocking IPv6 traffic on your = network if it doesn't pass the security device encapsulated in IPv4, or doe= sn't pass the security device at all because it's local to a LAN? So I thin= k the choice becomes either find a way with your existing IPv4-only devices= to block *all* IPv6 traffic within your LANs, upgrade at least some of the= m to recognize and block local IPv6 traffic (along with any upstream blocki= ng of encapsualated v6), or acknowledge that you may still have local IPv6 = traffic on the network, and the potential security risk that may present (a= compromised machine can trigger IPv6 exploits on other machines in the net= work, etc). > > > >> > > [WEG] now who's talking about keeping an ops document as realistic as > > possible? ;-) Seriously, except in some of the most draconian of user > > environments (where network security violations are a zero-tolerance > > termination offense and 100% of devices on the network are centrally > > managed/locked down against unauthorized changes or both), I think > > that it's unrealistic to assume that there are no users "deciding" > > that the security/network admin's policy either doesn't apply to them > > or is otherwise stupid and "deciding" to find a way to circumvent it. > > From the security admin pov, that's an attack -- hence the admin doesn't > need to allow such traffic. [WEG] not saying they need to allow it. I'm saying that it exists because a= dherence to security policies is rarely 100%. But the point I'm really maki= ng here is that if a user has taken it upon themselves to make a way to car= ry IPv6 traffic through a network that doesn't yet support it, a good secur= ity admin (that is one that doesn't simply rule with an iron fist) should p= robably try to determine why this has happened, and whether there might be = a legitimate business reason for it that might lead to a different decision= (eg "we need to deploy IPv6") or whether it is the result of an attempt to= set up a covert channel or other malicious intent. > > > > I don't necessarily see v6 as "optional" -- and I certainly do not see > as optional in the future. [WEG] so I don't understand the resistance to making that statement in the = document, even if it's only a couple of sentences in the intro. > > My take is that the decision about whether to deploy v6 is (and should) > happen as a result of something else, and not just to address these > issues. [WEG] I agree, however, my view is that this is yet one more reason that sh= ould contribute to the decision to deploy IPv6, rather than being evaluated= independently from that discussion. I think we agree that the message of t= his document is "IPv6 is here, and it may be on your 'IPv4-only' network, y= ou need to consider the security implications." What I'm suggesting is that= there's an added thing which is "IPv6 deployments are happening, and this = idea of filtering the traffic is a temporary solution to protect your netwo= rk until you deploy IPv6." Perhaps with some qualifier about the fact that = some networks will have justification to remain IPv4-only for longer than o= thers, but this should be the exception rather than the default. > > > [WEG] I'll have a look, but at some point the "math is hard, let's go > > shopping" [1] justification for delaying IPv6 deployment really stops > > being relevant, and I think we do a disservice to those reviewing > > documents like this to make it seem like that's really an option to > > consider indefinitely. > > Is there anything (in particular) that gives you such idea? -- I ask > because that's not my idea, and not what I wanted to reflect in the > document. > [WEG] the fact that the document doesn't include the point I made just abov= e and the fact that you're justifying it by citing discussion that we shoul= dn't recommend IPv6 deployment as a solution because IPv6 deployment is har= d. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From fgont@si6networks.com Tue Dec 18 13:19:15 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A63B21E8039 for ; Tue, 18 Dec 2012 13:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A0YXVXr7tPy for ; Tue, 18 Dec 2012 13:19:14 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id E5D5C1F0CE1 for ; Tue, 18 Dec 2012 13:19:13 -0800 (PST) Received: from 187-135-17-190.fibertel.com.ar ([190.17.135.187] helo=[192.168.123.124]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Tl4Yk-0002y3-QM; Tue, 18 Dec 2012 22:18:43 +0100 Message-ID: <50D0D29A.7000104@si6networks.com> Date: Tue, 18 Dec 2012 17:31:22 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "George, Wes" References: <2671C6CDFBB59E47B64C10B3E0BD5923033907350D@PRVPEXVS15.corp.twcable.com> <50CF423D.3000503@si6networks.com> <2671C6CDFBB59E47B64C10B3E0BD59230339D95F50@PRVPEXVS15.corp.twcable.com> <50CFDA1E.30408@si6networks.com> <2671C6CDFBB59E47B64C10B3E0BD59230339D9655A@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230339D9655A@PRVPEXVS15.corp.twcable.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" , "draft-ietf-opsec-ipv6-implications-on-ipv4-nets@tools.ietf.org" Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 21:19:15 -0000 Hi, Wes, On 12/18/2012 03:44 PM, George, Wes wrote: >> Should I include some text in the Intro (only), or should I include >> a note in each of the filtering sections ("If you filter these >> packets, you should probably also filter the corresponding AAAA >> records"). > > [WEG] I think that perhaps a section on IPv6 brokenness inserted > before the discussion of the specific filtering options, or at the > end of the intro might make sense. Something like: "IPv6 deployments > in the Internet are continually increasing, and some hosts default to > preferring IPv6 connectivity whenever it is available. This is likely > to cause IPv6-capable hosts to attempt to reach an ever-increasing > number of popular destinations via IPv6, even if this IPv6 is via a > transition technology over an IPv4-only network. A large source of > IPv6 brokenness today comes from nodes that believe that they have > functional IPv6 connectivity, but the path to their destination fails > somewhere upstream. [citation to Huston's studies?] Upstream > filtering of transition technologies or situations where a > misconfigured node attempts to "provide" native IPv6 service on a > given network without proper upstream IPv6 connectivity may result in > end hosts attempting to reach IPv6 hosts, and depending on the > absence or presence and specific implementation details of happy > eyeballs [rfc 6555], there may be a non-trivial timeout period before > the host falls back to IPv4. For this reason, networks attempting to > prevent IPv6 traffic from traversing their devices SHOULD consider > configuring their local recursive DNS servers to ignore queries for > AAAA DNS records, or even consider filtering AAAA records at the > network ingress point to prevent end hosts from attempting their own > DNS resolution. This will ensure that end hosts which are on an > IPv4-only network will only receive DNS A records, and they will be > unlikely to attempt to use (likely broken) IPv6 connectivity to reach > their desired destinations. " *Thanks you*! -- I will incorporate this in the next rev. >> Well, for all these cases, the filtering happens in v4, rather than >> v6 -- e.g., filter ip proto 41, or the Teredo IPv4-based UDP ports, >> etc. >> > [WEG] you make a valid point that I'm sort of ashamed that I missed, > and that led to me conflating a couple of things in a way that was > not helpful. My apologies. *blush* No worries at all! >> Please see above. In all these cases, the filtering happens in v4, >> and not in v6. >> > [WEG] Noted. However, you also discuss other security measures that > are more IPv6-specific, such as ways to block rogue RAs, DHCPv6, etc, > or even any link-local IPv6 traffic, which is more what I had in mind > when I mentioned IPv6 security control. Yes. This is all "enforcing IPv6 security controls on your IPv6 networks" -- there's no other way to mitigate link-local attacks (except if you filter v6 packets based on the Ethernet Proto field). > How does one go about > blocking IPv6 traffic on your network if it doesn't pass the security > device encapsulated in IPv4, or doesn't pass the security device at > all because it's local to a LAN? Filter packets based on the Ethernet Proto field, or enforce layer-2/3 filtering a la RA-Guard/DHCPv6-Shield. >>> [WEG] now who's talking about keeping an ops document as >>> realistic as possible? ;-) Seriously, except in some of the most >>> draconian of user environments (where network security violations >>> are a zero-tolerance termination offense and 100% of devices on >>> the network are centrally managed/locked down against >>> unauthorized changes or both), I think that it's unrealistic to >>> assume that there are no users "deciding" that the >>> security/network admin's policy either doesn't apply to them or >>> is otherwise stupid and "deciding" to find a way to circumvent >>> it. >> >> From the security admin pov, that's an attack -- hence the admin >> doesn't need to allow such traffic. > > [WEG] not saying they need to allow it. I'm saying that it exists > because adherence to security policies is rarely 100%. But the point > I'm really making here is that if a user has taken it upon themselves > to make a way to carry IPv6 traffic through a network that doesn't > yet support it, a good security admin (that is one that doesn't > simply rule with an iron fist) should probably try to determine why > this has happened, and whether there might be a legitimate business > reason for it that might lead to a different decision (eg "we need to > deploy IPv6") or whether it is the result of an attempt to set up a > covert channel or other malicious intent. In my personal experience, most admins generally fall into the "iron fist" category.. :-) But YMMV... >> I don't necessarily see v6 as "optional" -- and I certainly do not >> see as optional in the future. > [WEG] so I don't understand the resistance to making that statement > in the document, even if it's only a couple of sentences in the > intro. If anything, I was resisting to "the way to mitigate this is to deploy v6". Something along the lines of what you wrote below ("IPv6 deployments are happening, and this idea of filtering the traffic is a temporary solution to protect your network until you deploy IPv6") is perfectly fine to me. >> My take is that the decision about whether to deploy v6 is (and >> should) happen as a result of something else, and not just to >> address these issues. > [WEG] I agree, however, my view is that this is yet one more reason > that should contribute to the decision to deploy IPv6, rather than > being evaluated independently from that discussion. I think we agree > that the message of this document is "IPv6 is here, and it may be on > your 'IPv4-only' network, you need to consider the security > implications." What I'm suggesting is that there's an added thing > which is "IPv6 deployments are happening, and this idea of filtering > the traffic is a temporary solution to protect your network until you > deploy IPv6." Perhaps with some qualifier about the fact that some > networks will have justification to remain IPv4-only for longer than > others, but this should be the exception rather than the default. So, have about including something along those lines in the intro. i.e. "IPv6 deployments are happening, and thus filtering IPv6 traffic to mitigate IPv6 security implications on IPv4 networks is a temporary solution to protect your network until you deploy IPv6. In some exceptional cases (such as e.g. military operations networks), this approach to mitigating the aforementioned security implications could be thought of as a longer-term strategy." (please suggest tweaks if deemed appropriate). >>> [WEG] I'll have a look, but at some point the "math is hard, >>> let's go shopping" [1] justification for delaying IPv6 deployment >>> really stops being relevant, and I think we do a disservice to >>> those reviewing documents like this to make it seem like that's >>> really an option to consider indefinitely. >> >> Is there anything (in particular) that gives you such idea? -- I >> ask because that's not my idea, and not what I wanted to reflect in >> the document. >> > [WEG] the fact that the document doesn't include the point I made > just above and the fact that you're justifying it by citing > discussion that we shouldn't recommend IPv6 deployment as a solution > because IPv6 deployment is hard. Would the above changes address your concerns? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From wesley.george@twcable.com Wed Dec 19 05:32:15 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CAF21F8B20 for ; Wed, 19 Dec 2012 05:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXfUN+6jIXua for ; Wed, 19 Dec 2012 05:32:14 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id AC27D21F86C0 for ; Wed, 19 Dec 2012 05:32:14 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,316,1355115600"; d="scan'208";a="556118" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 19 Dec 2012 08:32:00 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 19 Dec 2012 08:32:03 -0500 From: "George, Wes" To: Fernando Gont Date: Wed, 19 Dec 2012 08:32:04 -0500 Thread-Topic: [OPSEC] Security Implications of IPv6 on IPv4 Networks Thread-Index: Ac3dZUkOuL/6O8nySkGfWrz0SlZj/AAh01TQ Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033A3B3C1C@PRVPEXVS15.corp.twcable.com> References: <2671C6CDFBB59E47B64C10B3E0BD5923033907350D@PRVPEXVS15.corp.twcable.com> <50CF423D.3000503@si6networks.com> <2671C6CDFBB59E47B64C10B3E0BD59230339D95F50@PRVPEXVS15.corp.twcable.com> <50CFDA1E.30408@si6networks.com> <2671C6CDFBB59E47B64C10B3E0BD59230339D9655A@PRVPEXVS15.corp.twcable.com> <50D0D29A.7000104@si6networks.com> In-Reply-To: <50D0D29A.7000104@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" , "draft-ietf-opsec-ipv6-implications-on-ipv4-nets@tools.ietf.org" Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 13:32:15 -0000 > From: Fernando Gont [mailto:fgont@si6networks.com] > Sent: Tuesday, December 18, 2012 3:31 PM > >> My take is that the decision about whether to deploy v6 is (and > >> should) happen as a result of something else, and not just to address > >> these issues. > > [WEG] I agree, however, my view is that this is yet one more reason > > that should contribute to the decision to deploy IPv6, rather than > > being evaluated independently from that discussion. I think we agree > > that the message of this document is "IPv6 is here, and it may be on > > your 'IPv4-only' network, you need to consider the security > > implications." What I'm suggesting is that there's an added thing > > which is "IPv6 deployments are happening, and this idea of filtering > > the traffic is a temporary solution to protect your network until you > > deploy IPv6." Perhaps with some qualifier about the fact that some > > networks will have justification to remain IPv4-only for longer than > > others, but this should be the exception rather than the default. > > So, have about including something along those lines in the intro. i.e. > > "IPv6 deployments are happening, and thus filtering IPv6 traffic to > mitigate IPv6 security implications on IPv4 networks is a temporary > solution to protect your network until you deploy IPv6. In some > exceptional cases (such as e.g. military operations networks), this > approach to mitigating the aforementioned security implications could be > thought of as a longer-term strategy." > > > Would the above changes address your concerns? [WEG] yes, thanks a lot Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From internet-drafts@ietf.org Fri Dec 28 02:25:27 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0AD21F8319; Fri, 28 Dec 2012 02:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVtEhO9YIeSn; Fri, 28 Dec 2012 02:25:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E4721F8D32; Fri, 28 Dec 2012 02:25:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121228102527.10685.69919.idtracker@ietfa.amsl.com> Date: Fri, 28 Dec 2012 02:25:27 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 10:25:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : Security Implications of IPv6 on IPv4 Networks Author(s) : Fernando Gont Will Liu Filename : draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02.txt Pages : 21 Date : 2012-12-28 Abstract: This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4= -nets There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-= 02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ipv6-implications-on-ip= v4-nets-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/