Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT)

[Fernando Gont <[e-mail]>]

Hi, Ted,

On 02/10/2015 02:48 PM, Ted Lemon wrote:
> On Feb 9, 2015, at 11:56 PM, joel jaeggli <[e-mail]> wrote:
>> We do ourselves and the community a disservice when we fail to
>> include discussion  of operational divergence from expected
>> behavior. if whe can find a position that falls short of advocacy
>> where does that leave us?
> 
> I would suggest a note in the security considerations section that
> says something like this:

Your suggestion sounds very sensible. I have a couple of questions
below, though:



> The recommendations in this document represent the ideal behavior of
> a DHCPv6 shield device. However, in order to implement DHCPv6 shield
> on the fast path, it may be necessary to limit the depth into the
> packet that can be scanned before giving up.   In circumstances where
> there is such a limitation, it is recommended that implementations
> drop packets after attempting to find a protocol header (as opposed
> to an extension header) up to that limit, whatever it is.

Not sure what the "(as opposed to an extension header)" means. Could you
elaborate/clarify a bit?



> Ideally, such devices should be configurable with a list of protocol
> header identifiers so that if new transport protocols are
> standardized after the device is released, they can be added to the
> list of protocol header types that the device recognizes.  Since any
> protocol header that is not a UDP header would be passed by the
> DHCPv6 shield algorithm, this would allow such devices to avoid
> blocking the use of new transport protocols.

So in summary, this argues in favor of DHCPv6-Shield not having only a
hardcoded list of protocols/EHs that it should pass, but to also allow
that list to be expanded, so to speak, right?

If so, that's sensible, too. The only thing that I'd probably change is
s/transport protocols/Next Header values that do not represent Extension
Headers/, since it's more general (e.g., something new protocol ala
ICMPv6 should be passed.. but ICMPv6 is not a transport protocol).


> When an implementation must stop searching for recognizable header
> types in a packet due to such limitations, whether the device passes
> or drop that packet SHOULD be configurable.

Should we say anything about the default setting? From a security
standpoint, it shoudl clearly default to "drop".. otherwise
DHCPv6-Shield would be easily evasible by inserting an appropriate
number of IPv6 EHs.

Thoughts?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492