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

["C. M. Heard" <[e-mail]>]

On Tue, 10 Feb 2015, Fernando Gont wrote:
> On 02/10/2015 02:48 PM, Ted Lemon wrote:
> > 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).

Yes indeed, the problems we've been arguing about all get solved 
satisfactorily if the device sports a table that allows each of the 
undefined Next Header values to be be treated either as identifying 
either an upper-layer protocol, which should be passed, or as an 
extension header that follows the rules of RFC 6564, which can be 
skipped while parsing the header chain.

For the purposes of this discussion, "undefined Next Header values" 
means the values in the Protocol Numbers registry 
(http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml) 
that at the time of implementation are unassigned, PLUS the 
experimental values 253 and 254 (which could be either an 
experimental extension header or an experimental protocol), PLUS the 
reserved value 255.  Currently that would be 143 and up.

> > 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.

I would say MUST be configurable, otherwise it cannot comply with 
RFC 7045.

> 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.

I would be fine with lifting the agnostic "the default configuration 
MAY drop such packets" from RFC 7045 but I am not wedded to this.

//cmh