Introduction
IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique for attack vectors based on ICMPv6 Router Advertisement messages. RFC6104 describes the problem statement of “Rogue IPv6 Router Advertisements”, and RFC6105 specifies the “IPv6 Router Advertisement Guard” functionality.
Surprisingly enough, RFC6104 (the problem statement document) focuses on mis-configured routers, while RFC6105 describes RA-Guard as a security mechanism!
The basic concept behind RA-Guard is that a layer-2 device filters ICMPv6 Router Advertisement messages, according to a number of different criteria. The most basic filtering criteria is that Router Advertisement messages are discarded by the layer-2 device unless they are received on a specified port of the layer-2 device. Clearly, the effectiveness of the RA-Guard mitigation relies on the ability of the layer-2 device of identifying ICMPv6 Router Advertisement messages.
However, trying to filter layer-3 packets at layer-2 can be tricky.
Router Advertisement Guard (RA Guard) Evasion Vulnerability
While there is currently no legitimate for IPv6 Extension Headers in ICMPv6 Router Advertisement messages, implementations allow the use of Extension Headers included in these messages, by simple ignoring the received options. Some implementations of RA-Guard (notably that of Cisco Systems) try to identify ICMPv6 Router Advertisement messages by looking at the “Next Header” field of the fixed IPv6 header, rather than following the entire header chain. As a result, these implementations fail to identify any ICMPv6 Router Advertisement messages that include any Extension Headers (for example, Hop by Hop Options header, Destination Options Header, etc.).
The following figure illustrates the structure of ICMPv6 Router Advertisement messages that implements this RA-Guard evasion technique:
While this attack vector is effective with RA-Guard implementations that fail to process the entire header chain (e.g., Cisco’s), it could be easily mitigated by simply having the RA-Guard implementation process the entire header chain.
However, a more sophisticated attack vector can be employed by leveraging the IPv6 fragmentation (i.e., the IPv6 Fragment Header).
The basic idea is that if the forged ICMPv6 Router Advertisement is fragmented into at least two fragments, the layer-2 device implementing “RA-Guard” would be unable to identify the attack packet, and would those would fail do discard it.
A simple implementation of this attack vector would be an original ICMPv6 Router Advertisement message preceded with a Destination Options Header, that results in two fragments. The following figure illustrates the “original” attack packet, prior to fragmentation, and the two resulting fragments which are actually sent as part of the attack.
It should be noted that the length of the he Destination Options Header (its “Hdr Ext Len” field) is present only in the first fragment (but not in the second). Therefore, it would be impossible for a device processing only the second fragment to locate the ICMPv6 header contained in that fragment, since it is unknown how many bytes should be “skipped” to get to the next header following the Destination Options Header.
Thus, by leveraging the use of the Fragment Header together with the use of the Destination Options header, an attacker could conceal the type and contents of the ICMPv6 message he is sending (an ICMPv6 Router Advertisement in this example).
A layer-2 device could, however, at least detect that that an ICMPv6 message (or some type) is being sent, since the “Next Header” field of the Destination Options header contained in the first fragment is set to “58” (ICMPv6).
It is be possible for an attacker to take this idea further, such that it is impossible for the RA-Guard implementation to even detect that the attacker is sending an ICMPv6 message in the first place. This can be achieved with an original ICMPv6 Router Advertisement message preceded with two Destination Options Headers, that results in two fragments. The following figure illustrates the “original” attack packet, prior to fragmentation, and the two resulting packets which are actually sent as part of the attack.
In this variant, the “Next Header” field of the Destination Options header contained in the first fragment is set to “60” (Destination Options header), and thus it is impossible for a device processing only the first fragment to detect that an ICMPv6 message is being sent in the first place.
The second fragment presents the same challenges as the second fragment of the previous variant. That is, it would be impossible for a device processing only the second fragment to locate the second Destination Options header (and hence the ICMPv6 header), since the length of the first Destination Options header (i.e., its “Hdr Ext Len” field) is present in the first fragment (rather than the second).
Mitigations
Fernando Gont has published (on behalf of CPNI) two IETF Internet-Drafts, that propose mitigations for these RA-Guard evasion vulnerabilities. One of the internet-drafts proposes to modify the protocol specifications such that use of IPv6 Extension Headers with Neighbor Discovery messages is forbidden (when SEND is not employed). The other internet-draft proposes an improved filtering policy that could be readily employed by network administrators and operators to mitigate these RA-Guard evasion techniques.
These two internet-drafts have been presented at the 6man meeting and the v6ops meeting that took place at IETF 81, and are currently being discussed by the 6man and the v6ops working groups of the IETF.
Some Conclusions
In IPv4, options are limited to 40 bytes (resulting in a maximum IPv4 header of 60 bytes). On the other hand, IPv6 can easily employ 64K of options. This is just a simple example of how a protocol feature can be a two-sided knife: the larger option space available in IPv6 makes in much more difficult to enforce layer-2 ACLs.