Re: [OPSEC] FW: I-D Action: draft-ietf-opsec-dhcpv6-shield-07.txt

[Fernando Gont <[e-mail]>]

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492