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

[Ted Lemon <[e-mail]>]

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:

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.

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.

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.