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

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

[ Adding the working group to the reply, with apologies for the lengthy delay ]

On Sun, Jun 28, 2015 at 12:06 PM, joel jaeggli <[e-mail]> 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 <[e-mail]>
> > To: OPSEC <[e-mail]>
> > 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, [e-mail] 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/
> >>
> >>
> >
>