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

["C. M. Heard" <[e-mail]>]

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
> > 
> 
>