Atomic Fragments vs. Fragmentation in the IPv6 “Real World”

This is a guest post by Antonios Atlasis.

Continuing the discussion about the IPv6 Atomic Fragments started at the IPv6 hacker’s mailing list and the freshly proposed draft RFC regarding the deprecation of the generation of IPv6 Atomic Fragments, we decided to check very quickly what is the current situation regarding the acceptance or the rejection of Atomic fragments in the “real world”. Thanks to Rafael Schaefer and the RISC lab at ERNW, we got some first measurements really fast.

As an initial input list, for reasons of “rough” comparison, we used a list provided by Fernando Gont during an internal workshop he gave at ERNW earlier this year. This initial list included 1425 hosts in total.

We decided to perform our tests using TCP SYN packets to port 80, since we believe that this is the port where most hosts in the real world listen to. First, we wanted to confirm that we could reach our final targets, without using any kind of IPv6 Extension Headers for whatever reason. By doing so, we received:

– 1113 SYN-ACK messages.
– 36 RESET-ACK messages.
– 59 ‘ ICMPv6 ‘, ‘Destination unreachable’, ‘Address unreachable’ messages.
– 43 ‘ICMPv6 ‘, ‘Destination unreachable’, ‘No route to destination’ messages.
– 8 ‘ ICMPv6 ‘, ‘Destination unreachable’, ‘Communication with destination administratively prohibited’, messages.
– 5 of those were sent by the devices themselves, while the rest were sent by another, probably by a firewall.
– 7 ‘ ICMPv6 ‘, ‘Time exceeded’, ‘hop limit exceeded in transit’ messages.
– 2 ‘ ICMPv6 ‘, ‘Destination unreachable’, ‘Reject Route to Destination’ messages.

So, 1268 responses in total. The rest were silently dropped, obviously.

From the above responses we decided to use for our testing purposes only the ones where the final target responded, either with SYN-ACK (1113 hosts) or with a RESET-ACK (36 hosts), 1149 hosts in total.

Then, we sent traffic only to these 1149 “targets”:

A. By using Atomic fragments and
B. By fragmented our IPv6 datagram in two simple fragments.

We got:

A. When Atomic Fragments are used:

954 SYN-ACK (out of the initial 1113, acceptance percentage 85.7%. Not that bad).
35 RESET-ACK responses from the final targets

In summary, (954+35)/(1113+36) =  86.07% in total acceptance rate!

B. Simple Fragmentation

When the TCP SYN  packet is fragmented in two simple fragments (but we made sure that the first carries the whole TCP header and the second just the payload to avoid any rejection due to moving part of the layer-4 header at the second fragment).

674 SYN-ACK responses were received (acceptance percentage: 60.55%).
31 RESET-ACK from the final targets (2 RESET-ACKs were sent by intermediate devices, the reset were silently dropped).

In summary, (674+31)/(1113+36) =  61.36% in total acceptance rate!

The corresponding drop rate (38.64%) seems to be even higher than the one described by Fernando (28-30% for web servers) at the “IPv6 Extension Headers in the Real World” draft RFC.

Note: For the time being, we deliberately did not distinguish cases where an intermediate node rejected the traffic towards two or more end-nodes, because our goal was to check how many of them were (not) reachable, for whatever reason. Of course, this means that our sample should be chosen very carefuly in order to be representative.

To sum up:

So, it seems that the acceptance rate of Atomic Fragments (86%) is not that bad (but still, far away from the 100% that we should have in an ideal IPv6 situation), while this rate significantly deteriorates when real IPv6 Fragmentation is used.

Disclaimer: By no means we consider this to be a fully scientific approach, since the sample that we used was not that big. We believe that the tests must be repeated by using much more samples in order to calculate the acceptance ratios per case, as well as the corresponding confidence intervals.

Personal Comment:

I am not blaming administrators, operators, etc. for dropping IPv6 Extension Headers in their environment. From a security perspective, I would definitely do the same: You do not need something, you do not use it. This is why we close all the ports not used in our servers, right? I would take that risk, only if there was a need to use them, for whatever reason. However, the same argument is used by the ones who still refuse to deploy IPv6 in general, right?

However, does this mean that all these IPv6 “functionalities” (aka Extension Headers) should be deprecated? I don’t know. I believe not. No one can be sure that some of them may be needed tomorrow, right? So, for me, the right approach is exactly what happens right now. Leave them as they are (I am not talking about Atomic Fragments but about Extension Headers, generally speaking), drop them now since/if you do no need them, re-enable them later very carefully if/when some of them are needed. Because, I suppose that IPv6 was designed to be the next layer-3 protocols for many-many years, right? Unless, of course, you are a 100% that they are completely uselless, both for now and for the future.

In the meantime, vendors (of networking devices, security devices, operating systems, etc), with all my respect, please do some proper, in depth, testing to your products. We have seen a lot! Not the best approach to come after a vulnerability has been published in order to fix it. You should rather act proactively.

Best

Antonios

BTW: there will be talk about this stuff with much more detailed results at the IPv6 Security Summit 2015 next March, and – of course – another one about our ongoing research on architecture flaws & (implementation) vulnerabilities in MLD.