Subject: [OPSEC] Last Call: <draft-ietf-opsec-dhcpv6-shield-04.txt> (DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best Current Practice

From: The IESG <[email-masked]>
Date: Mon, 17 Nov 2014 11:52:09 -0800

The IESG has received a request from the Operational Security
Capabilities for IP Network Infrastructure WG (opsec) to consider the
following document:
- 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers'
  <draft-ietf-opsec-dhcpv6-shield-04.txt> as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-12-01. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document specifies a mechanism for protecting hosts connected to
   a switched network against rogue DHCPv6 servers.  The aforementioned
   mechanism is based on DHCPv6 packet-filtering at the layer-2 device
   at which the packets are received.  The aforementioned mechanism has
   been widely deployed in IPv4 networks ('DHCP snooping'), and hence it
   is desirable that similar functionality be provided for IPv6
   networks.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 18 Nov 2014 19:04:50 +0000

Minor suggestion aka nit:

pg. 1
This:
"Abstract

Reads a bit better if it is this:

Abstract

   This document specifies a mechanism for protecting hosts connected to
   a switched network against rogue DHCPv6 servers.  This
   mechanism is based on DHCPv6 packet-filtering at the layer-2 device
   at which the packets are received.  This mechanism has
   been widely deployed in IPv4 networks ('DHCP snooping'), and hence it
   is desirable that similar functionality be provided for IPv6
   networks.

Ultimately it reads the same but is s a bit simpler swapping The aforementioned for this.

pg 3.
This "first fragment" generally called "original packet",  (rfc2460 section 4.5) , description is a little weak.
"First Fragment:

      An IPv6 fragment with fragment offset equal to 0."

Maybe just refer to that rfc/section and call it original packet instead of trying to redefine and rename it here?
There are several instances of "initial fragment with offset of 0" that should probably be replaced with "original packet" and rfc reference.

pg 3.

IPv6 Header Chain:...

Seems mostly correct but again why restate what is described in rfc2460 section 4?

pg 4.
I am not sure I understand this part.
"RATIONALE: DHCPv6-Shield implementations MUST NOT enforce a
          limit on the number of bytes they can inspect (starting from
          the beginning of the IPv6 packet), since this could introduce
          false-positives: legitimate packets could be dropped simply
          because the DHCPv6-Shield device does not parse the entire
          IPv6 header chain present in the packet.  An implementation
          that has such an implementation-specific limit MUST NOT claim
          compliance with this specification."

If an implementation didn't parse the whole packet and it does not see an dhcp msg header wouldn't it default to allow not drop? ( MUST drop if see dhcp , MUST allow if not?)

So wouldn't you be more likely to have false negatives because the whole header wasn't examined?

pg 5
" 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: [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."

Why discuss "unrecognized Next Header" here?
Since this is  requirement of 7045 does it need to be restated here?

It says SHOULD log, so that implies the default is "drop and log" but I suspect many would be ok with "drop don't log".
I am not sure most of us would want to know about "unrecognized Next Headers" but could be wrong here.

pg 5 section 4.
"If a packet is dropped due to this filtering policy, then the packet
   drop event SHOULD be logged in an implementation-specific manner as a
   security fault.  The logging mechanism SHOULD include a drop counter
   dedicated to DHCPv6-Shield packet drops."

Doesn't the counter need to include port?  A system wide counter wouldn't be much good.

... The logging mechanism SHOULD include a per port drop counter ...

Note here it says DHCPv6 Shield even though above the logging appears to include "unrecognized Next Header". Would the counter include both or just DHCPv6 Shield drops?
Maybe two counters (but then we are out of scope for dhcp again?)

pg 5-6 section 4.

"In order to protect current end-node IPv6 implementations, Rule #2
   has been defined as a default rule to drop packets that cannot be
  positively identified as not being DHCPv6-server packets (because the
   packet is a fragment that fails to include the entire IPv6 header
   chain).  This means that, at least in theory, DHCPv6-Shield could
   result in false-positive blocking of some legitimate (non
   DHCPv6-server) packets.  However, as noted in [RFC7112], IPv6 packets
   that fail to include the entire IPv6 header chain are virtually
   impossible to police with state-less filters and firewalls, and hence
   are unlikely to survive in real networks.  [RFC7112] requires that
   hosts employing fragmentation include the entire IPv6 header chain in
   the first fragment (the fragment with the Fragment Offset set to 0),
   thus eliminating the aforementioned false positives."

It seems like 7112 covers this does it need to be part of this?

SILICON SENSE
I think it would make more sense to require dhcpv6 requests come from a special OID (Ethernet mac address) and only listen to them from that address.
It would require the switch to only allow that oid be used on dhcp server ports but that is much simpler from an silicon point of view.
It would also require changes to the dhcpv6 clients but does simplify the solution from a hw pov.
Moving this kind of deep header inspection into layer 2 gives us a new cpu dos vector as most vendors would initially (forever?) do that in cpu or shared npu?
We have that problem today with layer 3 routing an headers do we want to push this to the next layer down?

(coffee != sleep) & (!coffee == sleep)
 [email-masked]

From: OPSEC [[email-masked]] on behalf of The IESG [[email-masked]]
Sent: Monday, November 17, 2014 12:52 PM
To: IETF-Announce
Cc: [email-masked]
Subject: [OPSEC] Last Call: <draft-ietf-opsec-dhcpv6-shield-04.txt> (DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best Current Practice

Abstract

_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.