Hello, (didn't see summary of discussion in Atlanta yet, so bear with me if I would repeat something brought in there) (and my appologies for the long email)
Paragraph 4 of the Introduction states : "The main reason for this is that some firewalls attempt to inspect the transport header or payload." Is this a factual statement or do I read a negative undertone ? As a security person, I see the purpose of a firewall is to protect internal assets from potentially dangerous "things" trying to get in. This includes stopping traffic that is not conform to standards. So, to me, "attempting to inspect the transport header or payload" is simply a basis funcionality of the firewall. The draft already addresses the behaviour towards unknown extension headers. The statement, section 2, "If a firewall chooses to discard a packet containing a defined IPv6 extension header, it MUST be the result of an explicitly configured firewall policy, and not just the result of a failure to recognise such a header." seems in contradiction with what a firewall has to do : inspect traffic ! Because : how can a firewall distinguish between a newly defined extension header or type in an existing header and a potential malicious character combination ? If a firewall drops extension headers (except fragmentation) but provides documentation to selectively allow (and verify) others or if a firewall allows extension headers and allows the admin to seclectively block (known) headers they both lose in case of newly defined headers or option types : The first one has no code to verify, the second one has no provisions (GUI selector) to block. I'd feel safer with the first type of firewall ... Anyway, since IPv6 should be considered to be "in production" already, and security equipment is being put in place, I hope we won't see any changes at all in this area at all. Perhaps the appropriate WG should not be to enthousiastic in adding headers or options in the first place ?! Another aspect of extension header (verification), not addressed in this draft (nor, after rereading RFC 2460 for this subject) is the fact that rules are defined. RFC 2460 states extension headers have a specific order. What should security equipment do if it detects the order is not respected ? (some hacker might be searching for obfuscation or undesireable side effects ?) I suggest this draft is completed with statements on this situation. (presently, it only addresses type and content of extension headers, not the order) And, in the same line of thinking, RFC 2460 does not seem to limit the number of extension headers ?! Since the first field in any extension header is "next header", nothing prevents an extension header to state the next one is of the same type ! But two consecutive fragmentation headers don't make sense, do they ? Yet, it doesnot seem to be forbidden. (don't say this cannot happen, perhaps it's the hacker, in search to obfuscate or side effects ...) ((no firewall vendor I've contacted so far has been able to give me a straight answer on how its product would behave in that situation ...)) Kind regards, Marc On Tue, Nov 13, 2012 at 12:02 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > Updated after the discussions in Atlanta. More discussion wanted... > > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-6man-ext-transmit-01.txt > Date: Tue, 13 Nov 2012 02:38:38 -0800 > From: internet-dra...@ietf.org > Reply-To: internet-dra...@ietf.org > To: i-d-annou...@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Transmission of IPv6 Extension Headers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-carpenter-6man-ext-transmit-01.txt > Pages : 8 > Date : 2012-11-13 > > Abstract: > Various IPv6 extension headers have been defined since the IPv6 > standard was first published. This document updates RFC 2460 to > clarify how intermediate nodes should deal with such extension > headers and with any that are defined in future. It also specifies > how extension headers should be registered by IANA, with a > corresponding minor update to RFC 2780. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ext-transmit-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
