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

[joel jaeggli <[e-mail]>]

On 2/10/15 12:49 PM, Ted Lemon wrote:
> On Feb 10, 2015, at 1:38 PM, Fernando Gont <[e-mail]>
> wrote:
>> Not sure what the "(as opposed to an extension header)" means.
>> Could you elaborate/clarify a bit?
> 
> What I'm proposing is that unknown codes can be assumed to be
> extension headers.   Any known code may be either an extension header
> or a protocol header, but then it's a known code, so not a problem.
> But rereading the text, that parenthetical does seem unnecessary.
> 
> Anyway, it sounds like we now have some text to argue about that we
> might be able to agree on, so I will defer to you on tweaking it--I
> just wanted to give you a sense of what I had in mind.   The main
> thing I want to avoid is a recommendation that the basic shield
> algorithm by default drop unknown extension and transport headers,
> but I agree that it's good to say what to do if the hardware can't
> support that fully.

We got a new version of this draft on 2/25 which I kinda of lost track
of in the midst of two IESG review calls.

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-opsec-dhcpv6-shield-06.txt

It stops short of  my interpretation  of Ted's position, with the
reordered and clarified test in section 3. the new explanatory text in
in the security considerations:

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