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

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

On Sun, 8 Feb 2015, Pete Resnick wrote:
> On 2/8/15 11:01 PM, Ted Lemon wrote:
> > Can you explain, in detail, what a DHCPv6 packet would look like that would
> > get past a filter because either it used unknown extension headers, or an
> > unknown protocol header?
> >    
> 
> Better yet, could you give an example packet with a fake new extension header
> that a middlebox would think is not a DHCPv6 packet, but in fact is?

Not with a fake extension header, but with a real one.  Suppose:

- A new extension header is defined that make sense to sandwich in 
  front of a DHCPv6 packet (not all do; some extension headers are 
  required to have a next header value of "no next header")

- This extension header is unknowm to a DHCPv6-Shield implementation

- This is extension header is known and considered valid by a host 
  that DHCPv6-Shield implementation is trying to protect

If I correctly understand Ted's position, he is saying that a 
DHCPv6-Shield implementation should unconditionally pass a packet 
containing a next header value it does not recognize.  In that case, 
a DHCPv6 packet containing the hypothesized new extension header 
described above would pass through the DHCPv6-Shield implementation 
and be processed by the host.

The current DHCPv6-Shield draft (and the variant language I proposed 
a few messages back) takes the position that whether a DHCPv6-Shield 
implementation passes a packet with an unknown next header value 
must be a user configurable option.  Some users may consider the 
above scenario too improbable to worry about and configure packets 
with unknown next header values to be passed.  Other users of a more 
paranoid persuation may have a different point of view.

Sorry, I said I was going to shut up.  Now I will.

//cmh