+1 The packets themselves might be normal, but the packet arrival rate might be where the covert information is conveyed.
----- Original Message ----- > From: Ray Hunter <v6...@globis.net> > To: Joel M. Halpern <j...@joelhalpern.com> > Cc: 6man <ipv6@ietf.org> > Sent: Tuesday, 27 November 2012 7:35 AM > Subject: Re: Re: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt] > > +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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
