+1. If anyone wants to be able to guarantee blocking any ability to construct a covert channel over a communication path, then they should probably employ a messaging protocol that is fully defined from the ground up using a formal grammar. Then they could check all (application level) messages against that grammar at all points along the transmission path. But that's almost certainly not going to be an Internet protocol.
I also suspect a number of IPv6 security books are going to have to be rewritten, and that "stateful firewall" devices (or indeed any stateful mechanisms located at the entrance to a site) are themselves likely going to become the target of (DoS) attacks. I therefore suspect many of these functions are going to have to be devolved, perhaps all they way to the end hosts, or even the application layer itself. regards, RayH Joel M. Halpern wrote: > Yes, I think that having the IETF attempt to define rules for avoiding > covert channels in IPv6 packets is actively counter-productive. It > impedes innovation without providing a meaningful increase in security. > > Yours, > Joel > > On 11/20/2012 2:53 AM, 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). >> >> >> 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 --------------------------------------------------------------------
