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@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492