Minor suggestion aka nit:
pg. 1
This:
"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.
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)
Donald(_dot_)Smith(_at_)centurylink(_dot_)com
From: OPSEC [opsec-bounces(_at_)ietf(_dot_)org] on behalf of The IESG
[iesg-secretary(_at_)ietf(_dot_)org]
Sent: Monday, November 17, 2014 12:52 PM
To: IETF-Announce
Cc: opsec(_at_)ietf(_dot_)org
Subject: [OPSEC] Last Call: <draft-ietf-opsec-dhcpv6-shield-04.txt>
(DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best Current
Practice
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
ietf(_at_)ietf(_dot_)org mailing lists by 2014-12-01. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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.
_______________________________________________
OPSEC mailing list
OPSEC(_at_)ietf(_dot_)org
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.