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