Hello Brian, (as I expected, you were the first to react - didn't let me down on that one ;-)
We have a different starting point to look at "things" : as I wrote, one reason for incorrect packets might be an attacker looking for unexpected behaviour, undesirable side effects. I understand and appreciate your point of view is sometimes different : "What is so dangerous about an unknown extension header? The receiving host will either understand it or drop it." --> perhaps the attacker looks for an implementation that does poor checking on extension header codes or option types. If handling is via a table without proper index value checking, perhaps such a kernel will crash upon receiving the unexpected packet. In my opinion : the firewall is what should protect such a (poor, I agree) server. (because the server behaves correct on known codes and combinations) --> perhaps both partners do understand the extension header code, and (ab)use it to create a hidden data channel in a conversation that looks - at layer 4 + upwards - like one thing but carries undesired data in the IPv6 header (+ extensions). Again, in my opinion : what use is any "Data Leakage Prevention" solution if security equipment allows unknown extension headers and option codes to pass without problem ? (when refering to multiple fragmentation headers) "But since any receiving host should obviously drop such malformed packets, it would be fine for firewalls to drop them too." --> (we agree there ;-) but according to RFC they are *not* illegal, are they ? RFC 2460 does not forbid two or more fragmentation headers. One does not expect them, but again, I'm vigilant for the attacker in search of undesired side effects. And I think we've had, since the 90's a lot of security issues that had "unexpected" / "never thought we'd see this combination for real" packets arriving at some server. (and not only with IP(v4) - also in layer4 and higher (L5-L7) protocols !) That is why I feel uncomfortable with any security advice that states : check what you understand, and allow what you do not ... Kind regards, Marc On Mon, Nov 19, 2012 at 5:37 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > Hi Marc, thanks for the comments. > > On 19/11/2012 10:54, Marc Lampo wrote: >> 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 ? > > It's intended to be factual. As described later, the attempt fails > if the the firewall in question does not follow the entire header > chain for one reason or another. > >> 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. > > Right, and the IPv6 standard says that all extension headers should be > forwarded. That's exactly the problem. > >> 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 ! > > A firewall that doesn't understand some of the defined headers is clearly > inadequate to completely inspect the traffic. The requirement for an > explicit policy is to make sure that the network is transparent by default, > with blocking being a human choice. > >> Because : how can a firewall distinguish between a newly defined >> extension header or type in an existing header >> and a potential malicious character combination ? > > My computer annoys me very frequently with security updates. A firewall > should be updated in the same way, very soon after a new extension is defined, > which will be a great deal less frequent than the discovery of new viruses. > >> 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 ... > > What is so dangerous about an unknown extension header? The receiving > host will either understand it or drop it. > >> 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. > > It's broken today, so we have to do something. This draft attempts > to repair broken firewalls. Anything else will be much more drastic. > >> Perhaps the appropriate WG should not be to enthousiastic >> in adding headers or options in the first place ?! > > That would be very sad - the end of innovation in the network layer. > In fact, the IETF has not been prolific in this area, and won't be, > unless we can fix the problems caused by firewalls and DOS defence. > >> 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) > > This draft is about making the Internet transparent to extensions, so I think > this aspect is out of scope. I'm not sure that there are any attacks based on > misordered extension headers, but if so, I think that deserves a draft of its > own. > >> And, in the same line of thinking, RFC 2460 does not seem to limit >> the number of extension headers ?! > > Nor the amount of padding. This is where the fragmentation-based attack > mentioned in draft-ietf-6man-oversized-header-chain comes from. > >> 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 ...) > > Overlapping fragments are forbidden (RFC 5722) but that is a different matter. > Also see draft-ietf-6man-ipv6-atomic-fragments. Formally forbidding > multiple fragment headers seems a bit like overkill, since clearly > no sane host will do that. > > The general issue is discussed in draft-ietf-6man-oversized-header-chain, > which aims to defeat the fragmentation attack. > >> ((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 ...)) > > Again, I'm not sure there's a real attack there - if there is, it might > be an attack against weak firewall code, which frankly I don't care > about. But since any receiving host should obviously drop such > malformed packets, it would be fine for firewalls to drop them too. > The concern is about firewalls that drop well-formed packets! > > Regards, > Brian > >> 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 --------------------------------------------------------------------