Hi, Donald,
Not sure if any of us had responded to this one, but, just in case, here
I go (please find my responses in-line):
On 11/18/2014 04:04 PM, Smith, Donald wrote:
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.
Nope. They are different things:
The original packet is the packet your host produces but never hits the
wire (when you're employing fragmentation).
OTOH, the first fragment is a fragment with the FO==0.
pg 3.
IPv6 Header Chain:...
Seems mostly correct but again why restate what is described in
rfc2460 section 4?
When we did RFC7112 at 6man, the wg asked us to have all these
definitions...
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?
You're right. Fixed!
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?
We need a specific action regarding unrecognized Next Header values
here.. that's why.
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 ...
Done. Thanks!
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?)
I guess the "per port drop counter" would be the minimum required... but
an implementation can always do better than that.
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?
We've been asked to -- although me, I'd probably agree with you.
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.
But this is not backwards-compatible....
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?
FWIW, whether a vendor implements this in hw or software is out of
scope. As you correctly note, doing this in software has its implications...
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492