Fred, On Wed, Jun 17, 2015 at 04:46:03PM +0000, Fred Baker (fred) wrote:
Cutting to the chase, on the surface it looks like most of the cases you specified conform to the sequence rule, with the exception of one that has three Destination Option Headers. What I *think* you're pointing out is (from your PDF) that this is part of a sequence of messages, one of which is fragmented, accepted by the intrusion detector, and not accepted by the ultimate host (perhaps a TCP checksum failed?), and as a result bypasses the signature that the intrusion detector is looking for. The issue wasn't that the sequence was incorrect, in most cases; it was that the intrusion detector made a different choice than the end host.
Let's put it slightly different: the intrusion detector is supposed to detect/block certain application layer attacks. Which it does as long as those come in/pass by without extension headers/fragmentation. Once the attack packets are crafted in certain ways, the intrusion detector let's them through, the end host happily reassembles and gets hit. The end host does so as the overall datagram does not violate RFC 2460's (dubious) liberty. The detector is "blind" as parsing a single datagram split into an arbitrary number of fragments with an arbitrary number of extension headers in a (mostly) arbitrary order is a, well, complex task. It's not only intrusion detectors facing this type of difficulty, it's other "black list approach" security controls (like so-called First Hop Security features or Infrastructure ACLs), too. [see, for example, http://www.insinuator.net/2015/01/dhcpv6-guard-do-it-like-ra-guard-evasion/).
Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)?
'm tempted to reply that this would make the Internet world a safer place (without losing any current functionality) and might speeden up overall IPv6 deployment, as some organizations had one (for some of them: severe) concern less. So it's not about my personal happiness; though the factors mentioned might actually contribute to that as well ;-).
From that angle RFC 7112 is certainly a step into the right direction. It's just not widely implemented - while IPv6 is "finally here" - and it doesn't "solve" certain cases (see the link above). That's why I think that a major revision of the whole extension header concept is needed.
Best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================