IPv6 First Hop Security

Introduction and Overview

As IPv4 public addresses get depleted, the number of IPv6 deployments has increased exponentially. This exponential increase in the adoption of IPv6 can also be attributed to introduction of Internet of Things (IoT).

With all these devices gaining access to networks, security concerns are growing in IPv6 deployments. It is important that these IPv6 deployments are secured for optimum operation of these networks. A critical part of the network that needs to be considered when implementing security mechanisms is at the local links (Layer 2) where hosts are connected to the network.

First hop is the network segment between the end hosts and their default gateway i.e., the access layer. Security at the first hop aims to prevent against internal threats at the access layer such as a man-in-the-middle(MiM) attack. In IPv4, security at the access layer is implemented through DHCP snooping, IP source guard and dynamic ARP inspection. Most IPv6 first-hop security features are implemented on a layer 2 device(switch).

In IPv6, ICMPv6 ND/NDP replaces IPv4 ARP. ARP uses two messages: request and reply. With ICMPv6 ND uses four messages:

1. Neighbor Solicitation (NS): a device requests for information about a neighbor.
2. Neighbor Advertisement (NA): a device advertises its information to other neighbors.
3. Router Solicitation (RS): a device requests for information about local routers i.e., routers in the network segment.
4. Router Advertisement (RA): a device advertises itself as an active router.

When a host is added to a network:

1. The host chooses a link-local address; usually FE80::/10 for the network segment of the address. The host segment of the address is generated using EUI-64.
2. The host then checks to confirm that the link-local address is unique by sending an NS on the local link to the solicited node multicast address (FF02:0:0:0:0:1:FF00::/104 + 24 low-order bits from the EUI-64). If no response is received for the NS, then the link-local address is confirmed as unique.
3. The host then sends a NA to the "all hosts multicast address" FF02::1 (similar to 255.255.255.255 in IPv4) announcing itself as a host.
4. Router discovery is then attempted by sending RS messages to FF02::2 (all routers multicast address).
5. A local router replies with RA that contains the router's IPv6 address and MAC address along with prefix information for SLAAC.
6. The host chooses a global prefix for SLAAC where the address is generated using the RA advertised prefix and EUI-64 for the host part of the address. The host performs DAD to verify that the global prefix address is unique. If unique, the host sends a NA for the global prefix.

IPv6 First Hop Attack Surface

IPv6 features such as ICMPv6 Neighbor Discovery’s Neighbor Solicitation (NS), Neighbor Advertisement (NA) messages and Router Discovery Router Solicitation (RS) and Router Advertisement (RA) introduce attack options that were previously not possible in IPv4. IPv6 first hop security concerns on the local links are usually associated with router discovery, neighbor discovery, duplicate address detection(DAD), stateless address autoconfiguration(SLAAC) and DHCPv6.

This process presents several attack surfaces that can be exploited in some of the following ways:

• Spoof the router: a rogue device can send gratuitous RA to announce itself as the router. Spoofing the router is a MiM attack or a basic DoS attack
• Spoof DHCPv6 server: a rogue device can respond with bogus DHCPv6 messages. Spoofing the DHCPv6 server is a form of DoS attack or MiM if it is combined with RA spoofing.
• Poison the router's ND cache: a rogue device can send gratuitous NA messages with other device's addresses. Poisoning the router's ND cache is a MiM or DoS attack.
• Overload the router's ND cache: a rogue device sends packets to the entire /64 prefix range. This results in the DoS attack as router is overwhelmed trying to respond with NS messages.

RA Guard

Router discovery is a means for hosts to locate routers that reside on a local link. Security concerns with router discovery include attacks on ICMPv6 Router Discovery (RD) and host address allocation using SLAAC (Stateless Address Autoconfiguration). RD attacks are categorized as man-in-the-middle attacks.

Attack

One of the several ways that an RD attack may take place follows this sequence:

Host A sends a Router Solicitation (RS) message on its local link to discover local routers connected to its link.

A legitimate router R1 responds with a Router Advertisement (RA) with lifetime X to the RS from Host A. Host A installs R1 as its default gateway for duration X.

An intruder Rx inserts itself in the local link by connecting to one of the switchports on the local link switch or connecting to the wireless network common to R1 and Host A. Rx can then spoof R1’s RA messages and sends R1’s RA messages with a shorter lifetime Y.

When duration X is about to elapse, Host A request a renewal of the prefix lease.

Rx then sends new RA messages with lifetime Z. Host A will receive these RA messages and install Rx as its default gateway.

Host A starts to direct traffic to remote networks through Rx as its gateway. Rx can then monitor traffic from Host A.

The above sequence of events is an example of a man-in-the-middle (MiTM) attack on IPv6 local links.

IPv6 RA Guard

Router advertisements should enter a network through an authorized switchport and from an authorized source. RA Guard protects against router spoofing and prefix spoofing on the segment. This is accomplished by blocking or rejection of rogue or unwanted router advertisements that are received on certain ports.

Deploying RA Guard involves configuration of a policy and attaching the policy to a specific VLAN or switchport. Traffic is permitted on the ports that comply with the policy and blocked/dropped on non-compliant ports.

Configuration

When configuring RA Guard policies, device roles are specified for each of the ports that the policy will be applied. The configurable device roles include:

• host: attached device is a end-user host device. In host mode, all RA redirect messages are disallowed on the port.
• router: attached device is a router. RA and RS messages are to be expected from this port. Additionally, switchports with routers can be configured as trusted ports.
• monitor: for attached devices that have network monitoring features or are network sniffers.
• switch: attached device is a switch.

When configuring RA Guard, two policies are usually configured; one policy for ports where routers are attached and a separate policy for ports where hosts are attached.

1. Configure the RA Guard Policy:

   Defining a policy for hosts:

   1. Define the RA guard policy: ipv6 nd raguard policy <policy-name>
      SW1(config)#ipv6 nd raguard policy HOSTS

   2. Specify the device role: The device role can be host or router: device-role host.
      SW1(config-nd-raguard)#device-role host

   Creating a second policy for routers:

   1. Define the RA guard policy: ipv6 nd raguard policy <policy-name>
      SW1(config)#ipv6 nd raguard policy ROUTERS

   2. Specify the device role: The device role is router: device-role router.
      SW1(config-nd-raguard)#device-role router

   3. Configure the port as trusted: trusted-port
      SW1(config-nd-raguard)#trusted-port

   4. Enable of O flag/bit: other-config-flag on. The O bit indicates to the client additional information is to be extracted from another source such as a DHCP or DNS server.
      SW1(config-nd-raguard)#other-config-flag on

   5. All optional features are bypassed if not configured. They include:
      • hop limit <maximum | minimum> <number>: (Optional) Enable verification of advertised hop count limit.
      • managed-config-flag <on | off>: (Optional) Enable verification that the advertised managed address configuration flag is on.
      • match ipv6 access-list alc
      • match ra prefix-list ipv6_prefix_list: (Optional) Verification of the advertised prefixes in inspected messages from configured prefix-list.
      • other-config-flag <on | off> : (Optional) Verification of advertised other-config parameter
      • router-preference maximum < high | low | medium > : (Optional) Verification that the advertised default router preference parameter value is lower than or equal to a specified limit
      • match ipv6 access-list <acl>: (Optional) Enable verification of the sender’s IPv6 address in inspected messages from the configured authorized device source access-list

2. Apply the RA Guard policy to the switchport or VLAN:
   • VLAN:
     SW1(config)#vlan configuration 1
SW1(config-vlan-config)#ipv6 nd raguard attach-policy HOSTS


   • interface: Apply IPv6 RAGuard feature to a specified interface using the command ipv6 nd raguard attach-policy <policy-name> [vlan <add|except|none|remove|all> vlan <vlan1, vlan2 … vlan n>]
     SW1(config)#interface g0/0
SW1(config-if)#ipv6 nd raguard attach-policy ROUTERS


Verification

The following commands verify RA Guard configuration and operation:

• show ipv6 snooping policies: RA guard will appear as one of the snooping policies configured
• show ipv6 nd raguard policy <policy-name>
• debug ipv6 snooping raguard <filter | interface | vlanID>
• show ipv6 snooping capture-policy interface <interface-id>: for configured interfaces

Restrictions for IPv6 RA guard

• IPv6 RA guard does not offer protection when IPv6 traffic is tunneled.
• RA guard is supported on hardware when the TCAM is programmed.
• RA Guard can be configured on a switchport interface in the ingress direction.
• Supports host and router mode.
• Not supported in etherchannel and etherchannel port members.
• Not supported on trunk ports with merge mode.
• Is supported on auxiliary VLANs and private VLANs (PvLANs). Primary VLAN features are inherited and merged with port features.
• Packets dropped by IPv6 RA guard can be spanned.
• RA guard cannot be configured if the following command is configured platform ipv6 acl icmp optimize neighbor-discovery

SLAAC

SLAAC is a mechanism that enables an IPv6 host to obtain an IPv6 address prefix from its local router through one of its local links without the use of all DHCPv6 features. Unlike DHCPv6, due to the stateless nature of SLAAC, address assignments are not verified before addresses are issued.

Steps involved in a SLAAC attack:

1. Host A sends a Router Solicitation (RS) message on its local link to discover local routers connected to its link.
2. A legitimate router R1 responds with a Router Advertisement (RA) that provides the IPv6 prefix. 2001:DB8:C0FF:EE::/64 with lifetime X.
3. Host A configures the address 2001:DB8:COFF:EE::2/128 and checks the availability of the address using Duplicate Address Detection (DAD) and begins using this address.
4. An intruder Rx inserts itself in the local link by connecting to one of the switchports on the local link switch or connecting to the wireless network common to R1 and Host A. Rx can then spoof R1’s RA messages and sends R1’s RA messages with a shorter lifetime Y.
5. Host A’s IPv6 address will then expire at the lapse of duration Y.
6. Rx can then send a new RA with a new prefix 2001:DB9:COFF:EA::/64.
7. Upon receiving the new prefix, Host A will configure the address 2001:DB9:COFF:EA::09/128 with R1 still being retained as the default gateway. R1 may block Host A’s network traffic due to the fact that it is from an unknown network.
8. R1 may drop Host A’s traffic resulting in black-holing all network traffic from Host A.

DHCPv6 Guard

DHCPv6 assigns hosts IPv6 prefixes and other configuration options. DHCPv6 is both a stateful and stateless protocol. A rogue DHCPv6 server could be inserted into a network. The attackers can then deploy man-in-the-middle attacks ,traffic interception or blackhole traffic.

DHCPV6 Attacks

DHCPv6 does not assign a default router like DHCP in IPv4 environments. Th default router is learned through SLAAC from RA messages.

DHCPv6 Guard prevents the spoofing of the DHCPv6 server by blocking DHCPv6 messages that come from unauthorized / rogue DHCPv6 servers and relay agents. Client messages or messages sent by replay agents from clients are not blocked. When implementing DHCPv6 Guard, devices are categorized as server and client. DHCPv6 server messages are only processed if the device role is set to server.

Configuration

The configuration of the DHCPv6 Guard is similar to that of the RA Guard. A DHCPv6 Guard policy is configured for the DHCPv6 clients and a separate policy for the servers. The policy is then applied to a VLAN or interface.

1. Configure the DHCPv6 policy:

   Policy for servers:

   1. SW1(config)#ipv6 dhcp guard policy SERVERS
SW1(config)#device-role server
SW1(config)#trusted-port

      Additional configuration options exist for attached DHCPv6 servers:

      • Authorized DHCPv6 servers: DHCPv6 messages can be permitted to be transmitted if they originate from authorized DHCPv6 servers. To enable this feature:
        1. Configure an IPv6 access control list with the IPv6 addresses of the authorized DHCPv6 servers: ipv6 access-list <acl-name> permit host <ipv6-address> 128.
        2. Enable verification of the advertised DHCP server and relay address in inspected messages from the configured authorized server ACL. An empty ACL is treated as a permit. match server access-list <acl-name>.
      • IPv6 Addresses in Authorized Range: DHCPv6 Guard can be configured to permit DHCPv6 advertised prefixes are in the permitted IPv6 range:
        1. Create an entry in an IPv6 prefix-list; ipv6 prefix-list <prefix_list_name> permit <ipv6_prefix> 128.
        2. Enable verification of advertised prefixes in DHCP reply messages from the configured authorized prefix-list. An empty ACL is treated as a permit.

   Policy for clients:

   1. SW1(config)#ipv6 dhcp guard policy CLIENTS
SW1(config)#device-role client

   Other optional DHCPv6 features include:

   • preference min limit : Enable verification that the advertised preference (in preference option) is greater than the specified limit
   • preference max limit : Enable verification that the advertised preference is less than the specified limit

2. Apply the DHCPv6 Guard policy:
   1. Interface:
      SW1(config)#interface g0/0
SW1(config-if)#ipv6 dhcp guard attach-policy SERVERS


   2. VLAN:
      SW1(config)#vlan configuration 1
SW1(config-vlan-config)#ipv6 dhcp guard attach-policy CLIENTS

Verification

The operational state of DHCPv6 Guard can be verified using these commands:

• show ipv6 dhcp guard policy <policy-name>.
• show ipv6 snooping policies.

Restrictions

DHCPv6Guard is not supported on etherchannel ports.

Binding Table

The binding table is a database of IPv6 neighbors connected to a device and is created from informational sources such as ND snooping, DHCP gleaning. It contains information such as the link-layer address, the IPv4 or IPv6 address, and the prefix binding i.e., it can be considered to be a mapping of layer 2 addresses to IPv6 addresses. It is used by various IPv6 guard features to prevent spoofing and redirect attacks.

The binding table supports features that can be leveraged to provide first hop security:

• Limits can be set for the number of IPv6 addresses that a MAC address can have.
• The binding table recovery mechanism feature enables the binding table to recover in the event of a device reboot. The recovery mechanism will block any data traffic sourced from an unknown source (a source that is not in the binding table).
• The binding table introduces the capacity to provide a prefix-list that is matched before the recovery is attempted for both DHCP and NDP. If an address does not match the prefix-list associated with the protocol, the recovery of the binding table entry will not be attempted with that protocol.

IPv6 Snooping

IPv6 snooping bundles several IPv6 first-hop security features such as ND inspection, IPv6 device tracking, IPv6 address glean, IPv6 binding table recovery. IPv6 ND inspection operates at Layer 2 or between Layer 2 and Layer 3. IPv6 snooping mitigates vulnerabilities in the ICMPv6 ND mechanisms for example attacks on DAD, address resolution, device discovery and neighbor cache/table. IPv6 snooping learns and secures binding for SLAAC addresses in Layer 2 neighbor tables and analyses ND messages in order to build a trust binding table. An ND message is considered trustworthy if its IPv6-to-MAC mapping is verifiable. The IPv6 first-hop security binding table recovery mechanism enables the binding table to recover in the event of a device reboot.

The binding table is a database of IPv6 neighbors connected to the device and is created from sources such as ND snooping. It is used by various IPv6 guard features to validate link-layer addresses, IPv4 or IPv6 addresses prefix-binding of neighbors to prevent spoofing and redirect attacks.

Configuration

To configure an IPv6 snooping policy;

1. Configure the snooping policy:
   SW(config)#ipv6 snooping policy SNOOP_POLICY


2. Attach the snooping policy to an interface:
   SW(config)#interface g0/0
SW(config-if)#ipv6 snooping attach-policy SNOOP_POLICY


Verification

• show ipv6 snooping capture-policy interface <interface_number>: To display snooping ND messages and capture policies
• show ipv6 snooping counter interface <interface_name_number> : To display information about the packets counted by the interface counter
• show ipv6 snooping features : To display information about snooping features configured on a device
• show ipv6 snooping policies : To display information about configured policies and interfaces that they are attached to
• debug ipv6 snooping : Debugging of IPv6 snooping information

Restriction

IPv6 snooping is not supported on etherchannels.

Source Guard

If a device starts transmitting on a network segment without IPv6 host discovery messages such as NS, NA, DHCPv6 message exchange, source guard enables the switch to drop such traffic from an unfamiliar IPv6 source address.

IPv6 source guard relies on IPv6 snooping cache to create the IPv6 neighbor binding table. It creates an automatic IPv6 port ACL(PACL) to filter sources based on neighbor binding table.

Configuration

1. Configure the source guard policy:
   SW(config)#ipv6 source-guard policy SG_POLICY
SW(config-sisf-sourceguard)#permit link-local
SW(config-sisf-sourceguard)#deny global-autoconf
SW(config-sisf-sourceguard)#trusted

2. Apply the configured source guard policy to the VLAN or interface:
   • On the VLAN:
     SW(config)#vlan configuration 1
SW(config-vlan-config)#ipv6 source-guard attach-policy SG_POLICY

   • On the interface:
     SW(config)#interface g0/0
SW(config-if)#ipv6 source-guard attach-policy SG_POLICY

Verification of Source Guard

The following command is used to verify IPv6 source guard: show ipv6 snooping policies.

Neighbor Discovery Attacks

Similar to RA messages ND messages are used to discover other hosts on the local link. It replaces ARP in IPv6. ND performs DAD and address resolution, neighbor unreachability and redirection. Neighbor discovery messages are mainly Neighbor Solicitation (NS) and Neighbor Advertisement (NA). ND Attacks usually involve Address Resolution, Duplicate Address Detection and Neighbor Cache attacks.

Address Resolution Attacks

Address resolution is the process that a host (Host A) follows when it wants to send network traffic to another host (Host B) on the local link when it does not know its Layer 2 address (MAC address in Ethernet networks). Host A resolves the IPv6 address of Host B into a MAC address and forwards the packet with Host B’s MAC address as the destination address of the Layer 2 frame.

Stages in IPv6 address resolution attacks include the following;

1. Host A sends a Neighbor Solicitation message on the local link requesting for Host B’s link local address. Host B sends a Neighbor Advertisement (NA) message on the local link containing its MAC address which Host A stores in its neighbor table binding the MAC address with the IPv6 address.
2. If a malicious Host X inserts itself into the local network, it can masquerade as Host B and intercept all packets sent to Host B. Without effective IPv6 first-hop security, Host X can perform a Man-in-the-Middle (MiTM) attack.
3. Host A will attempt to send packets destined to Host B but using Host X’s link-layer address.

Duplicate Address Detection Attacks

Duplicate Address Detection (DAD) is an IPv6 protocol that enables a host to detect a duplicate address on the local network. DAD attacks are usually aimed at preventing hosts from having IPv6 addresses. Steps involved in deploying a DAD attack;

1. Host A wants to use the address 2001:DB8:C0FF:EE::1. So it sends an NS message on its local link to determine if any other host is using this address. If no NA response is received from other hosts on the local link, Host A will go ahead to use this address.
2. However, malicious host Host X which has inserted itself on the local link receives this NS message. It responds with an NA claiming that it is currently using that same address 2001:DB8:C0FF:EE::1 yet it does not actually use this address.
3. Host A sends another NS message requesting to use another IPv6 address 2001:DB8:C0FF:EE::A. Host X again claims that this address is already taken. Host X essentially claims all addresses that Host A requests to use thereby preventing Host A from having a valid IPv6 address.

Neighbor Cache Attacks

When performing address resolution after receiving IPv6 an NA response to an NS request, a host stores the MAC address to IPv6 address binding in its neighbor table/cache. If many hosts reside on the local link, the neighbor table can grow large in size. In IPv6, the interface identifier is 64-bits long. There could be as many as 264 potential number of hosts on the link resulting in potentially 264 neighbor table entries. With IoT devices prevalent these possibilities become close to reality.

A malicious host (Host X) can attempt to fill up the neighbor cache / table of another host or router resulting in a DoS condition.

Step 1: Malicious Host X sends packets to all potential addresses in its local link. The local router R1 will attempt to resolve the IPv6 addresses in order to forward the frames to them. For hosts whose addresses are not yet resolved, R1 will create an incomplete cache entry for a few seconds as it awaits a response that is never received. This entry eventually times out.

However, if Host X sends many such packets fast, it could fill up the R1 neighbor table resulting in a DoS condition.