The Story Continues – Another IPv6 Update

TROOPERS12 came to an end last week on Friday; needless to say it was an awesome  event. 😉
The first two days offered workshops on various topics. On Monday Enno, Marc “Van Hauser” Heuse and I gave a one day workshop on “Advanced IPv6 Security”.  I think attendees as well as trainers had a real good time during and after the workshop fiddling around with IPv6. Especially Marc had quite some fun as he discovered that we provided “global” IPv6 Connectivity for the conference network, and according to one of his tweets, TROOPERS12 was the first security conference he visited, offering this kind of connectivity.

So back to the topic

Our last posts on IPv6 Security go back to the first half of 2011. If you haven’t read them already, now it’s a good time to do so. You can find them here, here, here and here.

In the last post of the series Enno discussed how RA-Guard can be circumvented with clever use of extension headers. As a short reminder, the packet dump looks like this.

The Information of the upper-layer protocol is only present in the second fragment, so RA Guard does not kick in.

As we found out on the Heise IPv6 Kongress last year, this issue can be mitigated with the following parameter in an IPv6 ACL.

deny ipv6 any any undetermined-transport

As a reminder, this parameter drops all IPv6 packets where the upper-layer protocol information cannot be determined.

After the workshop was officially over, Marc and I played a little bit with this ACL Parameter to see if it is working as intended. So I configured the following IPv6 ACL on our beautiful Cisco 4948E:

4948E(config)#ipv6 access-list IPv6
4948E(config-ipv6-acl)#deny ipv6 any any undetermined-transport
4948E(config-ipv6-acl)#permit ipv6 any any
4948E(config)#interface g1/19
4948E(config-if)#ipv6 traffic-filter IPv6 in

We started the attack again with the following parameter:

Apparently nothing happened with my (IPv6 enabled) laptop (which is a good thing ;))

The corresponding packet dump looked quite unspectacular:

Only the STP packets could be seen, and the flooded router advertisements were dropped by the Switch.

So could this parameter solve the issue with the whole RA mess?

Unfortunately the answer is no. The ACL parameter does mitigate the issue with the fragmented router advertisement. However, the ACL parameter can be circumvented by using overlapping fragments. Unfortunately we couldn’t test this scenario because this wasn’t yet implemented in the THC Tool Suite, but this is just a matter of time…

The IPv6 Packet  basically looks like this:

Fragment 1:
IPv6 Header
Fragmentation Header
Destination Header (8 bytes)
ICMPv6 with Echo Request
Fragment 2:
IPv6 Header
Fragmentation Header with offset == 1 (equals position of 8th byte ==
start of Echo Request in first fragment)
ICMPv6 with RA


In this case it depends on the operating system whether or not the packet is discarded when overlapping fragments are detected. RFC 5722 is very specific on how these should be handled:

“When reassembling an IPv6 datagram, if one or more its
constituent fragments is determined to be an overlapping
fragment,the entire datagram (and any constituent fragments,
including those not yet received) MUST be silently discarded.”

So it is up to the operating system to implement this behavior. We’ll see how things work out 😉

If you’re interested in more IPv6 issues, or simply wanna chat about this topic, meet Enno and me again at the  Heise IPv6 Kongress this year in Frankfurt, where we will give a talk on IPv6 as well.

Have great day,


Leave a Reply

Your email address will not be published. Required fields are marked *