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

[Brian Haberman <[e-mail]>]

Let me chime in here with two points...

On 2/9/15 1:02 AM, C. M. Heard wrote:
> 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

The above is a typical scenario where different code bases update their
capabilities on different time scales.  Any time a new feature/function
is added, there will be a risk of incompatible functionality within the
set of devices that compose the network path from source to destination.

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

I have interpreted Ted's position to be that this document should simply
point to RFC 7045 (or its successor) for handling unknown extension headers.

Regards,
Brian