Keywords

IPv6 Neighbor Discovery, Router Advertisement, Rogue RA attack, RA Guard.

1. Introduction to NDP

The Neighbor Discovery Protocol (NDP) specified by RFC 4861 can be thought of as an IPv6 analogy to the set of IPv4 protocols, namely Address Resolution Protocol (ARP), ICMP Redirect and ICMP Router Discovery. To be more precise, it provides even more services, but as far as the Rogue RA Attack is concerned, the most important are Router Discovery and SLAAC. The main purpose of these services is to provide hosts with a unique IPv6 address and a default gateway. After a host connects to the network, the process is as follows:

1. A host creates an Interface ID, usually via EUI-64 procedure or in case of Privacy Extensions it uses a (pseudo)random ID.
2. The host creates a link-local IPv6 address by appending an Interface ID to the FE80::/10 prefix.
3. The host discovers routers by sending Router Solicitation (ICMPv6 message type 133).
4. IF there are any routers on the link, they announce themselves by replying with Router Advertisement (ICMPv6 message type 134), including:
   - Advertised prefix
   - Router Lifetime – a positive value indicates the remaining time a router is willing to behave as a default gateway
   - Additional parameters such as MTU, etc.
5. The host receives a Router Advertisement, creates an IPv6 Globally Unique Address by appending its Interface ID to the advertised prefix.
6. IF the Router Lifetime value is non-zero, it inserts the IPv6 address of a router to its Default Router List.

The following figure illustrates the whole process.

2. Rogue RA Attack

The main issue of the NDP protocol is that its messages are unsecured. Nodes receiving unsecured NDP messages cannot distinguish between valid and “bogus” NDP messages, so there are only two possible ways of treating them. Either to ignore (which is not acceptable) or to process all of them. This is a huge security issue, because an attacker can pretend to be a valid router and provide hosts with malicious information in order to disrupt their connectivity (Denial of Service) or worse, capture their data (Man-in-the-Middle). The outline of a typical MitM Rogue RA Attack can be as follows.

1. An attacker captures a valid Router Advertisement.
2. An attacker changes a Router Lifetime value to zero and sends such crafted message in order to force the victim to remove the current valid router from its Default Router List.
3. An attacker then creates another Router Advertisement, but this time announcing himself as a valid router, which effectively redirects the traffic through an attacker’s station. In fact, the traffic flowing back to the victim will be forwarded directly to the victim. An attacker can, however, perform a Neighbor Cache Poisoning Attack to change this, but this is beyond the scope of this article.

As mentioned above, currently there are few mitigation techniques available against this type of attack, but there is probably only one of them that is usable — RA Snooping.

3. RA Guard

Most of the networks have a common attribute that their nodes are on a link layer bonded by some intermediary device (usually switch), rather than directly. Such scenarios provide an opportunity to make use of a mechanism called RA Snooping. The idea of so-called snooping has been present in computer networks for long time, in the form of, for instance, IGMP Snooping or DHCP Snooping. It is well-known that switches use only information provided by link-layer header of received frames to forward them through the right interface. The concept of snooping exceeds this behavior in that the switch inspects also upper-layer information, based on which it takes beforehand defined actions. These actions have either optimizing (IGMP) or security (DHCP, RA) character.

RA Guard is a prevention mechanism against Rogue RA attack that utilizes RA Snooping. The key condition that must be met prior to RA Guard deployment is that there must be some intermediary device in a network that all traffic passes through. Typical example of such device is an Ethernet switch. RA Guard is implemented precisely on this device. The core functionality of RA Guard is that it inspects Router Advertisements and based on the information provided it decides whether to drop or forward them. Note that RA Guard is not any particular protocol or strictly defined mechanism. It is just common term describing a set of recommendations and general description of prevention mechanisms that were implemented by various vendors and appeared under various names. For example, while Cisco retains the name RA Guard, H3C uses the different label — ND Detection.

3.1 Configuring RA Guard on Cisco device

This section briefly describes, the configuration of RA Guard on Cisco devices. More details can be found in official Cisco documentation [4]

Switch(config)# ipv6 nd raguard policy POLICY-NAME   ! Defines the RA Guard policy name
Switch(config-ra-guard)# device-role {host | router} ! Specifies the role of the device attached to the port.

The RA Guard policy can have several other optional options checking the hop limit, router preference etc. After the policy is configured, it has to be applied to appropriate interfaces.

Switch(config)# interface INTERFACE
Switch(config-if)# ipv6 nd raguard attach-policy POLICY-NAME ! Applies the RA Guard policy

If a policy is configured with device-role host, a switch will drop any RA messages received on an interface where the policy is applied, thus eliminating the RA attack. Interfaces towards to a router should be configured with a policy where device-role is set to router.

3.2 Configuring RA Guard on H3C device

H3C devices incorporate RA Guard into more complex ND attack defense tool called ND Detection. Similarly to Cisco RA Guard implementation, also ND Detection function differentiates between trusted and untrusted ports. RA messages are not checked for correctness at trusted ports and are always forwarded.

[Switch] ipv6                                         # Enable IPv6, as it is disabled by default.
[Switch] vlan 1
[Switch-vlan1] ipv6 nd detection enable               # Enable ND Detection functionality on selected VLAN.
[Switch-vlan1] quit
[Switch] interface GigabitEthernet 1/0/1
[Switch-GigabitEthernet1/0/1] ipv6 nd detection trust # Set interface connected to router as trusted.

4. Bypassing RA Guard

Against the simplest form of this attack (i.e. IPv6 header and Rogue ICMPv6 message are the only content of an IPv6 packet) are both RA Guard and ND Detection effective. As it turns out, if an attacker modifies the Router Advertisement message in an appropriate way, RA Guard may not recognize such messages as bogus. For that purpose, an attacker can make use of the concept of IPv6 Extension Headers and/or IPv6 packet fragmentation.

4.1 RA Guard Bypass Using Extension Headers

Similarly to IPv4, also IPv6 provides the option to extend the protocol. IPv4 has the Options field in IPv4 packet header, which can contain an information of arbitrary length (with respect to the maximum length of an IPv4 packet and IHL maximum value) as specified by RFC 791. Some intermediary nodes, processing IPv4 packets need an access to upper-layer information (e.g. firewalls), but as the Options field is variable in size, the first octet of an upper-layer header must be calculated dynamically according to Internet Header Length (IHL) value of an IPv4 packet.

Also the specification of IPv6 (RFC 2460) provides a room for protocol extensions, but the realization is slightly different as with its predecessor. The size of an IPv6 header is now fixed, in order to speed up the forwarding process. The Options field is not present anymore, but its role was substituted by the Next Header field. Apart from the fixed-size main header of an IPv6 packet, there may be a number of supplementary Extension Headers. These Extension Headers are concatenated in a row, each containing the Next Header field in addition to data contained. Each Extension Header is identified by its identifier, which is contained in the Next Header field of a previous header. The semantics of the last Extension Header is the same as the Protocol field of an IPv4 packet (i.e. it identifies the payload of an IPv6 packet).

In most cases, ICMPv6 messages are transmitted without any Extension Header. Some of the implementations of RA Guard may reckon on this, so they inspect only the Next Header field of an IPv6 header. If it does not contain a value of 58, the packet is considered as non-ICMPv6, thus RA Guard does not prevent it from forwarding. This is, however, false premise, as an attacker can easily craft packets with additional Extension Header preceding the ICMPv6 message itself.

To build upon this idea, an attacker can concatenate more than one extension header in order to bypass RA Guard. In order to improve network performance, NDP messages inspection is usually implemented in hardware, which has limited resources. If an attacker creates a packet with absurdly long header chain and succeeds in exhausting all available resources of a switch, the device fails to identify spurious RA message and the defense fails. This may not be true for all devices, but there is a high probability that it may pose a significant challenge for low-end devices.

Further testing revealed that even RA Guard implementation of tested devices fails to inspect the whole chain of Extension Headers and already seven empty Destination Options Extension Headers are sufficient enough to bypass the RA Guard on tested Cisco devices. H3C device has even lower limit — three Extension Headers (see figure below). Tests have shown that if an attacker includes more than 16 extension headers (All of the conducted tests used empty Destination Options Extension Headers), the Cisco RA Guard Implementation is suddenly able to properly recognize bogus Router Advertisements. Based on the information provided by Cisco, hardware forwarding path is preffered to software forwarding. This means that if an IPv6 traffic filtering is in use, also Extension Headers must be inspected in hardware. In case of the header chain too large to fit into the resources allocated in hardware, the packet is punted to the software path. Based on this information, it is reasonable to assume that if a packet has an Extension Header chain short enough to fit into available resources, but consisting of sufficient amount of headers, so that they would not be inspected entirely, such packet would most probably not be dropped (Since this inspection is implemented in hardware, the number of headers that could actually be inspected must be fixed). This is probably only a flaw in implementation, but the fact remains that these devices are vulnerable from this kind of attack.

4.2 RA Guard Bypass Using Packet Fragmentation

The purpose of IP fragmentation is to transfer packets larger than the MTU of used link-layer technology. This is achieved by splitting the original packet into multiple fragments, each of the size less than given MTU and transferring each part separately, so that they can be reassembled by their receiver. As with IPv6, the idea remains the same as in IPv4, but there are some differencies. In IPv4, any device is allowed to fragment the transiting packet in case, when the MTU of a link that a packet is supposed to be sent to is smaller than the size of a packet itself. On the contrary, fragmentation of IPv6 datagrams is allowed only at the sender’s node. In case, when a datagram cannot be forwarded by some intermediary device because of too small MTU of the particular link, the device sends an ICMPv6 Packet Too Big message including the MTU that caused the failure to the sender. This behavior is a part of the Path MTU Discovery defined by RFC 1981, which is used to determine the minimum MTU size of all the links spanning from the sender to the receiver, so that IPv6 datagrams would not need to be fragmented. What is more, IPv6 specification requires that every link in the Internet have an MTU of 1280 octets or greater. Another difference from IPv4 is that in IPv4, all information needed for IP fragments assembly at receiving node are present directly in IPv4 header. On the other side, IPv6 excluded this information from an IPv6 header and introduced separate Extension Header for that purpose, because its aim is to avoid packet fragmentation at all.

The concept of IPv6 packet fragmentation can be exploited to bypass RA Guard. The idea is as follows. An attacker inserts additional Extension Header (e.g. Destination Options), splits the Rogue RA message into more fragments, and sends them separately. Therefore, also a device with RA Guard configured will treat these fragments separately. Note, that most of the IP networks ensure high availability by means of path redundacy and therefore, if there are multiple paths available between the sender and the receiver, each fragment can take another path. Following figure illustrates the original Rogue RA message, prior to fragmentation, and the two resulting fragments which are subsequently sent as a part of the attack.

In this case, a device processing the second fragment is unable to locate the ICMPv6 header contained in this fragment. The reason for this is following. To locate the first byte of an ICMPv6 header a device needs to know the length of a previous header, which is, however, present in the first fragment. Thus, by leveraging the use of a Fragment Header together with another Extension Header (in our case Destination Options), the attacker is able to conceal the content of an ICMPv6 message including its type. The transit device with RA Guard configured has only two options. Either it blocks all such fragmented messages including those that are valid, or it forwards all of them, including the malicious ones. The reasonable choice is the second one, as it is unacceptable to drop any valid traffic.

If an attacker uses the approach mentioned above, a snooping device can at least detect that the original packet was an ICMPv6 message, since the Next Header field of the last Extension Header of the first fragment is set to 58. This idea can be pushed further, so that it is impossible for the intermediary device to even detect that it is an ICMPv6 message, actually. This can be achieved with an ICMPv6 message preceded with two or more Extension Headers that are splitted into fragments as illustrated in the following figure.

The challenge that the second fragment presents is the same as in the previous case, but this time, a device processing the first fragment is not even able to detect that ICMPv6 message is being transmitted. This is because the Next Header field of the last Extension Header of the first fragment has the value of 60, which indicates the Destination Options as the following Extension Header.

All of the tested devices are vulnerable from Rogue RA attack with packet fragmentation, as expected. Current specification of RA Guard actually does not take into account issues associated with packet fragmentation and therefore, practically all of the current implementations of RA Guard are vulnerable from this form of an attack.

There is, however, some work in progress [1] that recommends to drop all IPv6 packets that are first fragments (i.e., Fragment Offset is set to 0) and fail to include the entire header chain. Non-first fragments may be safely forwarded, because their destination would not be able to properly assemble all of the fragments, as the first one would be missing. At the time of this writing, such behavior of RA Guard has not been implemented yet and it is questionable, if it ever will be. There is, however, a possibility to achieve such behavior on Cisco devices by making use of an ACL deny ip any any undetermined-transport, but unfortunately, none of the tested devices supports such ACL. The main obstacle preventing this solution from being deployed is that it may drop unusual but valid packets.

Even if such restriction would be acceptable, there is still a chance to bypass RA Guard [3]. An attacker can create two overlapping fragments in a way so that the first fragment would contain some regular message (e.g. ICMPv6 Echo Request), so that it will not be dropped by RA Guard and the second fragment would contain malicious RA message with an offset being set in such a way that when these fragments will be assembled at their destination, RA message overwrites the message included in the first fragment. Following figure illustrates the situation.

Since different operating systems handled assembly of fragments in different ways and overlapping fragments represented critical security issue, RFC 5722 forbade their usage. According to research conducted by SI6 Networks [2], all of the current operating systems are converging towards the implementation of RFC 5722, so overlapping fragments should not pose a threat in most cases.

5. Conclusion

The presented attack was tested on following devices with RA Guard (resp. ND Detection) enabled:

• Cisco Catalyst 3750-X Series Switch with IOS version 15.0(2)SE1
• Cisco Catalyst 2960-S Series Switch with IOS version 15.0(2)SE2
• H3C A5800 with OS version 5.20