On 07/04/2015 06:14 PM, C. M. Heard wrote: >> 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.
You're 100% correct. > 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. This is how we've fixed the document, with the addition of a "RATIONALE" in bullet 4. Thanks so much! -- You've done a lot in keeping this document correct. Cheers, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
