Re: draft-carpenter-6man-ext-transmit-01.txt

[Ray Hunter]

Brian E Carpenter 15 February 2013 09:24 On 14/02/2013 21:15, Ray Hunter wrote: Brian E Carpenter wrote: https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit/ There was some discussion of this draft when it came out, but nothing that led to any specific changes. We should perhaps emphasise that it's complementary to draft-ietf-6man-oversized-header-chain. I'd like to ask for opinions about taking this draft forward. I won't be in Orlando, but the other author (Sheng) will be. Regards Brian You can write what you like about firewalls needing to have an explicit policy configured (manually) before dropping any packets. Ray, the IETF is supposed to make the Internet work better. So we should write down requirements for that to happen. Well IMHO I think the requirements are precisely the other way around: extensions should be simple to parse, demonstrably not a security issue or likely to cause harm, and useful:  not that firewalls should blindly pass everything thrown at them. Hop by hop has already been labelled potentially harmful in http://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05. The market is still deciding what headers are "good". And this standard will then (quite rightly) be ignored by every single firewall manufacturer I know. That parenthesis is a value judgement, but in any case, the idea of the draft is to push implementors in the direction of parsing all well-defined extensions, and of making policy control possible. Agreed. I'd support a draft with these goals, but let's keep it realistic. If an extension proves itself safe, easily parse-able, and useful, it will be transported over the public Internet. If it doesn't, it will get dropped. At the moment this is impossible. There is no place for firewall implementors to find a master list of all well-defined extension headers and no way for site IT managers to configure firewalls to block or allow specific extension headers. So there is no way for a new extension header to prove itself safe and viable. It's pure Catch 22. Providing a clear list of extensions in a repository, what their benefits are, and how they work, is a completely different matter to mandating behaviour of  middleware boxes that is directly contradictory to current industry best-practice. Firewalls should be designed to make new extension headers subject to user control, and the IETF should structure its designs, documents and IANA registries to make life as easy as possible for both firewall implementors and users. Agreed. Extensions should also clearly have been designed with firewalls and other middleware boxes in mind. And new extensions should too. Firewall code and other middleware box code will always significantly lag IETF standards. I don't really see how the Uniform Format header structure defined in http://tools.ietf.org/html/rfc6564 truly addresses the firewall issue. If we were starting from scratch I'd prefer that unknown extensions should be easily "strippable", rather than having to drop the entire packet if they cannot be parsed, or still having to traverse the full chain without truly understanding the contents and then passing that unknown content into a secure zone. How you achieve that practically I don't really know. Thinking out loud, we could potentially define yet another new extension header that defines a fork in the header chain: next header field = following (optional) header extensions, plus length to reach the next header as per RFC6564; final header field (contained as header specific data within the new header) =  top level protocol of the final header value e.g. TCP= 6, plus offset to reach the final payload header in either octets or 8-octet units.     0                   1                   2                   3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |  Next Header  |  Hdr Ext Len  | Final Header  | offset to     |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    | final header  |                                               |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ That in itself of course will not be fully backwards compatible. But at least it would be a once-off action. And firewalls could strip out the optional headers, whilst easily locating and parsing payload data. regards, RayH That's what we need to fix. We can maybe state it more clearly in the draft; thanks for pointing to the existing Catch 22. Brian Ray Hunter 14 February 2013 22:15 You can write what you like about firewalls needing to have an explicit policy configured (manually) before dropping any packets. And this standard will then (quite rightly) be ignored by every single firewall manufacturer I know. If an extension proves itself safe, easily parse-able, and useful, it will be transported over the public Internet. If it doesn't, it will get dropped. regards, RayH

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------