(coffee != sleep) & (!coffee == sleep)
Donald(_dot_)Smith(_at_)centurylink(_dot_)com
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):
Thank you.
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).
Ahh I missed that distinction but get it now.
OTOH, the first fragment is a fragment with the FO==0.
And more fragments flag set to 1?
> 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.
Ok.
> 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....
Yea I like this from a hw pov but it isn't compatible with other rfcs so we can
drop my comment.
> 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
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.