Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT)

[Fernando Gont <[e-mail]>]

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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/opsec
>>>
>>
>>
> 
> _______________________________________________
> OPSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
> 


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492