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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
