Newly connected IPv6 hosts can automatically discover configuration details by sending link-local router solicitation messages. Once received, an IPv6 router can send IPv6 router advertisements (RAs) back to the host, that include network configuration parameters. Since IPv6 router advertisement packets are used to configure, among other things, the host‘s gateway address, unauthorized users employ various methods to spoof IPv6 router advertisements to redirect, or deny service.
The IPv6 Router Advertisement Filtering feature exposes the existing “icmp-type” match criteria to allow IPv6 packets to match RAs and other IPv6 packets that use the ICMPv6 protocol. This functionality provides the ability to flexibly detect certain conditions and take appropriate actions based on network design and expectations.
All Summit, BD8K, and BDX8 platforms are supported. However, there are per-platform limitations on how many IPv6 extension headers can be parsed while still matching the supplied ICMP (Internet Control Message Protocol) type:
Up to 2 extension headers: X670-G2, X770
0 extension headers: Summit platforms
The exact field compatibility with this match criteria depends on the platform, but all platforms are able to match the port and protocol (ICMPv6) in single wide mode. Using double wide mode provides access to a 128-bit source address, or source MAC address, for example. All of the above platforms support double wide mode at the expense of reducing ACL scale by 50%. The XGS3 platforms do not support double wide mode at all.
On platforms that support double wide mode, if the layer-2 device is unable to identify whether the packet is an ICMPv6 Router Advertisement message, and the IPv6 Source Address of the packet is a link-local address or is unspecified, the packet is blocked.
You can also use the new “icmp-type” to match other protocol cases such as MLD and MLDv2.
The existing ACL match criteria icmp-type type is exposed in dynamic ACLs and static ACL policies on the target platforms. This same match criteria is already supported for rules that specify IPv4 criteria on the target platforms.
Here is a policy to detect and log a “simple” RA attack, only allow TCP/UDP/ICMP/xyz protocol traffic that can be parsed (i.e., has up to 2 extension headers and, if fragmented, the L4 NH is contained in the first fragment), and deny everything else including “complex” RA attacks:
Print
this page
Email this topic
Feedback
View PDF
Download EPUBentry disallow_and_log_RA_attacks
{
if
{protocol icmpv6;icmp-type 134;}
then
{ deny; mirror-cpu; log; count RA_attack;}}
entry allow_tcp
{
if {protocol tcp; first-fragments;}
then {permit;}}
entry allow_udp
{
if {protocol udp; first-fragments;}
then {permit;}}
entry allow_icmp
{
if {protocol icmpv6; first-fragments;}
then {permit;}}
entry allow_xyz…entry denyall
{
if{first-fragments; }
then
{
deny;}}
The above policy works for newer chipsets, but leaves (at least) the following exposure for older chipsets: a malicious user could send an RA with a single extension header and it would be allowed to pass due to rule “allow_icmp” (newer chipsets would block this packet through the first rule). To mitigate this exposure on older chipsets, you could call out each “icmp-type” that is supported (ND, MLD, etc.), and then drop any ICMPv6 with an extension header.
For more information, please refer to http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-04.