Most IPv4 networks are managed using DHCP and as a result are subject to attacks via rogue DHCP servers. In response, many switches implement "DHCP Snooping" as a feature to protect from these attacks.

As networks switch to IPv6, DHCP will become less used. Some operating systems, like for example OS X, don't even implement DHCPv6. Instead, router advertisements will be used to help systems discover the network and to configure themselves. But just like DHCP, router advertisements (RA) may be spoofed. To protect your network from rogue RAs, a switch may implement RA-Guard [1], a feature similar to DHCP Snooping.

RA-Guard will only forward RAs, if they are received on a port known to be connected to an authorized router. Additional filtering may happen based on the MAC address of the router.

A recent IETF draft outlines some deficiencies of RA-Guard and how to possibly evade RA-Guard. The basic premise of RA-Guard is that the switch, a layer 2 device, is able to inspect the IPv6 and ICMP6 headers (layer 3) as well as the ICMP6 payload in order to identify and interpret RAs. In particular for IPv6, this is not an easy task and the evasion techniques outlined in the IETF draft are a nice lesson in the difficulties of correctly interpreting IPv6 traffic.

First of all, there is the potential for extension headers. Router advertisements *should not* have any extension headers, but there isn't really anything to prevent that from happening and per RFC, it is legal. However, as soon as we are dealing with extension headers, the "Next Header" field in the IPv6 header can no longer be used to identify the packet as an ICMP6 packet. Instead, the switch will have to find the last header and use it's Next-Header field.

Processing the entire header chain will take more resources and in the end, may limit the through put of the switch or even lead to denial of service conditions.

Next, the RA messages may be fragmented. This is again a condition that should not be seen in a *normal* network, but then again, attackers may very well craft legal RA packets that are fragmented. The fragmentation could be used to only show the IPv6 header and some extension headers in the first fragment, and move the header indicating the ICMP6 header, as well as the actual ICMP6 header, to the second fragment. Of course, this could be made even more interesting with multiple fragments.

Oh... and remember: Wednesday is IPv6 day :) We will have more about that later.

[1] http://tools.ietf.org/html/rfc6105
[2] http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt

IPv6 Security Summit is coming July 15th, Washington DC,  http://www.sans.org/ipv6-summit-2011

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter