From nobody Thu Feb 5 05:33:40 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D481A1AA5; Thu, 5 Feb 2015 05:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX-_GEjIj3Zb; Thu, 5 Feb 2015 05:33:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 318AD1A8877; Thu, 5 Feb 2015 05:33:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205133327.4216.41600.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 05:33:27 -0800 Archived-At: Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-06.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 13:33:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. 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 Authors : Fernando Gont Tim Chown Filename : draft-ietf-opsec-ipv6-host-scanning-06.txt Pages : 33 Date : 2015-02-05 Abstract: IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or less unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and therefore brute-force IPv6 address scanning attacks have been considered unfeasible. This document updates RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address scanning techniques apply to IPv6 networks, and exploring some additional techniques that can be employed for IPv6 network reconnaissance. In doing so, 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-host-scanning-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 6 04:08:00 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47581A0263 for ; Fri, 6 Feb 2015 04:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rsg3yKOSsXGu for ; Fri, 6 Feb 2015 04:07:44 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3441A01BA for ; Fri, 6 Feb 2015 04:07:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B03EA871628; Fri, 6 Feb 2015 13:07:42 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5JSeDqfwUZF; Fri, 6 Feb 2015 13:07:42 +0100 (CET) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 900B7871613; Fri, 6 Feb 2015 13:07:42 +0100 (CET) Message-ID: <54D4AE8D.1020508@globis.net> Date: Fri, 06 Feb 2015 13:07:41 +0100 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: opsec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont Subject: Re: [OPSEC] I-D Action:,draft-ietf-opsec-ipv6-host-scanning-06.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 12:07:48 -0000 I have read this version of the draft and support it. My previous comments have been incorporated. Thanks. > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > 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 > Authors : Fernando Gont > Tim Chown > Filename : draft-ietf-opsec-ipv6-host-scanning-06.txt > Pages : 33 > Date : 2015-02-05 > > Abstract: > IPv6 offers a much larger address space than that of its IPv4 > counterpart. An IPv6 subnet of size /64 can (in theory) accommodate > approximately 1.844 * 10^19 hosts, thus resulting in a much lower > host density (#hosts/#addresses) than is typical in IPv4 networks, > where a site typically has 65,000 or less unique addresses. As a > result, it is widely assumed that it would take a tremendous effort > to perform address scanning attacks against IPv6 networks, and > therefore brute-force IPv6 address scanning attacks have been > considered unfeasible. This document updates RFC 5157, which first > discussed this assumption, by providing further analysis on how > traditional address scanning techniques apply to IPv6 networks, and > exploring some additional techniques that can be employed for IPv6 > network reconnaissance. In doing so, 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-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-host-scanning-06 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ -- Regards, RayH From nobody Sat Feb 7 11:47:40 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B381A1A47; Sat, 7 Feb 2015 11:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz7Zm7aHTEtt; Sat, 7 Feb 2015 11:46:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E6C1A0AF1; Sat, 7 Feb 2015 11:46:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> Date: Sat, 07 Feb 2015 11:46:16 -0800 Archived-At: Cc: draft-ietf-opsec-dhcpv6-shield@ietf.org, opsec@ietf.org, draft-ietf-opsec-dhcpv6-shield.ad@ietf.org, draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org, opsec-chairs@ietf.org, brian.e.carpenter@gmail.com Subject: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 19:46:18 -0000 Ted Lemon has entered the following ballot position for draft-ietf-opsec-dhcpv6-shield-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- When I began with this DISCUSS, my understanding was that in order to implement DHCPv6 Shield and be sure of stopping all DHCP packets, it would, as the document says, be necessary to filter packets with unknown IPv6 headers. This would likely mean that the layer 2 switching fabric of a network supporting DHCPv6 shield would be unable to carry any IP packets containing not only unknown IP extension headers, but also packets containing unknown (to the switching fabric) protocol headers. Consequently I suggested a fairly elaborate way to mitigate the risk without requiring that all such packets be filtered. However, after discussing this at length with Fernando, I realized that it was actually not at all necessary to filter unknown IPv6 headers. The reason for this is that we can safely assume that any IP extension header that appears in a packet conforms to RFC 6564. This means that switches implementing DHCPv6 shield can at least in principle skip over unknown IP extension headers. If an unknown protocol header is seen, this will look to the switch like a malformed IP extension header, but this is harmless in the context of DHCPv6 shield because any such packet is by definition _not_ a DHCPv6 packet. I believe that a switching fabric should not default to dropping packets it doesn't recognize, because this pretty much guarantees that new protocols can't be deployed even in site-specific situations. Therefore, I believe that this document should not only not require filtering unknown IP extension headers, but should not even mention filtering them. It may be that some implementations may need to filter them for other reasons, but this is already allowed by RFC 7045, and therefore needn't be mentioned here. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is the original text of this DISCUSS: This text makes sense, but I think it needs to be changed somewhat: 3. When parsing the IPv6 header chain, if the packet is identified to be a DHCPv6 packet meant for a DHCPv6 client or the packet contains an unrecognized Next Header value, DHCPv6-Shield MUST drop the packet, and SHOULD log the packet drop event in an implementation-specific manner as a security alert. DHCPv6-Shield MUST provide a configuration knob that controls whether packets with unrecognized Next Header values are dropped; this configuration knob MUST default to "drop". RATIONALE: An unrecognized Next Header value could possibly identify an IPv6 Extension Header, and thus be leveraged to conceal a DHCPv6-server packet (since there is no way for DHCPv6-Shield to parse past unrecognized Next Header values [I-D.gont-6man-rfc6564bis]). [RFC7045] requires that nodes be configurable with respect to whether packets with unrecognized headers are forwarded, and allows the default behavior to be that such packets be dropped. I think it's worth considering whether the default setting for this configuration knob should be "drop" or "pass." The problem with defaulting to "drop" is that it means that extension headers the DHCPv6 Shield device does not understand fail to pass, which could cause operational problems. The problem with not defaulting to "drop" you have already explained. I do not think that the threat of DHCPv6 spoofing is sufficient to justify defaulting to drop. Yes, DHCPv6 spoofing can cause operational issues. So can filtering "unknown" headers. The frustrating thing about this document is that it actually solves the problem the wrong way. What this document should recommend is filtering of DHCPv6 packets from _clients_. If a rogue DHCP server can't see client multicasts because DHCPv6 shield is blocking them, then it can't know to attack DHCPv6 clients. This substantially limits the rogue's ability to attack DHCPv6 clients on the local subnet. If you combine that with server packet filtering but do not block unknown headers, I think you have achieved a good tradeoff between the problems caused by whatever spoofing might get to a client using an unknown header and the problems caused by blocking non-DHCP packets that use that unknown header for some legitimate purpose. So, realizing that this would be a major change, the way I would LIKE you to address this discuss is to add DHCPv6 client packet filtering. You could also address it by changing the default for the unknown header filter, but I would understand if you felt that this was inadequate. Or you could argue persuasively that I'm wrong, which has been known to happen. :) From nobody Sat Feb 7 11:50:39 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C451A19F7; Sat, 7 Feb 2015 11:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU32iIePfir8; Sat, 7 Feb 2015 11:48:14 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00E61A0AF1; Sat, 7 Feb 2015 11:48:01 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id BC897DA00EF; Sat, 7 Feb 2015 19:48:01 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 6C02653E08A; Sat, 7 Feb 2015 11:48:01 -0800 (PST) Received: from [192.168.1.4] (70.196.212.73) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sat, 7 Feb 2015 11:48:01 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> Date: Sat, 7 Feb 2015 12:47:55 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> To: The IESG X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [70.196.212.73] Archived-At: Cc: draft-ietf-opsec-dhcpv6-shield@ietf.org, opsec@ietf.org, draft-ietf-opsec-dhcpv6-shield.ad@ietf.org, draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org, opsec-chairs@ietf.org, brian.e.carpenter@gmail.com Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 19:48:16 -0000 On Feb 7, 2015, at 12:46 PM, Ted Lemon wrote: > The reason for this is that we can safely assume that any IP extension > header that appears in a packet conforms to RFC 6564.=20 What I mean here is that any IP extension header not already = standardized at the time of publication of this document, which = presumably any implementation conforming to this document will be aware = of. Of course there are IP extension headers already defined that do = not conform to RFC 6564. From nobody Sat Feb 7 12:27:21 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5CA1A0404; Sat, 7 Feb 2015 12:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4TbrHskHgIV; Sat, 7 Feb 2015 12:25:40 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF071A00A7; Sat, 7 Feb 2015 12:25:40 -0800 (PST) Received: from [192.168.44.15] (71-9-224-93.static.reno.nv.charter.com [71.9.224.93]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t17KPa3D082968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Feb 2015 20:25:37 GMT (envelope-from joelja@bogus.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joel Jaeggli X-Mailer: iPhone Mail (12B466) In-Reply-To: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> Date: Sat, 7 Feb 2015 12:25:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> To: Ted Lemon Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 20:25:42 -0000 Right one would expect future extension headers to match the TLV expectatio= ns of 6564. I can live with the removal of filtering advice but I'd like to s= ee that run past the working group at the very least. Sent from my iPhone > On Feb 7, 2015, at 11:46, Ted Lemon wrote: >=20 > Ted Lemon has entered the following ballot position for > draft-ietf-opsec-dhcpv6-shield-05: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > When I began with this DISCUSS, my understanding was that in order to > implement DHCPv6 Shield and be sure of stopping all DHCP packets, it > would, as the document says, be necessary to filter packets with unknown > IPv6 headers. This would likely mean that the layer 2 switching fabric > of a network supporting DHCPv6 shield would be unable to carry any IP > packets containing not only unknown IP extension headers, but also > packets containing unknown (to the switching fabric) protocol headers. =20= > Consequently I suggested a fairly elaborate way to mitigate the risk > without requiring that all such packets be filtered. >=20 > However, after discussing this at length with Fernando, I realized that > it was actually not at all necessary to filter unknown IPv6 headers. =20 > The reason for this is that we can safely assume that any IP extension > header that appears in a packet conforms to RFC 6564. This means that > switches implementing DHCPv6 shield can at least in principle skip over > unknown IP extension headers. If an unknown protocol header is seen, > this will look to the switch like a malformed IP extension header, but > this is harmless in the context of DHCPv6 shield because any such packet > is by definition _not_ a DHCPv6 packet. I believe that a switching > fabric should not default to dropping packets it doesn't recognize, > because this pretty much guarantees that new protocols can't be deployed > even in site-specific situations. >=20 > Therefore, I believe that this document should not only not require > filtering unknown IP extension headers, but should not even mention > filtering them. It may be that some implementations may need to filter > them for other reasons, but this is already allowed by RFC 7045, and > therefore needn't be mentioned here. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This is the original text of this DISCUSS: >=20 > This text makes sense, but I think it needs to be changed somewhat: >=20 > 3. When parsing the IPv6 header chain, if the packet is identified > to be a DHCPv6 packet meant for a DHCPv6 client or the packet > contains an unrecognized Next Header value, DHCPv6-Shield MUST > drop the packet, and SHOULD log the packet drop event in an > implementation-specific manner as a security alert. > DHCPv6-Shield MUST provide a configuration knob that controls > whether packets with unrecognized Next Header values are dropped; > this configuration knob MUST default to "drop". >=20 > RATIONALE: An unrecognized Next Header value could possibly > identify an IPv6 Extension Header, and thus be leveraged to > conceal a DHCPv6-server packet (since there is no way for > DHCPv6-Shield to parse past unrecognized Next Header values > [I-D.gont-6man-rfc6564bis]). [RFC7045] requires that nodes be > configurable with respect to whether packets with unrecognized > headers are forwarded, and allows the default behavior to be > that such packets be dropped. >=20 > I think it's worth considering whether the default setting for this > configuration knob should be "drop" or "pass." The problem with > defaulting to "drop" is that it means that extension headers the DHCPv6 > Shield device does not understand fail to pass, which could cause > operational problems. The problem with not defaulting to "drop" you > have already explained. I do not think that the threat of DHCPv6 > spoofing is sufficient to justify defaulting to drop. Yes, DHCPv6 > spoofing can cause operational issues. So can filtering "unknown" > headers. >=20 > The frustrating thing about this document is that it actually solves the > problem the wrong way. What this document should recommend is filtering > of DHCPv6 packets from _clients_. If a rogue DHCP server can't see > client multicasts because DHCPv6 shield is blocking them, then it can't > know to attack DHCPv6 clients. This substantially limits the rogue's > ability to attack DHCPv6 clients on the local subnet. If you combine > that with server packet filtering but do not block unknown headers, I > think you have achieved a good tradeoff between the problems caused by > whatever spoofing might get to a client using an unknown header and the > problems caused by blocking non-DHCP packets that use that unknown header > for some legitimate purpose. >=20 > So, realizing that this would be a major change, the way I would LIKE you > to address this discuss is to add DHCPv6 client packet filtering. You > could also address it by changing the default for the unknown header > filter, but I would understand if you felt that this was inadequate. Or > you could argue persuasively that I'm wrong, which has been known to > happen. :) >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 From nobody Sat Feb 7 12:37:14 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9FD1A0404; Sat, 7 Feb 2015 12:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO12pNQTd8M6; Sat, 7 Feb 2015 12:37:11 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4245B1A00A7; Sat, 7 Feb 2015 12:37:11 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 07250DA00EF; Sat, 7 Feb 2015 20:37:11 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B57FD53E08A; Sat, 7 Feb 2015 12:37:10 -0800 (PST) Received: from [172.19.131.139] (12.130.116.26) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sat, 7 Feb 2015 12:37:10 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Sat, 7 Feb 2015 13:37:03 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [12.130.116.26] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 20:37:12 -0000 On Feb 7, 2015, at 1:25 PM, Joel Jaeggli wrote: > Right one would expect future extension headers to match the TLV = expectations of 6564. I can live with the removal of filtering advice = but I'd like to see that run past the working group at the very least. Sounds like a good plan. Thanks! From nobody Sat Feb 7 16:02:06 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39E91A1E0E; Sat, 7 Feb 2015 16:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pGzmt48_AFz; Sat, 7 Feb 2015 16:00:33 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAB11A1ABB; Sat, 7 Feb 2015 16:00:33 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id lf10so17771009pab.12; Sat, 07 Feb 2015 16:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9n8DNyQ210YOtsrvuurXDvKK3PDvqzDYztBpR4vdjqM=; b=wYXDMsV5Uzci0h9hTQVZMAXf1Z8gHFhqUtJG4RTEGijQgGFcY3QIkQN454QO9BUP30 Fox6UyDAxig0aznxNbDcbytNPdCBKM738KAK6Jsvx3qlX021ch54vdswXK2H+77bwFJY CA8V1a0TFkzMnVZFSCfz/SimWH3Dpb6d2/ajcjPBINsT9jZCol1t9HzAJCx6LzbN1HrL 93bi7Kxz6KawaA25Fct3V3fanHa4yPr8rQj64Rni9YARVxbE4XwfNtTmKINLcMCLPzF1 UjNRzRvE9ZDxqyLQQ8ugTsTv93KxkRgPVCnekt9G8Y/Z5Ujg1OBH/zDOQKi0YGwX/t1Y /fRg== X-Received: by 10.68.135.97 with SMTP id pr1mr17184501pbb.71.1423353632300; Sat, 07 Feb 2015 16:00:32 -0800 (PST) Received: from ?IPv6:2406:e007:67be:1:28cc:dc4c:9703:6781? ([2406:e007:67be:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id x1sm12018287pda.90.2015.02.07.16.00.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Feb 2015 16:00:31 -0800 (PST) Message-ID: <54D6A719.1010401@gmail.com> Date: Sun, 08 Feb 2015 13:00:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon , Joel Jaeggli References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 00:00:35 -0000 On 08/02/2015 09:37, Ted Lemon wrote: > On Feb 7, 2015, at 1:25 PM, Joel Jaeggli wrote: >> Right one would expect future extension headers to match the TLV expectations of 6564. I can live with the removal of filtering advice but I'd like to see that run past the working group at the very least. > > Sounds like a good plan. Thanks! However, I don't think you should remove this sentence and the normative reference to RFC 7045: [RFC7045] requires that nodes be configurable with respect to whether packets with unrecognized headers are forwarded, and allows the default behavior to be that such packets be dropped. Brian From nobody Sat Feb 7 16:56:10 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF21C1A0673; Sat, 7 Feb 2015 16:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMkdOkMOOKQ6; Sat, 7 Feb 2015 16:56:06 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B4F1A1BBB; Sat, 7 Feb 2015 16:56:06 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 77B9DDA00E8; Sun, 8 Feb 2015 00:56:06 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 376FD53E08A; Sat, 7 Feb 2015 16:56:06 -0800 (PST) Received: from [172.19.131.139] (12.130.116.84) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sat, 7 Feb 2015 16:56:05 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54D6A719.1010401@gmail.com> Date: Sat, 7 Feb 2015 19:55:54 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <54D6A719.1010401@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [12.130.116.84] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 00:56:08 -0000 On Feb 7, 2015, at 7:00 PM, Brian E Carpenter = wrote: > However, I don't think you should remove this sentence and the = normative reference > to RFC 7045: >=20 > [RFC7045] requires that nodes be > configurable with respect to whether packets with unrecognized > headers are forwarded, and allows the default behavior to be > that such packets be dropped. What does that have to do with DHCPv6 shield? I guess I don't mind if = this is included, but it seems unnecessary. From nobody Sat Feb 7 19:37:38 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5661A1B40 for ; Sat, 7 Feb 2015 19:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxCbILE6607R for ; Sat, 7 Feb 2015 19:37:31 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3BA1A1ADD for ; Sat, 7 Feb 2015 19:37:29 -0800 (PST) Received: (qmail 5187 invoked from network); 7 Feb 2015 19:37:20 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 7 Feb 2015 19:37:19 -0800 Date: Sat, 7 Feb 2015 19:37:19 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Ted Lemon , Joel Jaeggli In-Reply-To: Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 03:37:33 -0000 On Sat, 7 Feb 2015, Ted Lemon wrote: > However, after discussing this at length with Fernando, I realized that > it was actually not at all necessary to filter unknown IPv6 headers. > The reason for this is that we can safely assume that any IP extension > header that appears in a packet conforms to RFC 6564. This means that > switches implementing DHCPv6 shield can at least in principle skip over > unknown IP extension headers. That is incorrect because extension headers and upper layer headers share a numbering space. Upper layer headers do NOT follow the format in RFC 6564. That makes it in UNSAFE to attempt to skip over an unknown next header value. The decision to drop or pass must be made when an unknown extension header is encountered. Whether the default is drop or pass when encountering an unknown next header value may be worth reconsidering. However, I strongly agree with Brian Carpenter that the normative reference to RFC 7045 should be retained, and with it the requirement that the behaviour upon encountering an unknown next header value be user configurable. Mike Heard P.S. For previous discussion please see: http://www.ietf.org/mail-archive/web/opsec/current/msg01481.html http://www.ietf.org/mail-archive/web/v6ops/current/msg18529.html and please note that RFC 7113 (RA-Guard) specifies the same behaviour as does draft-ietf-opsec-dhcpv6-shield-05. On Sat, 7 Feb 2015, Joel Jaeggli wrote: > Right one would expect future extension headers to match the TLV > expectations of 6564. I can live with the removal of filtering > advice but I'd like to see that run past the working group at the > very least. > > Sent from my iPhone > > > On Feb 7, 2015, at 11:46, Ted Lemon wrote: > > > > Ted Lemon has entered the following ballot position for > > draft-ietf-opsec-dhcpv6-shield-05: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > When I began with this DISCUSS, my understanding was that in order to > > implement DHCPv6 Shield and be sure of stopping all DHCP packets, it > > would, as the document says, be necessary to filter packets with unknown > > IPv6 headers. This would likely mean that the layer 2 switching fabric > > of a network supporting DHCPv6 shield would be unable to carry any IP > > packets containing not only unknown IP extension headers, but also > > packets containing unknown (to the switching fabric) protocol headers. > > Consequently I suggested a fairly elaborate way to mitigate the risk > > without requiring that all such packets be filtered. > > > > However, after discussing this at length with Fernando, I realized that > > it was actually not at all necessary to filter unknown IPv6 headers. > > The reason for this is that we can safely assume that any IP extension > > header that appears in a packet conforms to RFC 6564. This means that > > switches implementing DHCPv6 shield can at least in principle skip over > > unknown IP extension headers. If an unknown protocol header is seen, > > this will look to the switch like a malformed IP extension header, but > > this is harmless in the context of DHCPv6 shield because any such packet > > is by definition _not_ a DHCPv6 packet. I believe that a switching > > fabric should not default to dropping packets it doesn't recognize, > > because this pretty much guarantees that new protocols can't be deployed > > even in site-specific situations. > > > > Therefore, I believe that this document should not only not require > > filtering unknown IP extension headers, but should not even mention > > filtering them. It may be that some implementations may need to filter > > them for other reasons, but this is already allowed by RFC 7045, and > > therefore needn't be mentioned here. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > This is the original text of this DISCUSS: > > > > This text makes sense, but I think it needs to be changed somewhat: > > > > 3. When parsing the IPv6 header chain, if the packet is identified > > to be a DHCPv6 packet meant for a DHCPv6 client or the packet > > contains an unrecognized Next Header value, DHCPv6-Shield MUST > > drop the packet, and SHOULD log the packet drop event in an > > implementation-specific manner as a security alert. > > DHCPv6-Shield MUST provide a configuration knob that controls > > whether packets with unrecognized Next Header values are dropped; > > this configuration knob MUST default to "drop". > > > > RATIONALE: An unrecognized Next Header value could possibly > > identify an IPv6 Extension Header, and thus be leveraged to > > conceal a DHCPv6-server packet (since there is no way for > > DHCPv6-Shield to parse past unrecognized Next Header values > > [I-D.gont-6man-rfc6564bis]). [RFC7045] requires that nodes be > > configurable with respect to whether packets with unrecognized > > headers are forwarded, and allows the default behavior to be > > that such packets be dropped. > > > > I think it's worth considering whether the default setting for this > > configuration knob should be "drop" or "pass." The problem with > > defaulting to "drop" is that it means that extension headers the DHCPv6 > > Shield device does not understand fail to pass, which could cause > > operational problems. The problem with not defaulting to "drop" you > > have already explained. I do not think that the threat of DHCPv6 > > spoofing is sufficient to justify defaulting to drop. Yes, DHCPv6 > > spoofing can cause operational issues. So can filtering "unknown" > > headers. > > > > The frustrating thing about this document is that it actually solves the > > problem the wrong way. What this document should recommend is filtering > > of DHCPv6 packets from _clients_. If a rogue DHCP server can't see > > client multicasts because DHCPv6 shield is blocking them, then it can't > > know to attack DHCPv6 clients. This substantially limits the rogue's > > ability to attack DHCPv6 clients on the local subnet. If you combine > > that with server packet filtering but do not block unknown headers, I > > think you have achieved a good tradeoff between the problems caused by > > whatever spoofing might get to a client using an unknown header and the > > problems caused by blocking non-DHCP packets that use that unknown header > > for some legitimate purpose. > > > > So, realizing that this would be a major change, the way I would LIKE you > > to address this discuss is to add DHCPv6 client packet filtering. You > > could also address it by changing the default for the unknown header > > filter, but I would understand if you felt that this was inadequate. Or > > you could argue persuasively that I'm wrong, which has been known to > > happen. :) > > > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > > > From nobody Sat Feb 7 20:14:25 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5461A016C; Sat, 7 Feb 2015 20:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvAjzXUKphNF; Sat, 7 Feb 2015 20:14:19 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B561A0081; Sat, 7 Feb 2015 20:14:19 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id kx10so1828169pab.0; Sat, 07 Feb 2015 20:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ALyMcc3lVGpnV0s7g4lesdVnwyBsgy9+nuc2OTKbtqs=; b=lLUisq1FCJ27J/Pp5lbB69Im39ZZSrdaaxpD5VSZAxH5Bon82NUqBnoaGoU8fBmVU7 JD5P1Ub2I+RURNXzlE+oRUDUvF6gp3VF72EC+Nf+WXYF24/7tonHGQ9NYdN0qQ/xtQOm WSU8duhET2B30ByYaiweuaD/wEbIXwmelsxximiIWVO3nvpOPcyDWxilBZyW6z7HD5xb krBmqvjAQPBQ3KRhvoHKMLEuBHTGV+vRX5A8axoybChIxbksHnGP5p+Z6pusO/S/9OW2 A+Yobi+4h03mw61B4w8HqcbaOmaSKi5LxBiVXp8b/kMArQ4ebMS25m3D24jkgHvCm7OH 4GQw== X-Received: by 10.66.65.138 with SMTP id x10mr18078893pas.74.1423368858435; Sat, 07 Feb 2015 20:14:18 -0800 (PST) Received: from ?IPv6:2406:e007:67be:1:28cc:dc4c:9703:6781? ([2406:e007:67be:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id fx1sm12389380pdb.35.2015.02.07.20.14.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Feb 2015 20:14:17 -0800 (PST) Message-ID: <54D6E294.0@gmail.com> Date: Sun, 08 Feb 2015 17:14:12 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <54D6A719.1010401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 04:14:20 -0000 On 08/02/2015 13:55, Ted Lemon wrote: > On Feb 7, 2015, at 7:00 PM, Brian E Carpenter wrote: >> However, I don't think you should remove this sentence and the normative reference >> to RFC 7045: >> >> [RFC7045] requires that nodes be >> configurable with respect to whether packets with unrecognized >> headers are forwarded, and allows the default behavior to be >> that such packets be dropped. > > What does that have to do with DHCPv6 shield? I guess I don't mind if this is included, but it seems unnecessary. DHCPv6 Shield matches the definition of "forwarding node" given in RFC 7045, so reminding implementers of the requirement seems appropriate to me. Brian From nobody Sat Feb 7 23:05:01 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37EE1A6F32; Sat, 7 Feb 2015 23:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdQeSq7uZZzU; Sat, 7 Feb 2015 23:03:21 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62A61A0143; Sat, 7 Feb 2015 23:03:21 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 55BB1DA016F; Sun, 8 Feb 2015 07:03:21 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 1D06A53E08A; Sat, 7 Feb 2015 23:03:21 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sat, 7 Feb 2015 23:03:21 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Sun, 8 Feb 2015 02:03:15 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> To: "C. M. Heard" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 07:03:24 -0000 On Feb 7, 2015, at 10:37 PM, C. M. Heard wrote: > That is incorrect because extension headers and upper layer headers=20 > share a numbering space. Upper layer headers do NOT follow the=20 > format in RFC 6564. That makes it in UNSAFE to attempt to skip over=20= > an unknown next header value. I addressed that in my DISCUSS position. The fact that RA guard gives = bad advice is no reason for the bad advice to be repeated in this = document. From nobody Sun Feb 8 10:04:52 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACA21A1BAF; Sun, 8 Feb 2015 10:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtosTgCgyb3a; Sun, 8 Feb 2015 10:04:48 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957B91A1BA0; Sun, 8 Feb 2015 10:04:48 -0800 (PST) Received: from [186.134.12.169] (helo=[192.168.123.126]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YKWDq-000144-Pw; Sun, 08 Feb 2015 19:04:43 +0100 Message-ID: <54D7A51D.9050008@si6networks.com> Date: Sun, 08 Feb 2015 15:04:13 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Brian E Carpenter , Ted Lemon , Joel Jaeggli References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <54D6A719.1010401@gmail.com> In-Reply-To: <54D6A719.1010401@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 18:04:50 -0000 On 02/07/2015 09:00 PM, Brian E Carpenter wrote: > On 08/02/2015 09:37, Ted Lemon wrote: >> On Feb 7, 2015, at 1:25 PM, Joel Jaeggli wrote: >>> Right one would expect future extension headers to match the TLV >>> expectations of 6564. I can live with the removal of filtering >>> advice but I'd like to see that run past the working group at the >>> very least. >> >> Sounds like a good plan. Thanks! > > However, I don't think you should remove this sentence and the > normative reference to RFC 7045: > > [RFC7045] requires that nodes be configurable with respect to whether > packets with unrecognized headers are forwarded, and allows the > default behavior to be that such packets be dropped. Well, IMO, what Ted is essentially saying is that we cannot take the advice from RFC7045 (!). When this document says that DHCPv6 shield should (by default) filter packets with unrecognized IPv6 extension headers, t does so by backing the requirement with RFC7045. Namely, it says: ---- cut here ---- 3. When parsing the IPv6 header chain, if the packet is identified to be a DHCPv6 packet meant for a DHCPv6 client or the packet contains an unrecognized Next Header value, DHCPv6-Shield MUST drop the packet, and SHOULD log the packet drop event in an implementation-specific manner as a security alert. DHCPv6-Shield MUST provide a configuration knob that controls whether packets with unrecognized Next Header values are dropped; this configuration knob MUST default to "drop". RATIONALE: An unrecognized Next Header value could possibly identify an IPv6 Extension Header, and thus be leveraged to conceal a DHCPv6-server packet (since there is no way for DHCPv6-Shield to parse past unrecognized Next Header values [I-D.gont-6man-rfc6564bis]). [RFC7045] requires that nodes be configurable with respect to whether packets with unrecognized headers are forwarded, and allows the default behavior to be that such packets be dropped. ---- cut here ---- Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Feb 8 10:10:25 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A087E1A1B93; Sun, 8 Feb 2015 10:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8lExwT2MseK; Sun, 8 Feb 2015 10:09:47 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5581A1B71; Sun, 8 Feb 2015 10:09:47 -0800 (PST) Received: from [186.134.12.169] (helo=[192.168.123.126]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YKWIa-000155-Bf; Sun, 08 Feb 2015 19:09:37 +0100 Message-ID: <54D7A634.2070909@si6networks.com> Date: Sun, 08 Feb 2015 15:08:52 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "C. M. Heard" , Ted Lemon , Joel Jaeggli References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 18:09:52 -0000 Hi, Mike, FWIW, I made exactly the same point during the IESG-review discussions -- i.e., I agree 100% with what you've said. IMO, the default should be "drop", since that's the more sensible option from a security standpoint... and because RFC7045 (the RFC that clarifies what to do with IPv6 EHs) allows us to do so. Thanks, Fernando On 02/08/2015 12:37 AM, C. M. Heard wrote: > On Sat, 7 Feb 2015, Ted Lemon wrote: >> However, after discussing this at length with Fernando, I realized that >> it was actually not at all necessary to filter unknown IPv6 headers. >> The reason for this is that we can safely assume that any IP extension >> header that appears in a packet conforms to RFC 6564. This means that >> switches implementing DHCPv6 shield can at least in principle skip over >> unknown IP extension headers. > > That is incorrect because extension headers and upper layer headers > share a numbering space. Upper layer headers do NOT follow the > format in RFC 6564. That makes it in UNSAFE to attempt to skip over > an unknown next header value. The decision to drop or pass must be > made when an unknown extension header is encountered. > > Whether the default is drop or pass when encountering an unknown > next header value may be worth reconsidering. However, I strongly > agree with Brian Carpenter that the normative reference to RFC 7045 > should be retained, and with it the requirement that the behaviour > upon encountering an unknown next header value be user configurable. > > Mike Heard > > P.S. For previous discussion please see: > > http://www.ietf.org/mail-archive/web/opsec/current/msg01481.html > http://www.ietf.org/mail-archive/web/v6ops/current/msg18529.html > > and please note that RFC 7113 (RA-Guard) specifies the same > behaviour as does draft-ietf-opsec-dhcpv6-shield-05. > > On Sat, 7 Feb 2015, Joel Jaeggli wrote: >> Right one would expect future extension headers to match the TLV >> expectations of 6564. I can live with the removal of filtering >> advice but I'd like to see that run past the working group at the >> very least. >> >> Sent from my iPhone >> >>> On Feb 7, 2015, at 11:46, Ted Lemon wrote: >>> >>> Ted Lemon has entered the following ballot position for >>> draft-ietf-opsec-dhcpv6-shield-05: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> When I began with this DISCUSS, my understanding was that in order to >>> implement DHCPv6 Shield and be sure of stopping all DHCP packets, it >>> would, as the document says, be necessary to filter packets with unknown >>> IPv6 headers. This would likely mean that the layer 2 switching fabric >>> of a network supporting DHCPv6 shield would be unable to carry any IP >>> packets containing not only unknown IP extension headers, but also >>> packets containing unknown (to the switching fabric) protocol headers. >>> Consequently I suggested a fairly elaborate way to mitigate the risk >>> without requiring that all such packets be filtered. >>> >>> However, after discussing this at length with Fernando, I realized that >>> it was actually not at all necessary to filter unknown IPv6 headers. >>> The reason for this is that we can safely assume that any IP extension >>> header that appears in a packet conforms to RFC 6564. This means that >>> switches implementing DHCPv6 shield can at least in principle skip over >>> unknown IP extension headers. If an unknown protocol header is seen, >>> this will look to the switch like a malformed IP extension header, but >>> this is harmless in the context of DHCPv6 shield because any such packet >>> is by definition _not_ a DHCPv6 packet. I believe that a switching >>> fabric should not default to dropping packets it doesn't recognize, >>> because this pretty much guarantees that new protocols can't be deployed >>> even in site-specific situations. >>> >>> Therefore, I believe that this document should not only not require >>> filtering unknown IP extension headers, but should not even mention >>> filtering them. It may be that some implementations may need to filter >>> them for other reasons, but this is already allowed by RFC 7045, and >>> therefore needn't be mentioned here. >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> This is the original text of this DISCUSS: >>> >>> This text makes sense, but I think it needs to be changed somewhat: >>> >>> 3. When parsing the IPv6 header chain, if the packet is identified >>> to be a DHCPv6 packet meant for a DHCPv6 client or the packet >>> contains an unrecognized Next Header value, DHCPv6-Shield MUST >>> drop the packet, and SHOULD log the packet drop event in an >>> implementation-specific manner as a security alert. >>> DHCPv6-Shield MUST provide a configuration knob that controls >>> whether packets with unrecognized Next Header values are dropped; >>> this configuration knob MUST default to "drop". >>> >>> RATIONALE: An unrecognized Next Header value could possibly >>> identify an IPv6 Extension Header, and thus be leveraged to >>> conceal a DHCPv6-server packet (since there is no way for >>> DHCPv6-Shield to parse past unrecognized Next Header values >>> [I-D.gont-6man-rfc6564bis]). [RFC7045] requires that nodes be >>> configurable with respect to whether packets with unrecognized >>> headers are forwarded, and allows the default behavior to be >>> that such packets be dropped. >>> >>> I think it's worth considering whether the default setting for this >>> configuration knob should be "drop" or "pass." The problem with >>> defaulting to "drop" is that it means that extension headers the DHCPv6 >>> Shield device does not understand fail to pass, which could cause >>> operational problems. The problem with not defaulting to "drop" you >>> have already explained. I do not think that the threat of DHCPv6 >>> spoofing is sufficient to justify defaulting to drop. Yes, DHCPv6 >>> spoofing can cause operational issues. So can filtering "unknown" >>> headers. >>> >>> The frustrating thing about this document is that it actually solves the >>> problem the wrong way. What this document should recommend is filtering >>> of DHCPv6 packets from _clients_. If a rogue DHCP server can't see >>> client multicasts because DHCPv6 shield is blocking them, then it can't >>> know to attack DHCPv6 clients. This substantially limits the rogue's >>> ability to attack DHCPv6 clients on the local subnet. If you combine >>> that with server packet filtering but do not block unknown headers, I >>> think you have achieved a good tradeoff between the problems caused by >>> whatever spoofing might get to a client using an unknown header and the >>> problems caused by blocking non-DHCP packets that use that unknown header >>> for some legitimate purpose. >>> >>> So, realizing that this would be a major change, the way I would LIKE you >>> to address this discuss is to add DHCPv6 client packet filtering. You >>> could also address it by changing the default for the unknown header >>> filter, but I would understand if you felt that this was inadequate. Or >>> you could argue persuasively that I'm wrong, which has been known to >>> happen. :) >>> >>> >>> _______________________________________________ >>> OPSEC mailing list >>> OPSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsec >>> >> >> > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Feb 8 10:21:17 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874131A1B87; Sun, 8 Feb 2015 10:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaCX6ZkB9ukX; Sun, 8 Feb 2015 10:20:27 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BCD1A1B80; Sun, 8 Feb 2015 10:20:26 -0800 (PST) Received: from [186.134.12.169] (helo=[192.168.123.126]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YKWT0-00016x-7w; Sun, 08 Feb 2015 19:20:22 +0100 Message-ID: <54D7A6EB.4060604@si6networks.com> Date: Sun, 08 Feb 2015 15:11:55 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon , "C. M. Heard" References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> In-Reply-To: <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 18:20:33 -0000 On 02/08/2015 04:03 AM, Ted Lemon wrote: > On Feb 7, 2015, at 10:37 PM, C. M. Heard wrote: >> That is incorrect because extension headers and upper layer headers >> share a numbering space. Upper layer headers do NOT follow the >> format in RFC 6564. That makes it in UNSAFE to attempt to skip over >> an unknown next header value. > > I addressed that in my DISCUSS position. The fact that RA guard gives bad advice is no reason for the bad advice to be repeated in this document. The advice in RA-Guard in DHCPv6-shield is essentially 6man's advice on the topic: RFC7045. That's why we provide RFC7045 as a reference. If you don't like what the current version of the I-D says, you're not only disagreeing with it and with the "RA-Guard IMplementation advice" RFC, but also with the advice that 6man itself has produced on the topic (RFC7045). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Feb 8 10:59:42 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418641A1BDA for ; Sun, 8 Feb 2015 10:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4okY3AplhWiH for ; Sun, 8 Feb 2015 10:54:44 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA0E1A1BD9 for ; Sun, 8 Feb 2015 10:54:43 -0800 (PST) Received: (qmail 18028 invoked from network); 8 Feb 2015 10:47:58 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Feb 2015 10:47:58 -0800 Date: Sun, 8 Feb 2015 10:47:58 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Ted Lemon In-Reply-To: <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 18:54:45 -0000 On Sun, 8 Feb 2015, Ted Lemon wrote: > On Feb 7, 2015, at 10:37 PM, C. M. Heard wrote: > > That is incorrect because extension headers and upper layer headers > > share a numbering space. Upper layer headers do NOT follow the > > format in RFC 6564. That makes it in UNSAFE to attempt to skip over > > an unknown next header value. > > I addressed that in my DISCUSS position. Wherein you wrote: | If an unknown protocol header is seen, this will look to the | switch like a malformed IP extension header, but this is harmless | in the context of DHCPv6 shield because any such packet is by | definition _not_ a DHCPv6 packet. It is not necessarily true that an unknown upper layer protocol header will look like a malformed extension header to a device that assumes it is an extension header following the format in RFC 6564. If the value of the 2nd octet of the unknown header is v, then it won't appear malformed if at least 8*(v+1) bytes remain in the packet, starting from the beginning of the unknown header. At that point the device would be interpreting the payload of the unknown upper layer PDU as an extension header chain. In the benign case where the packet is a legitimate one with an upper layer protocol unknown to the device, it is likely (but not assured) that the chain would quickly terminate in something that looks like a malformed extension header. However, it would not be difficult to craft a packet that makes a very long apparent header chain. Depending on how the device processes header chains, that could easily be a vector for DOS attacks -- e.g., by consuming processing resources or by exercising a rarely used processing path. That is why I think it is UNSAFE to continue processing a header chain after encountering an unknown next header value. That being said, I think I agree with your main point: if the default for a DHCPv6-Shield device is to drop packets with unknown next header values, then a DHCPv6-Shield device will by default block unknown upper layer protocols, and that is not a desirable effect if the ONLY purpose of the device is to shield against rogue DHCPv6 packets. Perhaps a way forward would be to specify that a DHCPv6-Shield device SHOULD pass packets with unknown next header values if protection against rogue DHCPv6 packets is the ONLY purpose of the device, but it MAY default to blocking such packets (in accordance with RFC 7045) if other functionality is included. In any case, the behaviour MUST be user configurable (per RFC 7045). In my opinion, it's truly unfortunate that new IPv6 extension headers have not been banned outright in favor of using new destination options or upper layer protocol headers. That would make the correct action in this case unambiguous: pass the packet, as it's some protocol other than DHCPv6. RFC 6564 leaves the possibility of new extension headers open but raises they very high bar of proving that a new destination option or upper layer protocol header won't work. As far as I can see, that is an impossible bar to get over. > The fact that RA guard gives bad advice is no reason for the bad > advice to be repeated in this document. I agree that the advice should be the same. Mike Heard From nobody Sun Feb 8 11:25:59 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5C01ACD80; Sun, 8 Feb 2015 11:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGPZ4TsObAOC; Sun, 8 Feb 2015 11:24:27 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75401ACD7F; Sun, 8 Feb 2015 11:24:26 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 869AFDA0285; Sun, 8 Feb 2015 19:24:26 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3CCD753E07D; Sun, 8 Feb 2015 11:24:26 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sun, 8 Feb 2015 11:24:25 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Sun, 8 Feb 2015 14:24:11 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> To: "C. M. Heard" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 19:24:28 -0000 On Feb 8, 2015, at 1:47 PM, C. M. Heard wrote: > It is not necessarily true that an unknown upper layer protocol=20 > header will look like a malformed extension header to a device that=20 > assumes it is an extension header following the format in RFC 6564. =20= > If the value of the 2nd octet of the unknown header is v, then it=20 > won't appear malformed if at least 8*(v+1) bytes remain in the=20 > packet, starting from the beginning of the unknown header. At that=20 > point the device would be interpreting the payload of the unknown=20 > upper layer PDU as an extension header chain. In the benign case=20 > where the packet is a legitimate one with an upper layer protocol=20 > unknown to the device, it is likely (but not assured) that the chain=20= > would quickly terminate in something that looks like a malformed=20 > extension header. However, it would not be difficult to craft a=20 > packet that makes a very long apparent header chain. Depending on=20 > how the device processes header chains, that could easily be a=20 > vector for DOS attacks -- e.g., by consuming processing resources or=20= > by exercising a rarely used processing path. That is why I think it=20= > is UNSAFE to continue processing a header chain after encountering=20 > an unknown next header value. This may or may not be true, but to the extent that it's true, it's = already addressed in RFC 7045, and it's addressed correctly there. = There is no need to strengthen the advice in RFC 7045 here, which this = document currently does, and indeed this is completely unrelated to the = supposed purpose of the document, which is to prevent DHCP packets sent = by unauthorized servers from reaching clients. If indeed RFC 7045 is too weak and needs to be strengthened, the place = to do that is in 6man, not in opsec. Fernando tried to do that in 6man = and got no traction. If we were to allow that to be done here, it = would effectively be an end-run around the 6man working group. From nobody Sun Feb 8 15:23:11 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8344F1A1AB4 for ; Sun, 8 Feb 2015 15:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S_E45zJ3XTs for ; Sun, 8 Feb 2015 15:21:55 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486C11A6FFA for ; Sun, 8 Feb 2015 15:21:55 -0800 (PST) Received: (qmail 2573 invoked from network); 8 Feb 2015 15:21:46 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Feb 2015 15:21:46 -0800 Date: Sun, 8 Feb 2015 15:21:46 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Ted Lemon In-Reply-To: Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 23:21:56 -0000 On Sun, 8 Feb 2015, Ted Lemon wrote: > On Feb 8, 2015, at 1:47 PM, C. M. Heard wrote: > > It is not necessarily true that an unknown upper layer protocol > > header will look like a malformed extension header to a device that > > assumes it is an extension header following the format in RFC 6564. ... > This may or may not be true, but to the extent that it's true, > it's already addressed in RFC 7045, and it's addressed correctly > there. There is no need to strengthen the advice in RFC 7045 > here, which this document currently does, and indeed this is > completely unrelated to the supposed purpose of the document, > which is to prevent DHCP packets sent by unauthorized servers from > reaching clients. Would your objections be addressed if Section 3 of the draft were replaced by something along the lines of the following? =============================== cut here =============================== 3. When parsing the IPv6 header chain, if the packet contains an unrecognized Next Header value, DHCPv6-Shield MUST be configurable to pass the packet. The default configuration MAY drop such packets. When such a packet is dropped, DHCPv6-Shield SHOULD log the packet drop event in an implementation-specific manner as a security alert. RATIONALE: An unrecognized Next Header value could possibly identify an IPv6 Extension Header, and thus be leveraged to conceal a DHCPv6-server packet that should be dropped, or it may identify an unrecognized upper layer protocol, which should be passed. There is no reliable way to tell the difference. The advice given here is consistent with the requirements levied by [RFC7045] on forwarding nodes with respect to handling of unrecognized extension headers. 4. When parsing the IPv6 header chain, if the packet is identified to be a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield MUST drop the packet, and SHOULD log the packet drop event in an implementation-specific manner as a security alert. =============================== cut here =============================== //cmh From nobody Sun Feb 8 17:33:12 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D2B1A1B8A; Sun, 8 Feb 2015 17:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK_sYKaz0fLp; Sun, 8 Feb 2015 17:30:32 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12411A1B7F; Sun, 8 Feb 2015 17:30:32 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 41A24DA027B; Mon, 9 Feb 2015 01:30:32 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 00D1253E084; Sun, 8 Feb 2015 17:30:32 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sun, 8 Feb 2015 17:30:32 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Sun, 8 Feb 2015 20:30:13 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> To: "C. M. Heard" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 01:30:34 -0000 On Feb 8, 2015, at 6:21 PM, C. M. Heard wrote: > Would your objections be addressed if Section 3 of the draft were=20 > replaced by something along the lines of the following? No. This is not a draft about filtering extension headers. It is a = draft about filtering DHCP. The two are unrelated, and should not be = discussed as if they were related. From nobody Sun Feb 8 17:35:56 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443DD1A6F21; Sun, 8 Feb 2015 17:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oToa6NnJ7jiF; Sun, 8 Feb 2015 17:33:10 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 61F271A1B7F; Sun, 8 Feb 2015 17:33:10 -0800 (PST) Received: from [10.196.201.172] (10-193.icannmeeting.org [199.91.193.10]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3CF7D403BC; Sun, 8 Feb 2015 20:33:08 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Marc Blanchet In-Reply-To: <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> Date: Mon, 9 Feb 2015 09:33:04 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 01:33:12 -0000 > Le 2015-02-09 =C3=A0 09:30, Ted Lemon a =C3=A9cr= it : >=20 > On Feb 8, 2015, at 6:21 PM, C. M. Heard wrote: >> Would your objections be addressed if Section 3 of the draft were=20 >> replaced by something along the lines of the following? >=20 > No. This is not a draft about filtering extension headers. It is a = draft about filtering DHCP. The two are unrelated, and should not be = discussed as if they were related. I agree with Ted=E2=80=99s point above. The draft is about dhcpv6 not = extension headers.=20 Regards, Marc. >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From nobody Sun Feb 8 17:47:21 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EBE1A86DE for ; Sun, 8 Feb 2015 17:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.576 X-Spam-Level: * X-Spam-Status: No, score=1.576 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_POSSIBLE=2.697, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLCLVvjsFYqD for ; Sun, 8 Feb 2015 17:47:18 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F581A82E2 for ; Sun, 8 Feb 2015 17:47:17 -0800 (PST) Received: (qmail 15303 invoked from network); 8 Feb 2015 17:47:08 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Feb 2015 17:47:08 -0800 Date: Sun, 8 Feb 2015 17:47:08 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Marc Blanchet In-Reply-To: <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-1737874202-1423446428=:24776" Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , Ted Lemon , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" , The IESG Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 01:47:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---2133786286-1737874202-1423446428=:24776 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 9 Feb 2015, Marc Blanchet wrote: > > Le 2015-02-09 à 09:30, Ted Lemon a écrit : > > > > On Feb 8, 2015, at 6:21 PM, C. M. Heard wrote: > >> Would your objections be addressed if Section 3 of the draft were > >> replaced by something along the lines of the following? > > > > No. This is not a draft about filtering extension headers. It > > is a draft about filtering DHCP. The two are unrelated, and > > should not be discussed as if they were related. > > I agree with Tedÿÿs point above. The draft is about dhcpv6 not extension headers. Yes, but there is a situation in which it is not possibile to make a positive identification where a given packet is or is not a DHCPv6 packet. This should be pointed out to implementors, and the relevant requirements from RFC 7045 should be noted. I think I've made it amply clear that I disagree with the DISCUSS as it is currently written. I will now shut up and let others speak. //cmh ---2133786286-1737874202-1423446428=:24776-- From nobody Sun Feb 8 20:16:25 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712891A000F; Sun, 8 Feb 2015 20:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.787 X-Spam-Level: X-Spam-Status: No, score=0.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_POSSIBLE=2.697, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCqK3aaPCG3T; Sun, 8 Feb 2015 20:14:33 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6131A0006; Sun, 8 Feb 2015 20:14:33 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id CD4C9DA0283; Mon, 9 Feb 2015 04:14:32 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8415A53E083; Sun, 8 Feb 2015 20:14:32 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sun, 8 Feb 2015 20:14:32 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Sun, 8 Feb 2015 23:14:11 -0500 Content-Transfer-Encoding: 7bit Message-ID: <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> To: "C. M. Heard" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 04:14:34 -0000 On Feb 8, 2015, at 8:47 PM, C. M. Heard wrote: > Yes, but there is a situation in which it is not possibile to make a > positive identification where a given packet is or is not a DHCPv6 > packet. Can you carefully describe in detail how this could happen? From nobody Sun Feb 8 21:00:18 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57F61A0029; Sun, 8 Feb 2015 20:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.697 X-Spam-Level: X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_POSSIBLE=2.697, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnPFdkVXYORT; Sun, 8 Feb 2015 20:58:52 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF0B1A0027; Sun, 8 Feb 2015 20:58:52 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id eu11so9409599pac.10; Sun, 08 Feb 2015 20:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZcRPhF0LZ4YqePTGZ1009C/+GaRPuRDrGg/0tjjSSW4=; b=0Pp7qTLeiRA/XMd9gNK4CqZ+pWzIgf9DXD4kOBTnUdc2my5LX/NfSQbM/kgGfk1vKp n6HBAZI+/HFOkBUJkR8n53W0cWr8HRqmQInCQL0Kwpal70lNBbEQiRaRfSlTAx7OqmW3 TzgLb1ndaozS84DQUHM9VVpeX5gIXv4xfBy/F3ABWwWNMuQDdltT0mlQcTVIHay3NH/Q 45l18GjTjCGHHGG72KaSVPPkVLAOBN6C6q/VlgA3A9eFm0VCTNFvMj83k39xnhedLVtw sGco4bwnNiifW7bS4lf8xaLlOPXdCVMVou5U9Poj4ebnPZ/MqktFbE7p5anvgU1vPPaD si0g== X-Received: by 10.66.219.35 with SMTP id pl3mr25791964pac.32.1423457931644; Sun, 08 Feb 2015 20:58:51 -0800 (PST) Received: from ?IPv6:2406:e007:7afb:1:28cc:dc4c:9703:6781? ([2406:e007:7afb:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id f12sm15009887pat.43.2015.02.08.20.58.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Feb 2015 20:58:50 -0800 (PST) Message-ID: <54D83E7F.3040207@gmail.com> Date: Mon, 09 Feb 2015 17:58:39 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon , "C. M. Heard" References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> In-Reply-To: <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 04:58:54 -0000 On 09/02/2015 17:14, Ted Lemon wrote: > On Feb 8, 2015, at 8:47 PM, C. M. Heard wrote: >> Yes, but there is a situation in which it is not possibile to make a >> positive identification where a given packet is or is not a DHCPv6 >> packet. > > Can you carefully describe in detail how this could happen? Ted, I think we have to say Hi to the elephant in the corner of the room. There is a fundamental flaw in the IPv6 design, which is that there is no way, in the general case, to distinguish an unknown extension header from an unknown upper layer protocol. Now this doesn't matter too much in a middlebox-free Internet, since (with the well-specified exception of the hop-by-hop header) nobody ever needs to make that distinction, since unknowns cause a packet drop at the destination anyway. Steve Deering told me in Vancouver that this is just fine, because middleboxes are evil anyway. But that doesn't wash. A middlebox that is trying to flush out a specific type of upper layer protocol (such as DHCPv6) needs to parse all extension headers, including ones it doesn't understand, in case there is an instance of the upper layer protocol behind it. In the real world, that means that such middleboxes, if they are of the paranoid security persuasion, will discard packets that, as far as they are concerned, are unparseable. I'm afraid that IETF documents that don't recognise this fact of life will not be taken seriously. Brian From nobody Sun Feb 8 21:02:09 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1115C1A0032; Sun, 8 Feb 2015 21:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEzR7jU0gkSY; Sun, 8 Feb 2015 21:02:06 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E7B1A0027; Sun, 8 Feb 2015 21:02:06 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id B4769DA01DD; Mon, 9 Feb 2015 05:02:06 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 80ECF53E083; Sun, 8 Feb 2015 21:02:06 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sun, 8 Feb 2015 21:02:06 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54D83E7F.3040207@gmail.com> Date: Mon, 9 Feb 2015 00:01:43 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 05:02:08 -0000 On Feb 8, 2015, at 11:58 PM, Brian E Carpenter = wrote: > A middlebox that is trying to flush out a specific type of > upper layer protocol (such as DHCPv6) needs to parse all extension > headers, including ones it doesn't understand, in case there is > an instance of the upper layer protocol behind it. >=20 > In the real world, that means that such middleboxes, if they are > of the paranoid security persuasion, will discard packets that, > as far as they are concerned, are unparseable. Can you explain, in detail, what a DHCPv6 packet would look like that = would get past a filter because either it used unknown extension = headers, or an unknown protocol header? From nobody Sun Feb 8 21:05:09 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E971A0035; Sun, 8 Feb 2015 21:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExIoH9hdUYwz; Sun, 8 Feb 2015 21:04:20 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCB61A0027; Sun, 8 Feb 2015 21:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1423458260; x=1454994260; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/mAPYhbR0K2vTJaZ8sV+KoFYN1gcQrmuxE2WV3cefxU=; b=X4C32LcTBE7WZqfyZOW5Wu3FTHLJRxnjBoZbaZIPnjjk0qJtNRKTXWP7 +/SaNtH+yCFHjVO1fVWR6CSRqI6k6N7LW3rv+hKXBW1bXlR3gPmjqnoFO 9V62n8fxN7fzD/atnMZ/oPi4W/oFJkTVF7Lv1fXvjevk7IGqmuXqCumqc c=; X-IronPort-AV: E=McAfee;i="5600,1067,7706"; a="82932267" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2015 21:04:20 -0800 X-IronPort-AV: E=Sophos;i="5.09,541,1418112000"; d="scan'208";a="847464807" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Feb 2015 21:04:20 -0800 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sun, 8 Feb 2015 21:04:16 -0800 Message-ID: <54D83FCE.4070804@qti.qualcomm.com> Date: Sun, 8 Feb 2015 23:04:14 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ted Lemon References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01H.na.qualcomm.com (10.85.0.34) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 05:04:22 -0000 On 2/8/15 11:01 PM, Ted Lemon wrote: > On Feb 8, 2015, at 11:58 PM, Brian E Carpenter wrote: > >> A middlebox that is trying to flush out a specific type of >> upper layer protocol (such as DHCPv6) needs to parse all extension >> headers, including ones it doesn't understand, in case there is >> an instance of the upper layer protocol behind it. >> >> In the real world, that means that such middleboxes, if they are >> of the paranoid security persuasion, will discard packets that, >> as far as they are concerned, are unparseable. >> > Can you explain, in detail, what a DHCPv6 packet would look like that would get past a filter because either it used unknown extension headers, or an unknown protocol header? > Better yet, could you give an example packet with a fake new extension header that a middlebox would think is not a DHCPv6 packet, but in fact is? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Feb 8 22:11:06 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95541A006D for ; Sun, 8 Feb 2015 22:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxCBgGGL_AJ0 for ; Sun, 8 Feb 2015 22:08:58 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42EE1A006F for ; Sun, 8 Feb 2015 22:08:56 -0800 (PST) Received: (qmail 27498 invoked from network); 8 Feb 2015 22:02:04 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Feb 2015 22:02:04 -0800 Date: Sun, 8 Feb 2015 22:02:04 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Pete Resnick In-Reply-To: <54D83FCE.4070804@qti.qualcomm.com> Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , Ted Lemon , "opsec-chairs@ietf.org" , Brian E Carpenter , The IESG Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 06:09:00 -0000 On Sun, 8 Feb 2015, Pete Resnick wrote: > On 2/8/15 11:01 PM, Ted Lemon wrote: > > Can you explain, in detail, what a DHCPv6 packet would look like that would > > get past a filter because either it used unknown extension headers, or an > > unknown protocol header? > > > > Better yet, could you give an example packet with a fake new extension header > that a middlebox would think is not a DHCPv6 packet, but in fact is? Not with a fake extension header, but with a real one. Suppose: - A new extension header is defined that make sense to sandwich in front of a DHCPv6 packet (not all do; some extension headers are required to have a next header value of "no next header") - This extension header is unknowm to a DHCPv6-Shield implementation - This is extension header is known and considered valid by a host that DHCPv6-Shield implementation is trying to protect If I correctly understand Ted's position, he is saying that a DHCPv6-Shield implementation should unconditionally pass a packet containing a next header value it does not recognize. In that case, a DHCPv6 packet containing the hypothesized new extension header described above would pass through the DHCPv6-Shield implementation and be processed by the host. The current DHCPv6-Shield draft (and the variant language I proposed a few messages back) takes the position that whether a DHCPv6-Shield implementation passes a packet with an unknown next header value must be a user configurable option. Some users may consider the above scenario too improbable to worry about and configure packets with unknown next header values to be passed. Other users of a more paranoid persuation may have a different point of view. Sorry, I said I was going to shut up. Now I will. //cmh From nobody Mon Feb 9 05:12:09 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D4E1A039A; Mon, 9 Feb 2015 05:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QxNtsgltHlT; Mon, 9 Feb 2015 05:11:59 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4AD1A00EA; Mon, 9 Feb 2015 05:11:59 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id E575D880F5; Mon, 9 Feb 2015 05:11:58 -0800 (PST) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1ED1F71B0001; Mon, 9 Feb 2015 05:11:56 -0800 (PST) Message-ID: <54D8B220.2030204@innovationslab.net> Date: Mon, 09 Feb 2015 08:12:00 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "C. M. Heard" , Pete Resnick References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RjXOffUAQUSosDWSGcn2G7gGgjQh2rEqS" Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , Ted Lemon , "opsec-chairs@ietf.org" , Brian E Carpenter , The IESG Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 13:12:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RjXOffUAQUSosDWSGcn2G7gGgjQh2rEqS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Let me chime in here with two points... On 2/9/15 1:02 AM, C. M. Heard wrote: > On Sun, 8 Feb 2015, Pete Resnick wrote: >> On 2/8/15 11:01 PM, Ted Lemon wrote: >>> Can you explain, in detail, what a DHCPv6 packet would look like that= would >>> get past a filter because either it used unknown extension headers, o= r an >>> unknown protocol header? >>> =20 >> >> Better yet, could you give an example packet with a fake new extension= header >> that a middlebox would think is not a DHCPv6 packet, but in fact is? >=20 > Not with a fake extension header, but with a real one. Suppose: >=20 > - A new extension header is defined that make sense to sandwich in=20 > front of a DHCPv6 packet (not all do; some extension headers are=20 > required to have a next header value of "no next header") >=20 > - This extension header is unknowm to a DHCPv6-Shield implementation >=20 > - This is extension header is known and considered valid by a host=20 > that DHCPv6-Shield implementation is trying to protect The above is a typical scenario where different code bases update their capabilities on different time scales. Any time a new feature/function is added, there will be a risk of incompatible functionality within the set of devices that compose the network path from source to destination. >=20 > If I correctly understand Ted's position, he is saying that a=20 > DHCPv6-Shield implementation should unconditionally pass a packet=20 > containing a next header value it does not recognize. In that case,=20 > a DHCPv6 packet containing the hypothesized new extension header=20 > described above would pass through the DHCPv6-Shield implementation=20 > and be processed by the host. I have interpreted Ted's position to be that this document should simply point to RFC 7045 (or its successor) for handling unknown extension heade= rs. Regards, Brian --RjXOffUAQUSosDWSGcn2G7gGgjQh2rEqS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU2LInAAoJEBOZRqCi7goqeqcH/ji6bsEVGx+xqi1JTUpGp0iz 62/tnNoAq/HLiNd2Il9UdfwbhyqYbebs097n5Au2mMPhLJZCQQFof31+mLr3GW0o XX3Ykb+WYiBIFL1MlgHu033ZqiHiuh5psq7kJQ8YUH7QhWyv6na/PZu8IWPfEfUK /6xk6ygGBbYSABbF6aBVLE0DFttZ2mGVN7DwjIhcnL3p/hNu4QknjnH8tjB+ntUt YPErK0MU/2nlzQoxJz/8s8p+T2nZbL4oAkU0bXziXN1AA/2OACE2yiJlGhLmJiIP PyQcFERScj5dD6JS42vunkUAcLEB2FG2XgoBooU2uIYjDcWk3pnBizanCJSJ2Io= =Mfu7 -----END PGP SIGNATURE----- --RjXOffUAQUSosDWSGcn2G7gGgjQh2rEqS-- From nobody Mon Feb 9 06:59:05 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983BB1A044D; Mon, 9 Feb 2015 06:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFi9ywamPpid; Mon, 9 Feb 2015 06:42:00 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7EF41A046D; Mon, 9 Feb 2015 06:41:58 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 9B0F6DA028F; Mon, 9 Feb 2015 14:41:58 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4FDE653E082; Mon, 9 Feb 2015 06:41:58 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 9 Feb 2015 06:41:58 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 9 Feb 2015 09:41:53 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> To: "C. M. Heard" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 14:42:01 -0000 On Feb 9, 2015, at 1:02 AM, C. M. Heard wrote: > - A new extension header is defined that make sense to sandwich in=20 > front of a DHCPv6 packet (not all do; some extension headers are=20 > required to have a next header value of "no next header") >=20 > - This extension header is unknowm to a DHCPv6-Shield implementation >=20 > - This is extension header is known and considered valid by a host=20 > that DHCPv6-Shield implementation is trying to protect In addition to being known by the host, the extension header would have = to be a standard extension header that does not conform to RFC 6564. = Otherwise, the switch can just skip over it even though it's nominally = "unknown." Having skipped over it, it would correctly reach the UDP = protocol header, and notice that the packet was a DHCP packet. I think it's safe to assume that no future extension header that is = standardized will fail to conform to RFC 6564. Hence, we do not need = to worry that the host will be able to parse a new extension header, but = that the DHCPv6-shield device will not. Hence, there is no need to = drop packets with unknown extension headers. This is particularly important, because in dropping packets with unknown = extension headers, we are _also_ dropping packets with unknown protocol = headers. That is the real harm of the language of the document as it = is currently written. From nobody Mon Feb 9 07:26:28 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B50B1A1A25 for ; Mon, 9 Feb 2015 07:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzHNqst1joKw for ; Mon, 9 Feb 2015 07:08:14 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D291A1A12 for ; Mon, 9 Feb 2015 07:08:14 -0800 (PST) Received: (qmail 26211 invoked from network); 9 Feb 2015 07:08:12 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2015 07:08:11 -0800 Date: Mon, 9 Feb 2015 07:08:11 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Brian Haberman In-Reply-To: <54D8B220.2030204@innovationslab.net> Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <54D8B220.2030204@innovationslab.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , Ted Lemon , "opsec-chairs@ietf.org" , Brian E Carpenter , The IESG Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 15:08:16 -0000 On Mon, 9 Feb 2015, Brian Haberman wrote: > I have interpreted Ted's position to be that this document should simply > point to RFC 7045 (or its successor) for handling unknown extension headers. I am probably confused, but the intended substance of the proposal in http://www.ietf.org/mail-archive/web/opsec/current/msg01819.html was just that, and it got rejected. //cmh From nobody Mon Feb 9 08:19:08 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F5D1A1A81 for ; Mon, 9 Feb 2015 08:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YaYttyMi1v3 for ; Mon, 9 Feb 2015 08:11:24 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFF41A1A83 for ; Mon, 9 Feb 2015 08:11:23 -0800 (PST) Received: (qmail 14620 invoked from network); 9 Feb 2015 08:11:20 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2015 08:11:20 -0800 Date: Mon, 9 Feb 2015 08:11:20 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Ted Lemon In-Reply-To: <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 16:11:29 -0000 On Mon, 9 Feb 2015, Ted Lemon wrote: > In addition to being known by the host, the extension header would > have to be a standard extension header that does not conform to > RFC 6564. Otherwise, the switch can just skip over it even though > it's nominally "unknown." That, unfortunately, is not true, as I have been trying repeatedly to explain. When the switch encounters an unknown next header value, it does not know if that refers to a new extension header, which is required to conform to the format of RFC 6564, or an upper layer protocol header, which is NOT required to conform to RFC 6564. As I argue in http://www.ietf.org/mail-archive/web/opsec/current/msg01817.html, the switch opens itself up to DOS attacks if it assumes that any unknown header in the chain conforms to RFC 6564 and attempts to continue parsing the header chain. RFC 6564 gives the misleading impression that it actually solves a problem. It does not. This is at least the third time I've seem this discussion has come up. For that reason it's time to retire RFC 6564, but that of course is a job for 6man, not opsec. There was some discussion of this problem in 6man -- one proposal was draft-gont-6man-rfc6564bis, discussed Feb-May 2014 (see, e.g., http://www.ietf.org/mail-archive/web/ipv6/current/msg20710.html). 6man never came to consensus that the problem was sufficiently important to solve, but I think the current discussion has hughlighted the importance of putting it to rest. Secifically: > ... in dropping packets with unknown extension headers, we are > _also_ dropping packets with unknown protocol headers. That is > the real harm of the language of the document as it is currently > written. THAT is a very a real problem in an Internet full of middleboxes. It would be fixed if the set of extension headers were closed off to further expansion. Multiple technically viable ways to do this without sacrificing functionality have been proposed; this discussion sould, I hope, provide the motivation needed to get 6man to adopt one of those solutions (or something similar). Sorry for the digression, but I think it was necessary to understand the problem. //cmh From nobody Mon Feb 9 08:37:02 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BBB1A1B56; Mon, 9 Feb 2015 08:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YNybdoGtVbq; Mon, 9 Feb 2015 08:36:35 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05731A1B2D; Mon, 9 Feb 2015 08:33:58 -0800 (PST) Received: from mb-aye.local (64.125.197.170.IPYX-102339-ZYO.zip.zayo.com [64.125.197.170] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t19GXuWt003663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Feb 2015 16:33:56 GMT (envelope-from joelja@bogus.com) Message-ID: <54D8E16D.4030402@bogus.com> Date: Mon, 09 Feb 2015 08:33:49 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: "C. M. Heard" , Ted Lemon References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2k2KPuI7GPRrNu601PktOENG2nlc4DjSv" Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 16:36:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2k2KPuI7GPRrNu601PktOENG2nlc4DjSv Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/9/15 8:11 AM, C. M. Heard wrote: > On Mon, 9 Feb 2015, Ted Lemon wrote: >> In addition to being known by the host, the extension header would=20 >> have to be a standard extension header that does not conform to=20 >> RFC 6564. Otherwise, the switch can just skip over it even though=20 >> it's nominally "unknown." >=20 > That, unfortunately, is not true, as I have been trying repeatedly=20 > to explain. >=20 > When the switch encounters an unknown next header value, it does not=20 > know if that refers to a new extension header, which is required to=20 > conform to the format of RFC 6564, or an upper layer protocol=20 > header, which is NOT required to conform to RFC 6564. So the problem I have in application is if i'm applying an acl with an L4 rule I have to find the upper layer header. If I can't parse the header chain the packet is hitting a drop rule. if I can jumper over a header due to 6564 and find the the L4 header then great, if I can't, that packet is getting dropped. > As I argue in=20 > http://www.ietf.org/mail-archive/web/opsec/current/msg01817.html,=20 > the switch opens itself up to DOS attacks if it assumes that any=20 > unknown header in the chain conforms to RFC 6564 and attempts to=20 > continue parsing the header chain. in a device such a switch, I'm going to have to give up long before this happens becasue the amount of the packet going towards the header processing is only 64/128/256 bytes so I'm going to drop it if I don't have that offset available to me. I do think what you describe is a serious problem. We do have a bunch of dos options to avail ourselves of on devices that can be assumed to be capable of processing arbitrary header chains. If such devices existed in my network I'd have to protect them with much simpler devices. > RFC 6564 gives the misleading impression that it actually solves a=20 > problem. It does not. This is at least the third time I've seem=20 > this discussion has come up. For that reason it's time to retire=20 > RFC 6564, but that of course is a job for 6man, not opsec. >=20 > There was some discussion of this problem in 6man -- one proposal=20 > was draft-gont-6man-rfc6564bis, discussed Feb-May 2014 (see, e.g.,=20 > http://www.ietf.org/mail-archive/web/ipv6/current/msg20710.html). =20 > 6man never came to consensus that the problem was sufficiently=20 > important to solve, but I think the current discussion has=20 > hughlighted the importance of putting it to rest. Secifically: >=20 >> ... in dropping packets with unknown extension headers, we are=20 >> _also_ dropping packets with unknown protocol headers. That is=20 >> the real harm of the language of the document as it is currently=20 >> written. >=20 > THAT is a very a real problem in an Internet full of middleboxes. =20 > It would be fixed if the set of extension headers were closed off to=20 > further expansion. Multiple technically viable ways to do this=20 > without sacrificing functionality have been proposed; this=20 > discussion sould, I hope, provide the motivation needed to get 6man=20 > to adopt one of those solutions (or something similar). >=20 > Sorry for the digression, but I think it was necessary to understand=20 > the problem. >=20 > //cmh >=20 --2k2KPuI7GPRrNu601PktOENG2nlc4DjSv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTY4W4ACgkQ8AA1q7Z/VrK2IgCbB0Y4CSF7lE1BCLFk/F/EX5QZ uKIAnjakNvy7uFWaDgotJYdYwmx1/QEi =QrLR -----END PGP SIGNATURE----- --2k2KPuI7GPRrNu601PktOENG2nlc4DjSv-- From nobody Mon Feb 9 09:03:39 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0704A1A1ACE; Mon, 9 Feb 2015 08:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31DD6xyXDfEz; Mon, 9 Feb 2015 08:45:24 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9AD1A1ADB; Mon, 9 Feb 2015 08:45:00 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 13C9FDA0219; Mon, 9 Feb 2015 16:45:00 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D5AF253E07D; Mon, 9 Feb 2015 08:44:59 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 9 Feb 2015 08:44:59 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 9 Feb 2015 11:44:52 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> To: "C. M. Heard" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 16:45:26 -0000 On Feb 9, 2015, at 11:11 AM, C. M. Heard wrote: > As I argue in=20 > http://www.ietf.org/mail-archive/web/opsec/current/msg01817.html,=20 > the switch opens itself up to DOS attacks if it assumes that any=20 > unknown header in the chain conforms to RFC 6564 and attempts to=20 > continue parsing the header chain. Yes, you made this argument. But how does this constitute a DoS = attack? You have a 1500 byte packet, and you have some kind of = fast-path hardware that's trying to parse the packet. At some point it = will either succeed or fail. Most such hardware doesn't even look very = far into the packet--maybe 256 bytes at most. I asked you earlier in this conversation to describe a specific attack, = not make general speculations. Can you describe a specific attack here = and explain why it is bad? Remember that we are specifically talking = about filtering DHCPv6 here, not solving the general problem of = eliminating possibly bogus packets at the switching fabric so that hosts = don't see them. Remember too that the packet has to actually be _valid_ when it's = forwarded to the host: it's not sufficient that it simply make it = through the filter. Otherwise the host will not see it as a DHCPv6 = packet, and the shield will have succeeded even though it passed the = packet. So the packet has to use a valid chain of extension headers = that the host can successfully parse, even if they are unknown to the = switch. Can you describe an attack that works in the presence of all these = requirements?= From nobody Mon Feb 9 11:31:13 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313F81A8724; Mon, 9 Feb 2015 11:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEBvJAmHvKkO; Mon, 9 Feb 2015 11:10:18 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18441A7029; Mon, 9 Feb 2015 11:10:12 -0800 (PST) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YKtia-0007u1-4C; Mon, 09 Feb 2015 20:10:00 +0100 Message-ID: <54D8F98D.1030101@si6networks.com> Date: Mon, 09 Feb 2015 15:16:45 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon , "C. M. Heard" References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> In-Reply-To: <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:10:23 -0000 Ted, Please let me describe a scenario for an attack that would work if we don't enforce the filtering rules from the current version of the I-D. Before getting into the specific details, please let me provide some background. ** Background ** * As have been noted multiple times, IPv6 Extension Headers and Transport Protocols share the same name space. Given an unrecognized/unknown EH/Protocol type, there's no way for you to know how to parse it: since it could be ether an EH, or a transport protocol. * RFC6564 has a major flaw, since it defines a "unified format for EHs". But per the above, it is impossible to tell when you should assume that what follows is an EH (in RFC6564 format) or a new transport protocol. * There's nothing that we can do to fix RFC6564 itself in this respect. The only possible option is to replace RFC6564 with something such as: . Regardless of whether the IETF decides to fix this problem or not, the problem is there. * If you assume that an unrecognized header follows the format in RFC6564, you will hurt the deployment of new transport protocols. * RFC7045 is the current IETF advice on the topic. DHCPv6 shield complies with it -- as noted a few times... even by Brian Carpenter (co-author of the aforementioned document). If you disagree with what DHCPv6-shield is currently doing, you're essentially disagreeing with 6man's advice on the topic. ** Attack scenario ** 1) Let us assume that either a new EH that doesn't follow RFC6564 is specified (since, as noted, RFC6564 doesn't buy you anything), or that the proposal in draft-gont-6man-rfc6564bis-00 gets standardized, and hence new EHs follow the EH format in that document. 2) Such EH, according to the rules you had proposed (namely "assume RFC6564 for unrecognized headers"), would be passed/allowed, since it would be considered a "transport protocol" rather than an EH. 3) Now, let us assume that such EH has been implemented by a target host. An attacker could send a DHCPv6-server packet with includes one of the aforementioned EHs. The DHCPv6-shiled device would (according to your rules) pass this packet, and the target host would receive it. 4) As a result of the above, an attacker would have been able to sneak a DHCPv6-server packet past the DHCPv6 shield device. This is an attack vector we mean to block. The current version of DHCPv6-shield would block it. If we were to modify the document as you suggest, it wouldn't. Thanks, Fernando On 02/09/2015 01:44 PM, Ted Lemon wrote: > On Feb 9, 2015, at 11:11 AM, C. M. Heard wrote: >> As I argue in >> http://www.ietf.org/mail-archive/web/opsec/current/msg01817.html, >> the switch opens itself up to DOS attacks if it assumes that any >> unknown header in the chain conforms to RFC 6564 and attempts to >> continue parsing the header chain. > > Yes, you made this argument. But how does this constitute a DoS attack? You have a 1500 byte packet, and you have some kind of fast-path hardware that's trying to parse the packet. At some point it will either succeed or fail. Most such hardware doesn't even look very far into the packet--maybe 256 bytes at most. > > I asked you earlier in this conversation to describe a specific attack, not make general speculations. Can you describe a specific attack here and explain why it is bad? Remember that we are specifically talking about filtering DHCPv6 here, not solving the general problem of eliminating possibly bogus packets at the switching fabric so that hosts don't see them. > > Remember too that the packet has to actually be _valid_ when it's forwarded to the host: it's not sufficient that it simply make it through the filter. Otherwise the host will not see it as a DHCPv6 packet, and the shield will have succeeded even though it passed the packet. So the packet has to use a valid chain of extension headers that the host can successfully parse, even if they are unknown to the switch. > > Can you describe an attack that works in the presence of all these requirements? > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 9 11:33:59 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE711A7029; Mon, 9 Feb 2015 11:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdfYLYfORcuR; Mon, 9 Feb 2015 11:10:41 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291CD1A6FF0; Mon, 9 Feb 2015 11:10:33 -0800 (PST) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YKtj2-0007ui-D1; Mon, 09 Feb 2015 20:10:28 +0100 Message-ID: <54D90317.4070205@si6networks.com> Date: Mon, 09 Feb 2015 15:57:27 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon , "C. M. Heard" References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:10:42 -0000 On 02/08/2015 04:24 PM, Ted Lemon wrote: > On Feb 8, 2015, at 1:47 PM, C. M. Heard wrote: >> It is not necessarily true that an unknown upper layer protocol >> header will look like a malformed extension header to a device that >> assumes it is an extension header following the format in RFC >> 6564. If the value of the 2nd octet of the unknown header is v, >> then it won't appear malformed if at least 8*(v+1) bytes remain in >> the packet, starting from the beginning of the unknown header. At >> that point the device would be interpreting the payload of the >> unknown upper layer PDU as an extension header chain. In the >> benign case where the packet is a legitimate one with an upper >> layer protocol unknown to the device, it is likely (but not >> assured) that the chain would quickly terminate in something that >> looks like a malformed extension header. However, it would not be >> difficult to craft a packet that makes a very long apparent header >> chain. Depending on how the device processes header chains, that >> could easily be a vector for DOS attacks -- e.g., by consuming >> processing resources or by exercising a rarely used processing >> path. That is why I think it is UNSAFE to continue processing a >> header chain after encountering an unknown next header value. > > This may or may not be true, but to the extent that it's true, it's > already addressed in RFC 7045, and it's addressed correctly there. > There is no need to strengthen the advice in RFC 7045 here, which > this document currently does Why do you think this document "strengthens the advice in RFC7045", as opposed to it actually *complying* with what's in RFC7045? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 9 11:37:04 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B92A1A8745; Mon, 9 Feb 2015 11:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v1UIgpxV0rE; Mon, 9 Feb 2015 11:10:57 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD471A873A; Mon, 9 Feb 2015 11:10:54 -0800 (PST) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YKtjO-0007vY-FV; Mon, 09 Feb 2015 20:10:50 +0100 Message-ID: <54D905C6.20007@si6networks.com> Date: Mon, 09 Feb 2015 16:08:54 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Brian Haberman , "C. M. Heard" , Pete Resnick References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <54D8B220.2030204@innovationslab.net> In-Reply-To: <54D8B220.2030204@innovationslab.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , Ted Lemon , "opsec-chairs@ietf.org" , Brian E Carpenter , The IESG Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:10:58 -0000 Hi, Brian, On 02/09/2015 10:12 AM, Brian Haberman wrote: [....] >>> Better yet, could you give an example packet with a fake new >>> extension header that a middlebox would think is not a DHCPv6 >>> packet, but in fact is? >> >> Not with a fake extension header, but with a real one. Suppose: >> >> - A new extension header is defined that make sense to sandwich >> in front of a DHCPv6 packet (not all do; some extension headers >> are required to have a next header value of "no next header") >> >> - This extension header is unknowm to a DHCPv6-Shield >> implementation >> >> - This is extension header is known and considered valid by a >> host that DHCPv6-Shield implementation is trying to protect > > The above is a typical scenario where different code bases update > their capabilities on different time scales. Any time a new > feature/function is added, there will be a risk of incompatible > functionality within the set of devices that compose the network > path from source to destination. Exactly. The same applies to Ted's concern: the newly-specified IPv6 EH would be "incorporated" by DHCPv6 implementations and hence would not be dropped. >> If I correctly understand Ted's position, he is saying that a >> DHCPv6-Shield implementation should unconditionally pass a packet >> containing a next header value it does not recognize. In that >> case, a DHCPv6 packet containing the hypothesized new extension >> header described above would pass through the DHCPv6-Shield >> implementation and be processed by the host. > > I have interpreted Ted's position to be that this document should > simply point to RFC 7045 (or its successor) for handling unknown > extension headers. It doesn't seem to be so. Brian Carpenter himself (co-author of RFC7045) noted that we comply with RFC7045. We simply state what the default should be, and normatively reference RF7045, since that's the document on which we've based our requirements. So I don't understand what's the issue here, since we *are* complying with the current (6man's) recommendations on the topic. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 9 11:49:14 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18231A877B; Mon, 9 Feb 2015 11:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hek-bNxwTOPp; Mon, 9 Feb 2015 11:18:31 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869641A8781; Mon, 9 Feb 2015 11:17:59 -0800 (PST) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YKtqE-0007xI-63; Mon, 09 Feb 2015 20:17:54 +0100 Message-ID: <54D9072F.9020406@si6networks.com> Date: Mon, 09 Feb 2015 16:14:55 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon , "C. M. Heard" References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> In-Reply-To: <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:18:33 -0000 On 02/09/2015 11:41 AM, Ted Lemon wrote: > On Feb 9, 2015, at 1:02 AM, C. M. Heard wrote: >> - A new extension header is defined that make sense to sandwich in >> front of a DHCPv6 packet (not all do; some extension headers are >> required to have a next header value of "no next header") >> >> - This extension header is unknowm to a DHCPv6-Shield >> implementation >> >> - This is extension header is known and considered valid by a host >> that DHCPv6-Shield implementation is trying to protect > > In addition to being known by the host, the extension header would > have to be a standard extension header that does not conform to RFC > 6564. Otherwise, the switch can just skip over it even though it's > nominally "unknown." Having skipped over it, it would correctly > reach the UDP protocol header, and notice that the packet was a DHCP > packet. > > I think it's safe to assume that no future extension header that is > standardized will fail to conform to RFC 6564. It is not. As noted, RFC6564 doesn't buy you anything. And if we decide to fix the problem in question (e.g., as described in draft-gont-6man-rfc6564bis-00.txt), then I can guarantee that new IPv6 EHs will *not* follow the format in RFC6564. (And I'd say that "assumptions" have been the source of most security flaws in protocols and implementations I've seen). > Hence, we do not > need to worry that the host will be able to parse a new extension > header, but that the DHCPv6-shield device will not. Hence, there is > no need to drop packets with unknown extension headers. > > This is particularly important, because in dropping packets with > unknown extension headers, we are _also_ dropping packets with > unknown protocol headers. That is the real harm of the language of > the document as it is currently written. You can't be worried about new transport protocols and at the same time support RFC6564. If you assume that new EHs will follow RFC6564, then you're banning *from scratch* deployment of new transport protocols (!). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 9 11:53:54 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032921A8765; Mon, 9 Feb 2015 11:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzxlgAQMzF5n; Mon, 9 Feb 2015 11:23:35 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716F71A8785; Mon, 9 Feb 2015 11:23:35 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 1F46BDA0213; Mon, 9 Feb 2015 19:23:35 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E17D353E080; Mon, 9 Feb 2015 11:23:34 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 9 Feb 2015 11:23:34 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54D8F98D.1030101@si6networks.com> Date: Mon, 9 Feb 2015 14:23:28 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:23:37 -0000 On Feb 9, 2015, at 1:16 PM, Fernando Gont wrote: > 1) Let us assume that either a new EH that doesn't follow RFC6564 is > specified (since, as noted, RFC6564 doesn't buy you anything), or that > the proposal in draft-gont-6man-rfc6564bis-00 gets standardized, and > hence new EHs follow the EH format in that document. Come on, Fernando, this is ridiculous. RFC 6564 is normative. We = should not expect new EHs to be standardized that do not conform with = RFC 6564. From nobody Mon Feb 9 12:29:27 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767151A1EF2; Mon, 9 Feb 2015 11:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-vN6Fq0JZMi; Mon, 9 Feb 2015 11:47:55 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB041A1DFA; Mon, 9 Feb 2015 11:47:55 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id ey11so11569676pad.11; Mon, 09 Feb 2015 11:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hdZUmHv6e3yX4mqRtifsS0PBNaa77nifByIUR3zlB9U=; b=afHAQCSU1gqjVe24A+718IkWXVjtUyABVVTFSsfm7+xq45b+7vThdgcojxf83iErt2 2peCJjFNiT+Pz/kgsWIjcDXvo4of/qVB5P/zRuCcpT2mIoLEhmZYvdyYKVHz0GzPYcJq 1U3mZhqKqDX6kCkDy+2HKziobdgfhVNWmI+sASCeAg6oHfO1VyB5yIybR9ugioPCzKSb 2cs/XF1n1djsJ8NfTmN251aNQNUE17USAPsTEDzILtGF+fCeOFx///uGaWRtAjJTal7z 6mom8LQfnQL+YprQMz265t1Gb30hXD47R/aNDM3CviVKRlP0Kt3i/mY7ON/8V+SfYSfm eJaw== X-Received: by 10.70.38.3 with SMTP id c3mr32011761pdk.154.1423511274876; Mon, 09 Feb 2015 11:47:54 -0800 (PST) Received: from ?IPv6:2406:e007:4f88:1:28cc:dc4c:9703:6781? ([2406:e007:4f88:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id j10sm17170107pdr.37.2015.02.09.11.47.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Feb 2015 11:47:53 -0800 (PST) Message-ID: <54D90EE5.2060002@gmail.com> Date: Tue, 10 Feb 2015 08:47:49 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon , Fernando Gont References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:47:57 -0000 On 10/02/2015 08:23, Ted Lemon wrote: > On Feb 9, 2015, at 1:16 PM, Fernando Gont wrote: >> 1) Let us assume that either a new EH that doesn't follow RFC6564 is >> specified (since, as noted, RFC6564 doesn't buy you anything), or that >> the proposal in draft-gont-6man-rfc6564bis-00 gets standardized, and >> hence new EHs follow the EH format in that document. > > Come on, Fernando, this is ridiculous. RFC 6564 is normative. We should not expect new EHs to be standardized that do not conform with RFC 6564. Fair enough. But let's just say that DHCPv6 Shield sees a Next Header value of 253. How does it know where to look for a potential UDP header with port 546? If you don't like 253 as an example, how about 143, or any other value that isn't listed at http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header I simply don't believe that any security product designer will do anything except give up and discard the packet. Don't we want RFCs to live in the real world? Brian From nobody Mon Feb 9 12:36:34 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFF21A1DFA; Mon, 9 Feb 2015 11:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogBhhR1wx-cw; Mon, 9 Feb 2015 11:53:03 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67771A212A; Mon, 9 Feb 2015 11:52:49 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id B3162DA0266; Mon, 9 Feb 2015 19:52:49 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 9BEF253E080; Mon, 9 Feb 2015 11:52:49 -0800 (PST) Received: from vpna-188.vpn.nominum.com (64.89.227.188) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 9 Feb 2015 11:52:49 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54D90EE5.2060002@gmail.com> Date: Mon, 9 Feb 2015 14:52:39 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [64.89.227.188] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , Fernando Gont , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:53:05 -0000 On Feb 9, 2015, at 2:47 PM, Brian E Carpenter = wrote: > Fair enough. But let's just say that DHCPv6 Shield sees a Next Header > value of 253. How does it know where to look for a potential UDP > header with port 546? Either the next header is an unknown EH conforming to RFC 6564, or else = it is a protocol header. If it is a protocol header, then it is an = unknown protocol header, and therefore not a UDP header. If it = conforms to RFC 6564, then it can be successfully skipped, whether or = not it is known. > I simply don't believe that any security product designer will do > anything except give up and discard the packet. Don't we want RFCs > to live in the real world? We want RFCs to recommend the right thing. It is likely true that at = present, the implementor of a switch that implements DHCPv6 shield may = cut some corners on processing of unknown headers. However, this is = not something the IETF should recommend they do, because our = recommendations will last longer than the current state of the art. = There is no reason to cast the limitations of the current state of the = art in stone.= From nobody Mon Feb 9 13:18:26 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261651A88CF; Mon, 9 Feb 2015 12:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOzITA-Xo0md; Mon, 9 Feb 2015 12:27:33 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2741A88C8; Mon, 9 Feb 2015 12:27:33 -0800 (PST) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YKuvS-0008IQ-IA; Mon, 09 Feb 2015 21:27:23 +0100 Message-ID: <54D91806.9070004@si6networks.com> Date: Mon, 09 Feb 2015 17:26:46 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon , Brian E Carpenter References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> In-Reply-To: <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 20:27:36 -0000 On 02/09/2015 04:52 PM, Ted Lemon wrote: > On Feb 9, 2015, at 2:47 PM, Brian E Carpenter > wrote: >> Fair enough. But let's just say that DHCPv6 Shield sees a Next >> Header value of 253. How does it know where to look for a potential >> UDP header with port 546? > > Either the next header is an unknown EH conforming to RFC 6564, or > else it is a protocol header. Are we in agreement that if RFC6564 is deployed, we say "bye bye" to new transport protocols? And if we are, is that the path you want to follow? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 9 14:14:12 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299EA1A8772; Mon, 9 Feb 2015 13:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pam5jrhjL0lw; Mon, 9 Feb 2015 13:41:32 -0800 (PST) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA991A1A48; Mon, 9 Feb 2015 13:41:32 -0800 (PST) Received: by pdbfl12 with SMTP id fl12so9295901pdb.2; Mon, 09 Feb 2015 13:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R6NpCq2p8vmOFR2Gw7VkfLSx8T+5GBCjTsm9/Yambnw=; b=0ra2tJDkCd0cYNUKLxt0aHXxU/cZotvzHhLLU59rVG80G/Iiywqi9x1DQ6UPGQnRQS 0y/eUMtcs9jccTTwb2bJQUEpQVW7QNMVtx9/wxb7l9dd7i7UySYlyESOXTuePq0XuB30 e7qEC6XAyEJotSI5iKWw+wMTbWrPxiv5QQZ9c83JNwJbHlELosig9+dMs0I1IFuuFcSp 10tqhbao3RlrbsCLIeP0VzpFVLfHOLp1WIMIXoLyolJtn29yb3g7IBeaNJ/J9ppAMAxi O4jQH6+knJQBTZpAhDORwVQlFR+bJ95yjwX/Pmr3yirfNdnAgnpr+1usm0zt5Gm1AbEk qKHQ== X-Received: by 10.70.134.97 with SMTP id pj1mr32290566pdb.125.1423518092206; Mon, 09 Feb 2015 13:41:32 -0800 (PST) Received: from ?IPv6:2406:e007:4f88:1:28cc:dc4c:9703:6781? ([2406:e007:4f88:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id v2sm17280261pdm.77.2015.02.09.13.41.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Feb 2015 13:41:31 -0800 (PST) Message-ID: <54D92987.2080505@gmail.com> Date: Tue, 10 Feb 2015 10:41:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> In-Reply-To: <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , Fernando Gont , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 21:41:34 -0000 On 10/02/2015 08:52, Ted Lemon wrote: > On Feb 9, 2015, at 2:47 PM, Brian E Carpenter wrote: >> Fair enough. But let's just say that DHCPv6 Shield sees a Next Header >> value of 253. How does it know where to look for a potential UDP >> header with port 546? > > Either the next header is an unknown EH conforming to RFC 6564, or else it is a protocol header. If it is a protocol header, then it is an unknown protocol header, and therefore not a UDP header. If it conforms to RFC 6564, then it can be successfully skipped, whether or not it is known. OK Ted, then please provide the pseudo-code for making that determination: if ???? then #it's an unknown extension header conforming to RFC 6564 else #it's an unknown transport protocol; Brian >> I simply don't believe that any security product designer will do >> anything except give up and discard the packet. Don't we want RFCs >> to live in the real world? > > We want RFCs to recommend the right thing. It is likely true that at present, the implementor of a switch that implements DHCPv6 shield may cut some corners on processing of unknown headers. However, this is not something the IETF should recommend they do, because our recommendations will last longer than the current state of the art. There is no reason to cast the limitations of the current state of the art in stone. > From nobody Mon Feb 9 15:49:17 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D01D1A1A64; Mon, 9 Feb 2015 07:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAA8yuuFpFcm; Mon, 9 Feb 2015 07:37:21 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8EB1A1A27; Mon, 9 Feb 2015 07:37:21 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 6000CDA0290; Mon, 9 Feb 2015 15:37:21 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2A9C153E082; Mon, 9 Feb 2015 07:37:21 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 9 Feb 2015 07:37:20 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 9 Feb 2015 10:37:15 -0500 Content-Transfer-Encoding: 7bit Message-ID: <2C9D49E6-AE82-42D1-8E5A-A7B1470BAEF0@nominum.com> References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <54D8B220.2030204@innovationslab.net> To: "C. M. Heard" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: Brian Haberman , "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 15:37:25 -0000 On Feb 9, 2015, at 10:08 AM, C. M. Heard wrote: > I am probably confused, but the intended substance of the proposal > in http://www.ietf.org/mail-archive/web/opsec/current/msg01819.html > was just that, and it got rejected. Can we _please_ understand the problem before arguing about the solution? From nobody Mon Feb 9 15:51:07 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03331A6EE8; Mon, 9 Feb 2015 15:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1NRrYEBuKKR; Mon, 9 Feb 2015 15:32:17 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A72C1A8940; Mon, 9 Feb 2015 15:32:17 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 1EEAADA0293; Mon, 9 Feb 2015 23:32:17 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id CB39C53E083; Mon, 9 Feb 2015 15:32:16 -0800 (PST) Received: from vpna-188.vpn.nominum.com (64.89.227.188) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 9 Feb 2015 15:32:16 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54D92987.2080505@gmail.com> Date: Mon, 9 Feb 2015 18:32:07 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [64.89.227.188] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , Fernando Gont , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 23:32:18 -0000 On Feb 9, 2015, at 4:41 PM, Brian E Carpenter = wrote: > OK Ted, then please provide the pseudo-code for making that > determination: >=20 > if ???? then #it's an unknown extension header conforming to RFC 6564 > else #it's an unknown transport protocol; >=20 > Brian Apologies if there are horrific buffer overflow bugs, but here's roughly = how you would do it: // return true if it's a dhcpv6 packet that we should drop BOOL guard_p(int next_header_type, u_int8_t *bufp, int buflen) { int header_len; // no space for a valid protocol or extension header? if (buflen < 2) return false; if (next_header_type =3D=3D 59) return false; if (udp_p(next_header_type)) return dhcpv6_guard_p(bufp, buflen); if (known_proto_header_type_p(next_header_type)) return false; if (known_extension_header_type_p(next_header_type)) { header_len =3D header_extension_len(next_header_type, bufp, = buflen); // evidently malformed header? if (header_len =3D=3D 0) return false; // tail call to check next header return guard_p(known_extension_header_next_type(next_header_type, = bufp, buflen), bufp + header_len, buflen - header_len); } // tail call to check presumed RFC 6564 header. // if it's actually an unknown protocol header, we may=20 // have to parse over some garbage before running off // the end of the packet and returning false. // It may also be deliberate garbage, in which case the // same thing will happen, but possibly more slowly. return guard_p(bufp[0], bufp + bufp[1], buflen - bufp[1]); } From nobody Mon Feb 9 15:51:17 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D4A1A8A71; Mon, 9 Feb 2015 15:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ6HSFMOMLjZ; Mon, 9 Feb 2015 15:35:58 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE811A6EE8; Mon, 9 Feb 2015 15:35:58 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 4E275DA0291; Mon, 9 Feb 2015 23:35:58 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 36F0E53E083; Mon, 9 Feb 2015 15:35:58 -0800 (PST) Received: from vpna-188.vpn.nominum.com (64.89.227.188) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 9 Feb 2015 15:35:57 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 9 Feb 2015 18:35:48 -0500 Content-Transfer-Encoding: 7bit Message-ID: <194333CD-B976-4F7E-B4DF-D9D3A2039798@nominum.com> References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [64.89.227.188] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , Fernando Gont , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 23:35:59 -0000 On Feb 9, 2015, at 6:32 PM, Ted Lemon wrote: > return guard_p(bufp[0], bufp + bufp[1], buflen - bufp[1]); should be: > return guard_p(bufp[0], bufp + bufp[1] + 2, buflen - bufp[1] - 2); From nobody Mon Feb 9 15:52:24 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3101A8AA9; Mon, 9 Feb 2015 15:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJsELBBJ7hIy; Mon, 9 Feb 2015 15:50:37 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00EB21A6EE8; Mon, 9 Feb 2015 15:50:37 -0800 (PST) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YKy5z-0002a4-4Q; Tue, 10 Feb 2015 00:50:29 +0100 Message-ID: <54D94764.7030509@si6networks.com> Date: Mon, 09 Feb 2015 20:48:52 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon , Brian E Carpenter References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 23:50:39 -0000 On 02/09/2015 08:32 PM, Ted Lemon wrote: [....] > // tail call to check presumed RFC 6564 header. > // if it's actually an unknown protocol header, we may > // have to parse over some garbage before running off > // the end of the packet and returning false. > // It may also be deliberate garbage, in which case the > // same thing will happen, but possibly more slowly. You're essentially proposing a hack to fix a known protocol design flaw, instead of accepting the flaw, and allow DHCPv6-shield to comply with the existing specifications/requirements (RFC7045). -- all this under the assumption that RFC6564 gets deployed. In which case you're essentially declaring "game over" for any new transport protocol. I'll just reference this: . And note that you're arguing against 6man's advice in RFC7045. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 9 16:03:13 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331881A87EE; Mon, 9 Feb 2015 16:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3P0ei1GJwjP; Mon, 9 Feb 2015 16:02:52 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A311A6EE8; Mon, 9 Feb 2015 16:02:52 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 59D52DA028E; Tue, 10 Feb 2015 00:02:52 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2198C53E082; Mon, 9 Feb 2015 16:02:52 -0800 (PST) Received: from vpna-188.vpn.nominum.com (64.89.227.188) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 9 Feb 2015 16:02:51 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54D94764.7030509@si6networks.com> Date: Mon, 9 Feb 2015 19:02:42 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <757363AB-66DB-422C-99D0-BCE3A320AC55@nominum.com> References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> <54D94764.7030509@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [64.89.227.188] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 00:02:54 -0000 On Feb 9, 2015, at 6:48 PM, Fernando Gont wrote: > You're essentially proposing a hack to fix a known protocol design = flaw, > instead of accepting the flaw, and allow DHCPv6-shield to comply with > the existing specifications/requirements (RFC7045). How is this a hack? It correctly identifies all DHCPv6 packets. The = solution I've proposed is completely in compliance with RFC 7045. If = you want to argue that a solution is wrong, you should say what is wrong = with it, not refer to it as a "hack" as if merely by calling it a = "hack," you have somehow shown that it is not a good solution. > -- all this under the assumption that RFC6564 gets deployed. In which > case you're essentially declaring "game over" for any new transport > protocol. Er, no, the point of this is to _not_ break new transport protocols. = RFC 7045 does not deprecate RFC 6564. If you want to deprecate RFC = 6564, please go do the work in the appropriate venue. It's my = understanding, however, that you already tried this, and did not get = consensus to even adopt your proposal as a working group work item. From nobody Mon Feb 9 16:29:57 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFAB1A883B; Mon, 9 Feb 2015 16:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNLstuKr4VJu; Mon, 9 Feb 2015 16:29:33 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85F51A0372; Mon, 9 Feb 2015 16:29:32 -0800 (PST) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YKyhi-0002sK-4t; Tue, 10 Feb 2015 01:29:26 +0100 Message-ID: <54D95064.3090307@si6networks.com> Date: Mon, 09 Feb 2015 21:27:16 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> <54D94764.7030509@si6networks.com> <757363AB-66DB-422C-99D0-BCE3A320AC55@nominum.com> In-Reply-To: <757363AB-66DB-422C-99D0-BCE3A320AC55@nominum.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 00:29:36 -0000 On 02/09/2015 09:02 PM, Ted Lemon wrote: > On Feb 9, 2015, at 6:48 PM, Fernando Gont > wrote: >> You're essentially proposing a hack to fix a known protocol design >> flaw, instead of accepting the flaw, and allow DHCPv6-shield to >> comply with the existing specifications/requirements (RFC7045). > > How is this a hack? How can you positively tell whether what follow is an EH or a transport protocol? -- You simply can't. In your code, you assume that because something seems to be parseable by the RFC6564 syntax, it does follow the RFC6564 syntax. And of course that's, if anything, a hack. If there's a transport protocol that happens to look like RFC6564, and it is followed by data that looks like DHCPv6/UDP, your code will fail. Your code also assumes that RFC6564 will the deployed, when hepefuly/chances_are_that it won't. -- Because deploying RFC6564 would essentially say "bye bye" to any new transport protocols. I keep repeating it, and you keep ignoring it. The question is: Are we in agreement that deploying RFC6564 would prevent us developing any new transport protocols? And, if so, is that what you want? >> -- all this under the assumption that RFC6564 gets deployed. In >> which case you're essentially declaring "game over" for any new >> transport protocol. > > Er, no, the point of this is to _not_ break new transport protocols. > RFC 7045 does not deprecate RFC 6564. That doesn't eliminate the flaw in RFC6564. Please see my two questions above. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 9 16:51:46 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDFA1A01A9; Mon, 9 Feb 2015 16:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UZsCNevcrk8; Mon, 9 Feb 2015 16:51:31 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4BF1A0193; Mon, 9 Feb 2015 16:51:31 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 07566DA0290; Tue, 10 Feb 2015 00:51:31 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D035153E082; Mon, 9 Feb 2015 16:51:30 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 9 Feb 2015 16:51:30 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54D95064.3090307@si6networks.com> Date: Mon, 9 Feb 2015 19:51:25 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <190AFABC-6EA6-4B48-B13B-5F1EC86CE205@nominum.com> References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> <54D94764.7030509@si6networks.com> <757363AB-66DB-422C-99D0-BCE3A320AC55@nominum.com> <54D95064.3090307@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 00:51:33 -0000 On Feb 9, 2015, at 7:27 PM, Fernando Gont wrote: > If there's a transport protocol that > happens to look like RFC6564, and it is followed by data that looks = like > DHCPv6/UDP, your code will fail. You mean if there is an unknown transport protocol header that looks = like RFC 6564, and it is followed by a next header type of UDP, and that = UDP packet happens to be a well-formed DHCP packet, and happens to match = the criteria of DHCPv6-guard, then the switch will drop it? Yes, this = is true. However, in your proposal, the switch will also drop it, so = we haven't lost anything. Moreover, this is easy to fix: update the = switch to support the new protocol header. (Yes, I realize that my = definition of easy is a bit optimistic, but under the circumstances I = think that's okay.) From nobody Mon Feb 9 16:53:07 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819BA1A01F7; Mon, 9 Feb 2015 16:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRK8Ja161Jp2; Mon, 9 Feb 2015 16:52:42 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681E01A01A9; Mon, 9 Feb 2015 16:52:42 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 368E8DA028E; Tue, 10 Feb 2015 00:52:42 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2104853E082; Mon, 9 Feb 2015 16:52:42 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 9 Feb 2015 16:52:41 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54D95064.3090307@si6networks.com> Date: Mon, 9 Feb 2015 19:52:37 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> <54D94764.7030509@si6networks.com> <757363AB-66DB-422C-99D0-BCE3A320AC55@nominum.com> <54D95064.3090307@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 00:52:44 -0000 On Feb 9, 2015, at 7:27 PM, Fernando Gont wrote: > Your code also assumes that RFC6564 will the deployed, when > hepefuly/chances_are_that it won't. -- Because deploying RFC6564 would > essentially say "bye bye" to any new transport protocols. I keep > repeating it, and you keep ignoring it. I keep ignoring it because you keep asserting it without explaining why = you believe it to be true. > The question is: Are we in agreement that deploying RFC6564 would > prevent us developing any new transport protocols? And, if so, is that > what you want? No, we are not in agreement about this. From nobody Mon Feb 9 18:58:42 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389891A86E2 for ; Mon, 9 Feb 2015 18:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWcmSHEkijkq for ; Mon, 9 Feb 2015 18:58:16 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416FF1A8547 for ; Mon, 9 Feb 2015 18:58:16 -0800 (PST) Received: (qmail 26847 invoked from network); 9 Feb 2015 18:51:25 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2015 18:51:25 -0800 Date: Mon, 9 Feb 2015 18:51:24 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Ted Lemon In-Reply-To: Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , Fernando Gont , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 02:58:18 -0000 On Mon, 9 Feb 2015, Ted Lemon wrote: > On Feb 9, 2015, at 4:41 PM, Brian E Carpenter wrote: > > OK Ted, then please provide the pseudo-code for making that > > determination: > > > > if ???? then #it's an unknown extension header conforming to RFC 6564 > > else #it's an unknown transport protocol; > > > > Brian > > Apologies if there are horrific buffer overflow bugs, but here's roughly how you would do it: > > // return true if it's a dhcpv6 packet that we should drop > BOOL > guard_p(int next_header_type, u_int8_t *bufp, int buflen) > { > int header_len; > // no space for a valid protocol or extension header? > if (buflen < 2) > return false; > if (next_header_type == 59) > return false; > if (udp_p(next_header_type)) > return dhcpv6_guard_p(bufp, buflen); > if (known_proto_header_type_p(next_header_type)) > return false; > if (known_extension_header_type_p(next_header_type)) > { > header_len = header_extension_len(next_header_type, bufp, buflen); > // evidently malformed header? > if (header_len == 0) > return false; > // tail call to check next header > return guard_p(known_extension_header_next_type(next_header_type, bufp, buflen), > bufp + header_len, buflen - header_len); > } > // tail call to check presumed RFC 6564 header. > // if it's actually an unknown protocol header, we may > // have to parse over some garbage before running off > // the end of the packet and returning false. > // It may also be deliberate garbage, in which case the > // same thing will happen, but possibly more slowly. > return guard_p(bufp[0], bufp + bufp[1] + 2, buflen - bufp[1] - 2);> > } [ final statement corrected as indicated in subsequent e-mail ] I think this pseudo-code pretty clearly makes the point I was trying to make about DOS attacks on the DHCPv6-Sheild engine. In an earlier message, you wrote: > I asked you earlier in this conversation to describe a specific > attack, not make general speculations. OK. Here is a crafted packet that will make things go slowly: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 880 | 143 | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 144 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 145 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 252 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 59 | 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If I counted correctly, this "packet" uses all 110 unassigned protocol numbers (aka next header values). It would be easy to include more or fewer headers. Or make the last header length point outside the packet. Note that this is not an attack on the destination host. The destination host should drop the packet immediately upon encountering an unknown next header value. Rather, it is an attack on the DHCPv6-Shield engine, which has to do a lot of work to figure out what to do with this packet. Is a typical implementation robust enough to deal with a line-rate stream of stuff like this? Do implementations with hardware accelerators (and limited header memory) suffer no adverse effects at all? What do they do if the header chain won't fit? I'm sure the effects vary greatly, but is is really true that this attack is nothing to worry about? //cmh From nobody Mon Feb 9 19:10:21 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444C61A86EE; Mon, 9 Feb 2015 19:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YBqVOI5sTBf; Mon, 9 Feb 2015 19:09:49 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FBD01A8547; Mon, 9 Feb 2015 19:09:49 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C95CADA0292; Tue, 10 Feb 2015 03:09:48 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 7CD7753E083; Mon, 9 Feb 2015 19:09:48 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 9 Feb 2015 19:09:48 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 9 Feb 2015 22:09:41 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> To: "C. M. Heard" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , Fernando Gont , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 03:09:52 -0000 On Feb 9, 2015, at 9:51 PM, C. M. Heard wrote: > If I counted correctly, this "packet" uses all 110 unassigned=20 > protocol numbers (aka next header values). It would be easy to=20 > include more or fewer headers. Or make the last header length point=20= > outside the packet. >=20 > Note that this is not an attack on the destination host. The=20 > destination host should drop the packet immediately upon=20 > encountering an unknown next header value. Rather, it is an attack=20 > on the DHCPv6-Shield engine, which has to do a lot of work to figure=20= > out what to do with this packet. Is a typical implementation robust=20= > enough to deal with a line-rate stream of stuff like this? Do=20 > implementations with hardware accelerators (and limited header=20 > memory) suffer no adverse effects at all? What do they do if the=20 > header chain won't fit? I'm sure the effects vary greatly, but is=20 > is really true that this attack is nothing to worry about? I think what will happen in practice is that there will be some = fast-path logic that looks at the first 256 bytes of the packet at most, = and probably discards it if it can't be made sense of by the end of = those 256 bytes. I am completely okay with that. What I am not okay = with is advocating this behavior in a BCP. AFAIK existing implementations of DHCPv6-shield already do this. From nobody Mon Feb 9 20:56:26 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84701A797C; Mon, 9 Feb 2015 20:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me_Opt4LQ7p8; Mon, 9 Feb 2015 20:56:19 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1251A0141; Mon, 9 Feb 2015 20:56:18 -0800 (PST) Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:ed03:6fe5:5698:bdb4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t1A4u2sK008651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Feb 2015 04:56:03 GMT (envelope-from joelja@bogus.com) Message-ID: <54D98F62.4080508@bogus.com> Date: Mon, 09 Feb 2015 20:56:02 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Ted Lemon , "C. M. Heard" References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iAeniG4lAHe3JrT9QjF5Uhjii4hkAlqD8" Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , Fernando Gont , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 04:56:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iAeniG4lAHe3JrT9QjF5Uhjii4hkAlqD8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/9/15 7:09 PM, Ted Lemon wrote: > On Feb 9, 2015, at 9:51 PM, C. M. Heard wrote: >> If I counted correctly, this "packet" uses all 110 unassigned=20 >> protocol numbers (aka next header values). It would be easy to=20 >> include more or fewer headers. Or make the last header length >> point outside the packet. >>=20 >> Note that this is not an attack on the destination host. The=20 >> destination host should drop the packet immediately upon=20 >> encountering an unknown next header value. Rather, it is an attack >> on the DHCPv6-Shield engine, which has to do a lot of work to >> figure out what to do with this packet. Is a typical >> implementation robust enough to deal with a line-rate stream of >> stuff like this? Do implementations with hardware accelerators >> (and limited header memory) suffer no adverse effects at all? What >> do they do if the header chain won't fit? I'm sure the effects >> vary greatly, but is is really true that this attack is nothing to >> worry about? >=20 > I think what will happen in practice is that there will be some > fast-path logic that looks at the first 256 bytes of the packet at > most, and probably discards it if it can't be made sense of by the > end of those 256 bytes. I am completely okay with that. What I am > not okay with is advocating this behavior in a BCP. We do ourselves and the community a disservice when we fail to include discussion of operational divergence from expected behavior. if whe can find a position that falls short of advocacy where does that leave us? > AFAIK existing implementations of DHCPv6-shield already do this. Yeah exactly. > _______________________________________________ OPSEC mailing list=20 > OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec >=20 --iAeniG4lAHe3JrT9QjF5Uhjii4hkAlqD8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTZj2IACgkQ8AA1q7Z/VrKHLwCeL/Sny9hAEylW1DETiZRDsqe5 pfwAn1lZub2J/ZhMoL9L1R4lr3xu077V =eRnC -----END PGP SIGNATURE----- --iAeniG4lAHe3JrT9QjF5Uhjii4hkAlqD8-- From nobody Tue Feb 10 06:49:41 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9F41A889B; Tue, 10 Feb 2015 06:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzVXyE8O_NIr; Tue, 10 Feb 2015 06:49:29 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C66A1A7013; Tue, 10 Feb 2015 06:49:02 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id DE271880CE; Tue, 10 Feb 2015 06:49:01 -0800 (PST) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C2DFA71B0001; Tue, 10 Feb 2015 06:49:00 -0800 (PST) Message-ID: <54DA1A56.8080909@innovationslab.net> Date: Tue, 10 Feb 2015 09:48:54 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Fernando Gont , Ted Lemon , "C. M. Heard" References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <54D90317.4070205@si6networks.com> In-Reply-To: <54D90317.4070205@si6networks.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kSSiadTlsHmd4U7HseXK2DC0Bkkmt5bub" Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 14:49:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kSSiadTlsHmd4U7HseXK2DC0Bkkmt5bub Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/9/15 1:57 PM, Fernando Gont wrote: > On 02/08/2015 04:24 PM, Ted Lemon wrote: >> On Feb 8, 2015, at 1:47 PM, C. M. Heard wrote: >>> It is not necessarily true that an unknown upper layer protocol=20 >>> header will look like a malformed extension header to a device that >>> assumes it is an extension header following the format in RFC >>> 6564. If the value of the 2nd octet of the unknown header is v, >>> then it won't appear malformed if at least 8*(v+1) bytes remain in >>> the packet, starting from the beginning of the unknown header. At >>> that point the device would be interpreting the payload of the >>> unknown upper layer PDU as an extension header chain. In the >>> benign case where the packet is a legitimate one with an upper >>> layer protocol unknown to the device, it is likely (but not >>> assured) that the chain would quickly terminate in something that >>> looks like a malformed extension header. However, it would not be >>> difficult to craft a packet that makes a very long apparent header >>> chain. Depending on how the device processes header chains, that >>> could easily be a vector for DOS attacks -- e.g., by consuming >>> processing resources or by exercising a rarely used processing >>> path. That is why I think it is UNSAFE to continue processing a >>> header chain after encountering an unknown next header value. >> >> This may or may not be true, but to the extent that it's true, it's >> already addressed in RFC 7045, and it's addressed correctly there. >> There is no need to strengthen the advice in RFC 7045 here, which >> this document currently does >=20 > Why do you think this document "strengthens the advice in RFC7045", as > opposed to it actually *complying* with what's in RFC7045? Perhaps the issue is that not everyone has read 7045 recently. The primary piece of advice in 7045 is section 2.1 (http://tools.ietf.org/html/rfc7045#section-2.1), which I summarize as: 1. A forwarding node SHOULD forward all packets regardless of whether there are extension headers present or not. 2. If a forwarding node examines the packet it MUST recognize all standard extension headers and SHOULD recognize all experimental extension headers. 3. Intermediate nodes SHOULD NOT discard a packet containing unrecognized extension headers. 4. If the intermediate node discards a packet containing a standard extension header, it MUST be because of a configurable policy. 5. The discard policy for each standard extension header MUST be individually configurable. The default configuration SHOULD allow all standard extension headers. 6. Forwarding nodes MUST be configurable to allow unrecognized extension headers. The default configuration MAY be to drop packets containing them= =2E Regards, Brian --kSSiadTlsHmd4U7HseXK2DC0Bkkmt5bub Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU2hpbAAoJEBOZRqCi7goq5tsH/i643Br3OsZ6hAo5QLAvWtXH +jkhiHR8z8fGm7IxHI5leky0NRgPmdzcWP2DwBsmxl2r9QZWJlwajIhO08quIdAF l4FmD/RyjbIQfX7AvPjjjkSEXKufInJePdAiai3HMEVK/HIMf4FHxyN4xfKBd/ES sgELF2ozZ4hHNYY1tPyvcwCd9hdaAxJ9f956VNoum4oQdkrncTg5i2ue2vSaGhKs HXlGLgAE5vuAv7g2byk//tl7uGsaXH56B4aYVar1jyJoio4uiyMOjsnSuMhoASvN 9AjQ0aJkl6CziMMaFn4URctCFBIYRERjT5ZlV2bagujFHFLqfT5UUYUfOEKOOu4= =XuFk -----END PGP SIGNATURE----- --kSSiadTlsHmd4U7HseXK2DC0Bkkmt5bub-- From nobody Tue Feb 10 09:26:08 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B785D1A1A72 for ; Tue, 10 Feb 2015 09:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tiux4j3m2b8y for ; Tue, 10 Feb 2015 09:26:01 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817061A1AE0 for ; Tue, 10 Feb 2015 09:25:58 -0800 (PST) Received: (qmail 13993 invoked from network); 10 Feb 2015 09:25:53 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Feb 2015 09:25:53 -0800 Date: Tue, 10 Feb 2015 09:25:53 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: joel jaeggli In-Reply-To: <54D98F62.4080508@bogus.com> Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> <54D98F62.4080508@bogus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , Ted Lemon , Fernando Gont , "opsec-chairs@ietf.org" , Brian E Carpenter , The IESG Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:26:02 -0000 On Mon, 9 Feb 2015, joel jaeggli wrote: > On 2/9/15 7:09 PM, Ted Lemon wrote: > > I think what will happen in practice is that there will be some > > fast-path logic that looks at the first 256 bytes of the packet at > > most, and probably discards it if it can't be made sense of by the > > end of those 256 bytes. I am completely okay with that. What I am > > not okay with is advocating this behavior in a BCP. > > We do ourselves and the community a disservice when we fail to include > discussion of operational divergence from expected behavior. if whe can > find a position that falls short of advocacy where does that leave us? Allow me to point out that a device that is unable to parse the entire IPv6 header chain is not compliant with the draft as now written: 1. DHCPv6-Shield MUST parse the entire IPv6 header chain present in the packet, to identify whether it is a DHCPv6 packet meant for a DHCPv6 client (i.e., a DHCPv6-server message). RATIONALE: DHCPv6-Shield implementations MUST NOT enforce a limit on the number of bytes they can inspect (starting from the beginning of the IPv6 packet), since this could introduce false-negatives: DHCP6-server packets received on ports not allowed to receive such packets could be allowed simply because the DHCPv6-Shield device does not parse the entire IPv6 header chain present in the packet. The implication is that if the header chain exceeds the size that can be looked at with fast-path logic, the packet would need to be kicked onto a slow path -- where the potential DoS exposure that I've pointed out would very likely be a real problem. //cmh From nobody Tue Feb 10 09:49:13 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07ABE1A1ADC; Tue, 10 Feb 2015 09:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWrIKCfWEbMk; Tue, 10 Feb 2015 09:49:08 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44FF01A1ADA; Tue, 10 Feb 2015 09:49:05 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 020BDDA0278; Tue, 10 Feb 2015 17:49:04 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B7CED53E083; Tue, 10 Feb 2015 09:49:04 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 10 Feb 2015 09:49:04 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54D98F62.4080508@bogus.com> Date: Tue, 10 Feb 2015 12:48:56 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> <54D98F62.4080508@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , Fernando Gont , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:49:10 -0000 On Feb 9, 2015, at 11:56 PM, joel jaeggli wrote: > We do ourselves and the community a disservice when we fail to include > discussion of operational divergence from expected behavior. if whe = can > find a position that falls short of advocacy where does that leave us? I would suggest a note in the security considerations section that says = something like this: The recommendations in this document represent the ideal behavior of a = DHCPv6 shield device. However, in order to implement DHCPv6 shield on = the fast path, it may be necessary to limit the depth into the packet = that can be scanned before giving up. In circumstances where there is = such a limitation, it is recommended that implementations drop packets = after attempting to find a protocol header (as opposed to an extension = header) up to that limit, whatever it is. Ideally, such devices should be configurable with a list of protocol = header identifiers so that if new transport protocols are standardized = after the device is released, they can be added to the list of protocol = header types that the device recognizes. Since any protocol header that = is not a UDP header would be passed by the DHCPv6 shield algorithm, this = would allow such devices to avoid blocking the use of new transport = protocols. When an implementation must stop searching for recognizable header types = in a packet due to such limitations, whether the device passes or drop = that packet SHOULD be configurable. From nobody Tue Feb 10 10:40:39 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0361A1BA5; Tue, 10 Feb 2015 10:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZJvaeiRL5Wq; Tue, 10 Feb 2015 10:40:31 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D547A1A1BA9; Tue, 10 Feb 2015 10:40:28 -0800 (PST) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YLFjR-0007g5-E0; Tue, 10 Feb 2015 19:40:21 +0100 Message-ID: <54DA500C.5070908@si6networks.com> Date: Tue, 10 Feb 2015 15:38:04 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon , Joel Jaeggli References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> <54D98F62.4080508@bogus.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 18:40:34 -0000 Hi, Ted, On 02/10/2015 02:48 PM, Ted Lemon wrote: > On Feb 9, 2015, at 11:56 PM, joel jaeggli wrote: >> We do ourselves and the community a disservice when we fail to >> include discussion of operational divergence from expected >> behavior. if whe can find a position that falls short of advocacy >> where does that leave us? > > I would suggest a note in the security considerations section that > says something like this: Your suggestion sounds very sensible. I have a couple of questions below, though: > The recommendations in this document represent the ideal behavior of > a DHCPv6 shield device. However, in order to implement DHCPv6 shield > on the fast path, it may be necessary to limit the depth into the > packet that can be scanned before giving up. In circumstances where > there is such a limitation, it is recommended that implementations > drop packets after attempting to find a protocol header (as opposed > to an extension header) up to that limit, whatever it is. Not sure what the "(as opposed to an extension header)" means. Could you elaborate/clarify a bit? > Ideally, such devices should be configurable with a list of protocol > header identifiers so that if new transport protocols are > standardized after the device is released, they can be added to the > list of protocol header types that the device recognizes. Since any > protocol header that is not a UDP header would be passed by the > DHCPv6 shield algorithm, this would allow such devices to avoid > blocking the use of new transport protocols. So in summary, this argues in favor of DHCPv6-Shield not having only a hardcoded list of protocols/EHs that it should pass, but to also allow that list to be expanded, so to speak, right? If so, that's sensible, too. The only thing that I'd probably change is s/transport protocols/Next Header values that do not represent Extension Headers/, since it's more general (e.g., something new protocol ala ICMPv6 should be passed.. but ICMPv6 is not a transport protocol). > When an implementation must stop searching for recognizable header > types in a packet due to such limitations, whether the device passes > or drop that packet SHOULD be configurable. Should we say anything about the default setting? From a security standpoint, it shoudl clearly default to "drop".. otherwise DHCPv6-Shield would be easily evasible by inserting an appropriate number of IPv6 EHs. Thoughts? 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 nobody Tue Feb 10 11:14:50 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785E21A1BC6 for ; Tue, 10 Feb 2015 11:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IHdJilA4hBY for ; Tue, 10 Feb 2015 11:14:47 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6171A7029 for ; Tue, 10 Feb 2015 11:14:43 -0800 (PST) Received: (qmail 26887 invoked from network); 10 Feb 2015 11:14:37 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Feb 2015 11:14:37 -0800 Date: Tue, 10 Feb 2015 11:14:37 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Fernando Gont In-Reply-To: <54DA500C.5070908@si6networks.com> Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> <54D98F62.4080508@bogus.com> <54DA500C.5070908@si6networks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , Pete Resnick , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , Ted Lemon , "opsec-chairs@ietf.org" , Brian E Carpenter , The IESG Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 19:14:48 -0000 On Tue, 10 Feb 2015, Fernando Gont wrote: > On 02/10/2015 02:48 PM, Ted Lemon wrote: > > Ideally, such devices should be configurable with a list of protocol > > header identifiers so that if new transport protocols are > > standardized after the device is released, they can be added to the > > list of protocol header types that the device recognizes. Since any > > protocol header that is not a UDP header would be passed by the > > DHCPv6 shield algorithm, this would allow such devices to avoid > > blocking the use of new transport protocols. > > So in summary, this argues in favor of DHCPv6-Shield not having only a > hardcoded list of protocols/EHs that it should pass, but to also allow > that list to be expanded, so to speak, right? > > If so, that's sensible, too. The only thing that I'd probably change is > s/transport protocols/Next Header values that do not represent Extension > Headers/, since it's more general (e.g., something new protocol ala > ICMPv6 should be passed.. but ICMPv6 is not a transport protocol). Yes indeed, the problems we've been arguing about all get solved satisfactorily if the device sports a table that allows each of the undefined Next Header values to be be treated either as identifying either an upper-layer protocol, which should be passed, or as an extension header that follows the rules of RFC 6564, which can be skipped while parsing the header chain. For the purposes of this discussion, "undefined Next Header values" means the values in the Protocol Numbers registry (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml) that at the time of implementation are unassigned, PLUS the experimental values 253 and 254 (which could be either an experimental extension header or an experimental protocol), PLUS the reserved value 255. Currently that would be 143 and up. > > When an implementation must stop searching for recognizable header > > types in a packet due to such limitations, whether the device passes > > or drop that packet SHOULD be configurable. I would say MUST be configurable, otherwise it cannot comply with RFC 7045. > Should we say anything about the default setting? From a security > standpoint, it shoudl clearly default to "drop".. otherwise > DHCPv6-Shield would be easily evasible by inserting an appropriate > number of IPv6 EHs. I would be fine with lifting the agnostic "the default configuration MAY drop such packets" from RFC 7045 but I am not wedded to this. //cmh From nobody Tue Feb 10 12:50:12 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56821A1EF7; Tue, 10 Feb 2015 12:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y49uIEJHZjl; Tue, 10 Feb 2015 12:50:00 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0F91A1BFB; Tue, 10 Feb 2015 12:50:00 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 6A803DA025E; Tue, 10 Feb 2015 20:50:00 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 1AF0053E082; Tue, 10 Feb 2015 12:50:00 -0800 (PST) Received: from [10.255.255.68] (64.223.66.169) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 10 Feb 2015 12:50:00 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54DA500C.5070908@si6networks.com> Date: Tue, 10 Feb 2015 15:49:53 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <54D83FCE.4070804@qti.qualcomm.com> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com> <54D92987.2080505@gmail.com> <54D98F62.4080508@bogus.com> <54DA500C.5070908@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [64.223.66.169] Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "C. M. Heard" , Pete Resnick , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "opsec@ietf.org" , The IESG , "opsec-chairs@ietf.org" , Brian E Carpenter Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 20:50:07 -0000 On Feb 10, 2015, at 1:38 PM, Fernando Gont = wrote: > Not sure what the "(as opposed to an extension header)" means. Could = you > elaborate/clarify a bit? What I'm proposing is that unknown codes can be assumed to be extension = headers. Any known code may be either an extension header or a = protocol header, but then it's a known code, so not a problem. But = rereading the text, that parenthetical does seem unnecessary. Anyway, it sounds like we now have some text to argue about that we = might be able to agree on, so I will defer to you on tweaking it--I just = wanted to give you a sense of what I had in mind. The main thing I = want to avoid is a recommendation that the basic shield algorithm by = default drop unknown extension and transport headers, but I agree that = it's good to say what to do if the hardware can't support that fully. From nobody Tue Feb 10 18:46:36 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF8E1A1DBC; Tue, 10 Feb 2015 18:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIidw8NPx3ir; Tue, 10 Feb 2015 18:46:29 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4871A6EFB; Tue, 10 Feb 2015 18:46:29 -0800 (PST) Received: from mb-aye.local (c-98-248-47-249.hsd1.ca.comcast.net [98.248.47.249]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t1B2kGRu022890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Feb 2015 02:46:17 GMT (envelope-from joelja@bogus.com) Message-ID: <54DAC271.7030604@bogus.com> Date: Tue, 10 Feb 2015 18:46:09 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Ted Lemon , "C. M. Heard" References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> In-Reply-To: <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D23t5wwpagJg9XDqlgx1LBXlGhiOhOtJe" Archived-At: Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" , "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" , The IESG , "opsec-chairs@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 02:46:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D23t5wwpagJg9XDqlgx1LBXlGhiOhOtJe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/8/15 5:30 PM, Ted Lemon wrote: > On Feb 8, 2015, at 6:21 PM, C. M. Heard wrote: >> Would your objections be addressed if Section 3 of the draft were=20 >> replaced by something along the lines of the following? >=20 > No. This is not a draft about filtering extension headers. It is a d= raft about filtering DHCP. The two are unrelated, and should not be dis= cussed as if they were related. >=20 This is the peril of getting a little far afield. I think we can solve the dhcpv6 problem discussion with a more narrowly scoped attack on the text. >=20 --D23t5wwpagJg9XDqlgx1LBXlGhiOhOtJe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTawnIACgkQ8AA1q7Z/VrIjqwCfa8TqusZpjCoTrL9EpMvNI15X OPEAnR1CichcVPIPsHJtuTQCZiNSIJx9 =f3iq -----END PGP SIGNATURE----- --D23t5wwpagJg9XDqlgx1LBXlGhiOhOtJe-- From nobody Wed Feb 18 15:03:47 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4C51A1B85; Wed, 18 Feb 2015 15:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9umoQ9wkBbB; Wed, 18 Feb 2015 15:03:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 267CE1A1B91; Wed, 18 Feb 2015 15:03:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5D671181D1F; Wed, 18 Feb 2015 15:03:09 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150218230309.5D671181D1F@rfc-editor.org> Date: Wed, 18 Feb 2015 15:03:09 -0800 (PST) Archived-At: Cc: opsec@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSEC] BCP 194, RFC 7454 on BGP Operations and Security X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 23:03:40 -0000 A new Request for Comments is now available in online RFC libraries. BCP 194 RFC 7454 Title: BGP Operations and Security Author: J. Durand, I. Pepelnjak, G. Doering Status: Best Current Practice Stream: IETF Date: February 2015 Mailbox: jerduran@cisco.com, ip@ipspace.net, gert@space.net Pages: 26 Characters: 56946 See Also: BCP 194 I-D Tag: draft-ietf-opsec-bgp-security-07.txt URL: https://www.rfc-editor.org/info/rfc7454 The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing. This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Feb 25 03:46:37 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D387A1A0015; Wed, 25 Feb 2015 03:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BCLiml6ymno; Wed, 25 Feb 2015 03:46:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C41B21A0016; Wed, 25 Feb 2015 03:46:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150225114630.8180.60890.idtracker@ietfa.amsl.com> Date: Wed, 25 Feb 2015 03:46:30 -0800 Archived-At: Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-06.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 11:46:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. 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 Authors : Fernando Gont Will Liu Gunter Van de Velde Filename : draft-ietf-opsec-dhcpv6-shield-06.txt Pages : 10 Date : 2015-02-25 Abstract: This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6 Shield. 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-dhcpv6-shield-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 25 03:46:48 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A5A1A0018; Wed, 25 Feb 2015 03:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rtO_FOG0v7W; Wed, 25 Feb 2015 03:46:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE18C1A001C; Wed, 25 Feb 2015 03:46:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150225114630.8180.85198.idtracker@ietfa.amsl.com> Date: Wed, 25 Feb 2015 03:46:30 -0800 Archived-At: Subject: [OPSEC] New Version Notification - draft-ietf-opsec-dhcpv6-shield-06.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 11:46:34 -0000 A new version (-06) has been submitted for draft-ietf-opsec-dhcpv6-shield: http://www.ietf.org/internet-drafts/draft-ietf-opsec-dhcpv6-shield-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-dhcpv6-shield-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat.