On 20/11/2012 07:53, Marc Lampo wrote: > 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).
I don't think we should confuse the discussion of firewalls attempting to prevent malicious attacks with snooping for covert channels. That is a completely different aspect of security. Brian > > > Kind regards, > > Marc > > > On Mon, Nov 19, 2012 at 9:01 PM, Joel M. Halpern <j...@joelhalpern.com> 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 >>> <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 >>> -------------------------------------------------------------------- >>> > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
