Hi, Brian, On 02/09/2015 10:12 AM, Brian Haberman wrote: [....] >>> 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.
Exactly. The same applies to Ted's concern: the newly-specified IPv6 EH would be "incorporated" by DHCPv6 implementations and hence would not be dropped. >> 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. It doesn't seem to be so. Brian Carpenter himself (co-author of RFC7045) noted that we comply with RFC7045. We simply state what the default should be, and normatively reference RF7045, since that's the document on which we've based our requirements. So I don't understand what's the issue here, since we *are* complying with the current (6man's) recommendations on the topic. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
