OverviewThere are a growing number of large-scale IPv6 deployments occurring within enterprise, university, and government networks. For these networks to succeed, it is important that the IPv6 deployments are secure and the quality of service (QoS) must rival the existing IPv4 infrastructure. An important security aspect to consider is the local links (Layer 2). Traditional Layer 2 security differs between IPv4 and IPv6 because of the functionality in Layer 2 operations. This paper identifies the threats to IPv6 first-hop security (FHS). Mitigations are outside the scope of this document.
IPv6 introduces a new set of technology link operations paradigms that differ significantly from IPv4. For example, IPv6 introduces changes to the network topology infrastructure because threats often align with topology. The changes include more end nodes permitted on the link (up to 264) and increased neighbor cache size on end nodes and the default router, which creates more opportunities for denial of service (DoS) attacks.
In addition to the topology changes, there are additional threats to consider in IPv6 including threats with the protocols in use:
- Neighbor Discovery Protocol (NDP) integrates all link operations that determine address assignment, router discovery, and associated tasks.
- Dynamic Host Configuration Protocol (DHCP) can have a lesser role in address assignment compared to IPv4.
Because of the increase in IPv6 technology and the intrinsic differences between IPv4 and IPv6 outlined previously, it is important to have secure environments in both IPv4 and IPv6. This paper will help identify first-hop security (FHS) concerns for the IPv6 infrastructure when connecting systems to a network link. A subsequent white paper will provide mitigations for the threats identified in this paper.
If an intruder, shown as host T, manages to install itself in the link, host T could attempt to insert itself as a default router in the routing table of host A. To do that, host T can spoof a new router advertisement to host A from RTR and set the lifetime to 2 hours. According to RFC 4862, "If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regard to the valid lifetime, unless the Router Advertisement from which this option was obtained has been authenticated." Host A will remove the installed default route that points to RTR after 2 hours. Host T is then free to send another router advertisement inserting itself as the default route for host A. If host T succeeds in becoming the default route, it can see all traffic from host A that is using its default route, and may gain additional information or deploy other types of attacks (for example, a man-in-the-middle attack). Figure 1 illustrates the steps involved in deploying a Router Discovery attack.
Figure 1. Attack against IPv6 Router Discovery
IPv6 address autoconfiguration is stateless; therefore, it does not require a mechanism to track the address allocations before it assigns a new address. The allocation occurs based on the IPv6 prefix information provided by ICMPv6 router advertisements. When host A needs to receive an IPv6 address, it sends an ICMPv6 router solicitation requesting the link information. RTR responds with an ICMPv6 router advertisement that provides the IPv6 address prefix (shown as 2001:DB8:600D::/64) on the link and a lifetime x for it. Then host A can pick an address (shown as 2001:DB8:600D::A) on the link and, after it checks its availability (see Duplicate Address Detection ), it can begin using it.
If malicious host T manages to insert itself in the link, it could spoof an ICMPv6 router advertisement from RTR that sets the lifetime for the link to 2 hours. According to RFC 4862, "If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regards to the valid lifetime, unless the Router Advertisement from which this option was obtained has been authenticated". That would cause the host A address to expire in 2 hours, and host T could then send a new router advertisement with a new prefix (shown as 2001:DB8:BAD::/64). Upon seeing the new prefix, host A will pick a new address (shown as 2001:DB8:BAD::A). Depending on the network configuration, the RTR ACLs may deny the new address from traversing the network; therefore, host A could be blocked from accessing beyond the next hop router, or even its link-local peers. If IPv6 address autoconfiguration is used and FHS protection is not employed, host T could potentially blackhole hosts in its local link by spoofing two IPv6 router advertisements. Figure 2 illustrates the steps involved in deploying the IPv6 address autoconfiguration attack.
Figure 2. Attack against IPv6 Auto-Configuration
In IPv4, Address Resolution Protocol (ARP) is responsible for address resolution; however, in IPv6, ICMPv6 is responsible for that service. In figure 3, Host A sends an ICMPv6 NS requesting the link-layer address for host B. When host B sends an ICMPv6 NA response, host A knows the MAC address that it will use to send the frame. At the same time, host A creates a neighbor cache entry for host B that binds the MAC for host B to its IPv6 address (similar to the ARP table in IPv4).
If malicious host T manages to insert itself in the link, it could impersonate host B and, in turn, intercept all packets that were originally destined for host B. Therefore, if proper FHS protections are not employed, host B can perform a man-in-the-middle attack or intercept traffic. Figure 3 illustrates the steps involved in deploying an address resolution attack.
Figure 3. Attack against IPv6 Address Resolution.
In this scenario, DAD can be susceptible to attacks by malicious host T, which wants to prevent host A from receiving an IPv6 address. When host A sends its NS for 2001:DB8:600D::A, host T can then send an NA stating that the address is taken. If host A tries to claim another address (for example, 2001:DB8:600D::AA), host T can send an NS and claim it. Essentially, host T can claim every address that host A performs DAD and prevent host A from getting an IPv6 address to communicate with the network. Figure 4 illustrates the steps involved in deploying a duplicate address attack.
Figure 4: Attack against IPv6 Duplicate Address Detection (DAD)
In this scenario, malicious host T can attack the neighbor cache of a host or routing device and attempt to fill it or cause a DoS condition. Let us assume that host T knows that RTR is connected to its link and to a link with hosts in the 2001:DB8:600D::/64 prefix. Host T can start scanning 2001:DB8:600D::/64 by sending a packet to the hosts one by one. Regardless of whether the destination host is present on the link, RTR will attempt to resolve their IPv6 addresses to forward the frame that is destined to them. For example, even if host 2001:DB8:600D::A is not on the link, while resolving it, RTR will create a cache entry that will be incomplete and remain in the RTR neighbor cache for a few seconds until it times out. Thus, if host T was fast enough and able to scan a large portion of the 264 hosts within a few seconds, it could succeed at filling the RTR cache entry and cause a DoS condition. Figure 5 illustrates the steps involved in deploying a neighbor cache attack.
Figure 5. Neighbor Cache attack
Note: The attack on the RTR neighbor cache does not require host T to be local to the RTR. If host T knows the links directly connected to RTR, it could launch the attack remotely.
As in IPv4 DHCP, DHCPv6 is susceptible to rogue server attacks. In other words, if DHCPv6 was used to provide IPv6 addresses to the hosts, an attacker that managed to insert a rogue DHCPv6 server in the link could potentially assign addresses and configuration options to the link hosts as he wished. In turn, the attacker could deploy man-in-the-middle, traffic interception, or blackhole traffic, similar to those in the stateless address autoconfiguration scenario. Thus, it is important to use DHCP protections for both IPv4 and IPv6.
Cisco Applied Intelligence Engineer
Implementing First Hop Security in IPv6
IPv6 First Hop Securityâ€”Protecting Your IPv6 Access Network Whitepaper
IETF RFC 4861 Neighbor Discovery for IP version 6 (IPv6)
IETF RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
IETF RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
IETF RFC 6104 Rogue IPv6 Router Advertisement Problem Statement
Book: IPv6 Security by Scott Hogg, Eric Vyncke, Cisco Press (2008)
Reference: Cisco Systems