[ipv6hackers] Fwd: Some stats on IPv6 fragments and EH filtering on the Internet

[Enno Rey]

Hi,


On Mon, Nov 04, 2013 at 03:57:51PM -0800, Fernando Gont wrote:
> On 11/04/2013 03:49 PM, Eric Vyncke (evyncke) wrote:
> > Interesting piece of data, it is even worse than what I guessed before
> 
> Yep. I had the same reaction: I didn't expect it to be that bad. :-(


I'd like to take this (statement) as a starting point to another discussion.
Both of you (Fernando and Eric) seem to imply that filtering packets with EHs and/or fragmentation is actually a bad thing. Wearing my "IPv6 enthusiast" (and "net citizen") hat I can support that stance.
Wearing my "[IPv6] security practitioner" hat I explicitly can _not_. We, for example, mainly consult to (networking/security teams) from very large enterprises. For them - and there's certainly some intersection with the Alexa top sites used as data sets both by Fernando and Tim/his student - handling of EHs/fragmentation comes down to a simple cost/benefit or risk evaluation like

a) what's the actual need/benefit of letting $SOME_TYPE_OF_IPV6_PACKETS into our network?
b) what's the risk associated with $SOME_TYPE_OF_IPV6_PACKETS?
c) is it worth it?

Let's first recognize that there's a lot of IPv6 security issues related to fragmentation and/or extension headers, just see the number of IPv6 related CVEs containing the word "fragments" or have a look at Antonios Atlasis' work (http://www.insinuator.net/2013/06/slides-scripts-from-antonios-atlasis-advanced-attack-techniques-against-ipv6-networks-workshop/). So one can probably state that there is some _relevant risk_.

Now, what about the actual production need/benefit from such packets? Let's split $SOME_TYPE_OF_IPV6_PACKETs into three categories

a1) fragmented packets.
a2) packets containing one of the three following extensions headers: HBH, destination header, routing header.
a3) packets containing a combination of the two above (read: fragments with HBH, destination and/or routing header).


As of late 2013 I personally can't really see much use/need for fragmented IPv6 traffic at all. We had this discussion before here and elsewhere (and it now takes place at each IETF meeting) so there's probably not much need to re-ignite it here. Still, I tend to think that most enterprise "end user" organizations (as opposed to service providers of different types, and even those might just allow IPv6 fragments to get rid of annoying discussions with customers of the "there's connection problems with our hosted SAP, might that be related to your filtering approach?" type) don't have any need to allow fragmented IPv6 traffic into their networks.
Let's go with a cautious "it depends" for the "a1" type then.

As for the above type "a2" (packets containing HBH, destination, routing headers): I'm aware that HBH is used by MLD, which in turn does not traverse L3 hops/security gateways. I'm further aware that routing header 2 might be used in Mobile IP scenarios, but given Mobile IP hasn't gained any ground so far (and will - probably - not play any role outside telco operator networks in the next years) I tend to assume there's no header for routing headers in the vast majority of "end user" enterprise networks in the foreseeable future.

As for the "a3" type I'd be very happy to learn about any IPv6 service or application generating or relying on such packets. Sure, I know the "in the future there might be IPv6 services we don't know of yet, that's what we built IPv6 for"line of reasoning. Given the apparent reality out there (expressed in the numbers of Fernando's presentation and Tim's [student's] work) it might just not be a very smart idea to come up with a future service/application of that type ;-)

So it turns out that all three subtypes of $SOME_TYPE_OF_IPV6_PACKETS I introduced above might not be used at all by "end user" enterprise organizations in the next years while at the same time having the potential of all sorts of nasty security issues. Hence it might actually be a quite reasonable approach to "simply drop all that crap at our network borders"...

Clearly this is yet another tragedy-of-the-commons in the IPv6 space and it "hurts" relevant IPv6 design objectives (end-to-end principle, openness & flexibility et.al.).
But from an individual organization's perspective it might be just a smart risk & reward decision.

my 0.02,
best

Enno  


On Mon, Nov 04, 2013 at 03:57:51PM -0800, Fernando Gont wrote:
> On 11/04/2013 03:49 PM, Eric Vyncke (evyncke) wrote:
> > Interesting piece of data, it is even worse than what I guessed before
> 
> Yep. I had the same reaction: I didn't expect it to be that bad. :-(
> 
> Cheers,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont at si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers

-- 
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

Troopers 2013 Videos online: http://www.youtube.com/user/TROOPERScon?feature=watch

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
=======================================================