[ Adding the working group to the reply, with apologies for the lengthy delay ]
On Sun, Jun 28, 2015 at 12:06 PM, joel jaeggli <[email protected]> wrote: > On 6/1/15 9:14 AM, C. M. Heard wrote: > > I failed to cc the AD, authors, and doc shepherd ... apologies for > > the duplication if you already saw this. I am making all this noise > > because if I am right this is a serious error that needs to be > > corrected prior to publication, and I see the state is > > Approved-announcement to be sent::Point Raised - writeup needed. > > sorry for the delay, imho section 5 bullet 3 I think preserves the > document's intent. There was substantial dicussion in the IESG > respecting the handling of unknown or unparasable header chains that > resulted in the slouch towards the text as you see it today. The text in bullet 3 does a fine job of saying how to handle unrecognized Next Header values. However, it does NOT say what to do when receiving a DHCPv6 packet meant for a DHCPv6 client. In -05 (the version that was the subject of intense discussion), bullet 3 did contain such instructions: "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 […]." Pete Resnick's ballot comments suggested splitting this bullet up into two parts. The part dealing with unrecognized Next Header values made it into -07; the part dealing with DHCPv6 packets meant for DHCPv6 clients did not. The remedy I propose is to include the omitted part of Pete's suggested text, as follows: OLD: 3. 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". When parsing the IPv6 header chain, if the packet contains an unrecognized Next Header value and the configuration knob is configured to "drop", DHCPv6-Shield MUST drop the packet, and ought to log the packet drop event in an implementation-specific manner as a security fault. 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. 4. In all other cases, DHCPv6-Shield MUST pass the packet as usual. NEW: 3. 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". When parsing the IPv6 header chain, if the packet contains an unrecognized Next Header value and the configuration knob is configured to "drop", DHCPv6-Shield MUST drop the packet, and ought to log the packet drop event in an implementation-specific manner as a security fault. 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. 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 ought to the packet drop event in an implementation-specific manner as a security alert. 5. In all other cases, DHCPv6-Shield MUST pass the packet as usual. END. > imho if Fernando can live with it in it's final form I think it > preserves the WGs intent. Read literally, the document in its present form says that DHCPv6-Shield MUST pass DHCPv6 packets meant forDHCPv6 clients. From my perspective, that does not reflect what the document said when then WG passed it to the IESG nor is it technically correct. Fernando, what is your take? //cmh > > joel > > > //cmh > > > > ---------- Forwarded message ---------- > > Date: Sat, 30 May 2015 20:34:50 -0700 (PDT) > > From: C. M. Heard <[email protected]> > > To: OPSEC <[email protected]> > > Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-07.txt > > > > Greetings, > > > > The text in Section 3 seems to have dropped the step saying that if > > the packet is identified to be a DHCPv6 packet meant for a DHCPv6 > > client then a DHCPv6-Shield implementation MUST drop the packet. > > That omission defeats the entire purpose of the draft and renders it > > unsuitable for publication. > > > > As noted in > > http://www.ietf.org/mail-archive/web/opsec/current/msg01870.html, > > this problem was introduced in the -06 version of the draft. Could the > > authors > > PLEASE fix this, or else point out where in -07 this step is spelled out? > > > > //cmh > > > > On Fri, 15 May 2015, [email protected] wrote: > >> 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-07.txt > >> Pages : 11 > >> Date : 2015-05-15 > >> > >> 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: > >> https://tools.ietf.org/html/draft-ietf-opsec-dhcpv6-shield-07 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-dhcpv6-shield-07 > >> > >> > >> 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/ > >> > >> > > > _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
