Hello Joel, do you mean that "because there are already other possibilities for covert channels, this WG should not bother if its work creates yet another one" ?
In the book "IPv6 Security", lower half of page 32, (ISBN-10: 1-58705-594-5 - ISBN-13: 978-1-58705-594-2) the authors refer to the destination extension header as a "covert channel". And quite correctly so, in my opinion : the PadN option allows two parties to exchange arbitrary data that looks, L4 upwards, like HTTP/DNS/ping6 (especially DNS - a covert channel by itself ! - is often allowed very liberally). Kind regards, Marc On Mon, Nov 19, 2012 at 9:01 PM, Joel M. Halpern <[email protected]> wrote: > Taking things out of order: > > If you are really going to lock covert channels, then you will have to block > HTTPS except to known sites (and check the hostname against the IP address, > etc...) That has not, and I hope is not, and acceptable design space for > the IETF. > > With regard to unknown extensions and broken implementations, there are two > issues. First, as Brian pointed out earlier, firewalls need to have dates. > If you are not willing to do that, then you will be vulnerable anyway. > Second, since the firewall does not know what already defined extensions are > mis-implemented in some host, you are already vulnerable on this front. In > fact, a broken implementation trying to process something is far more likely > than a broken default case. > > Yours, > Joel M. Halpern > > > On 11/19/2012 2:48 PM, Marc Lampo wrote: >> >> 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 >> <[email protected]> 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 >>>> <[email protected]> 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: [email protected] >>>>> Reply-To: [email protected] >>>>> To: [email protected] >>>>> >>>>> >>>>> 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 >>>>> [email protected] >>>>> 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 >>>>> [email protected] >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>> >>>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
