Security Threats and Best Practices to Protect Against Them

The relatively small-sized IPv6 deployments of past years did not render them uninteresting to hackers. Attacks surfaced shortly after IPv6 was deployed, based on concepts previously used with IPv4 or taking advantage of IPv6-specific vulnerabilities. It is therefore reasonable to relate the IPv6 security threats to IPv4 and group them into two categories: threats with new considerations in IPv6, and threats with similar behavior in IPv4 and IPv6. This classification is reflected in the recommended security best practices for mitigating these threats. Some recommendations are extrapolations of their IPv4 counterparts, whereas others are completely new and specific to IPv6.

Threats with New Considerations in IPv6

IPv6-specific features can make some common attacks more difficult while opening new vulnerabilities. This section analyzes those threats that have to adapt to these features as well as new threats that can impact exclusively IPv6.

Reconnaissance

Reconnaissance is not necessarily an attack, because it will most likely not impact negatively the network or the users. However, it typically is the precursor of an attack and it is intended to provide the attacker with information about the victim.

Characteristics

The common IPv4 practice of ping sweeps is not an option anymore with IPv6. It would take years to scan 2⁶⁴ hosts on a typical network of length /64 even if it is done at high rates, rates that would most likely trigger security alarms. For this reason, Network Mapper (Nmap), a tool commonly used in IPv4 to identify active hosts, does not even support IPv6 ping sweeps. With IPv6, other mechanisms must be used for reconnaissance purposes:

• DNS crawling DNS crawling remains an option with IPv6. With the elimination of Network Address Translation (NAT) and the difficulty of remembering 128-bit addresses, the use of Dynamic DNS might increase in an IPv6 environment. If the DNS resources are not properly secured, they can provide information about many hosts.

• Reducing the scope of the search for hosts The attacker can make a smart choice that could help narrow down the address space that needs to be scanned. One can try hosts with easy-to-remember interface IDs, such as ::1, ::FFFF, and ::F00D. Because the layer 2 burned-in address (BIA) is often used to generate the EUI-64 interface ID of hosts, one can focus the scan on addresses of certain NIC vendors based on their organizational unit identifier (OUI).

• A compromised network element A compromised network element can also provide information on local hosts via the neighbor cache.

• Use multicast addresses standardized for certain protocols This mechanism enables the attacker to identify key systems such as routers and DHCP servers. Addresses with larger scope are preferred because they do not require the attacker to be on a victim's local link. Site scope addresses such as All Router (FF05::2) or All DHCP Servers (FF05::1:3) can be targeted.

The larger network addresses can potentially pose challenges to the propagation of Internet worms from one prefix to another because it is more difficult to identify active hosts on a prefix other than that of the infected host. Locally, an infected host can send a ping to the all-nodes multicast address to find active hosts within its own prefix.

Best Practices

The recommended best practices deal with each aspect of reconnaissance discussed in the preceding section:

• Minimize attacker's chance to discover active hosts.

  Do not assign easy-to-guess addresses to key systems and network elements.

  Implement the privacy extensions (see the "IPv6 Unicast Address" section in Chapter 2, "An IPv6 Refresher") for the addresses used to communicate outside the internal network. Doing so limits the amount of time a given host address can be targeted. The disadvantage of using the privacy extensions is that the host is difficult to track for internal management purposes. For this reason, network managers may want to disable the use of privacy extensions.

  Note

  The use of privacy extensions is not suitable for all deployments. In particular, service providers need to be able to track customers for various reasons, including regulatory requirements. In both enterprise and service provider environments, privacy extensions makes user tracking more difficult.

  
  

• Stop Internet Control Message Protocol (ICMP)-based scanning.

  Filter unnecessary ICMP traffic at the network edge while being mindful of its importance in the control plane of IPv6.

  Block ICMP echo packets sourced from outside the internal network. Permit the neighbor-and router-discovery traffic as well as "Packet Too Large" messages used for the Path Maximum Transmission Unit (PMTU) Discovery process.

• Implement edge security measures.

  Use firewalls to filter unnecessary services. Control multicast traffic at the edge, and stop site-scoped external traffic while containing internal traffic. Enforce scoping at the network border.

• Enforce host and application security.

  Enable security tools such security agents and virus scans.

Unauthorized Access

To be able to exploit the vulnerabilities of hosts and servers, attackers must first reach them through IP. A host's ability to communicate implies IP accessibility. The most a network administrator can do to protect the hosts is to control some of the means that an attacker can use to covertly reach them. Network elements and devices can be used to filter traffic types identified as possibly supporting attacks.

Characteristics

Traffic filtering remains the primary means at a network's disposal to protect hosts from unauthorized access. Such filtering is commonly performed at layers 3 and 4 by routers and firewalls. It applies to IPv6 deployments as it did to IPv4 ones, but with a few specific considerations:

• Increased use of end-to-end encryption in IPv6 Can reduce the effectiveness of some filtering mechanisms by hiding the higher-level protocol information.

• EHs Can be used to get unauthorized access to hosts. With the integration of Mobile IP (MIP) in IPv6, the hosts became particularly exposed to attacks through Type 0 routing headers. That threat was addressed through the introduction of a MIP-specific, Type 2 routing header (see Chapter 8, "Advanced ServicesIPv6 Mobility"). However, the routing header is still in usefor example, in the link-local operation of IPv6 multicast (see Chapter 6, "Providing IPv6 Multicast Services").

• ICMP Can be used not only for reconnaissance but also to gain access to hosts. ICMPv6, however, plays a more significant role in the proper operation of the network, so its filtering cannot be as aggressive as it was in IPv4.

• Multicast traffic Should be filtered and inspected in the same manner as it is in IPv4. However, IPv6 relies on several specific multicast groups for its proper operation (see Chapter 2).

• Anycast traffic Should in principle be destined exclusively to routers per RFC 2373. With an increased interest in expanding the use of anycast, its monitoring might become even more important when you consider the problems identified with its use of IPsec, as discussed in RFC 3547.

Best Practices

The following best practices are recommended to deal with the aspects of filtering IPv6 previously mentioned:

• Using multiple addresses with various scopes and leveraging the privacy extensions can help minimize the exposure of enterprise hosts to attackers.

• When IPsec is used end to end by internal hosts, the firewalls and router filters can manage packets only based on layer 3 information. IPv4 faces this problem, too.

  Note

  If only the Authentication Header (AH) is used, the layer 4 information is still accessible for monitoring and filtering.

  
  

• The EHs necessary for the proper operation of the services deployed in the network should be identified and allowed through the filters. Specific security policies should be defined for the allowed EHs based on the service and function they support.

  Note

  The Cisco IOS implementation of extended access lists was enhanced, beginning with Cisco IOS 12.4(2)T, to filter based on the routing type, thereby allowing routers to differentiate between EHs used for MIPv6 and for source routing. Only Type 2 routing headers should be allowed to support a MIPv6 service.

  
  

• The IPv4 ICMP policies should be matched by the IPv6 ICMP policies. The following types should be permitted:

  - ICMPv6 No route to destination (Type 1, Code 0)

  - ICMPv6 Time exceeded (Type 3)

  - ICMPv6 Echo request and echo reply (Type 128 and Type 129, respectively)

• They should also be complemented with few additional important types:

  - ICMPv6 Packet too big (Type 2) for PMTU Discovery

  - ICMPv6 Parameter problem (Type 4)

  - ICMPv6 Multicast listener (Type 130132, 143)

  - ICMPv6 Router solicitation and router advertisement (Type 133 and 134, respectively) for link operation

  - ICMPv6 Neighbor solicitation and neighbor advertisement (Type 135 and 136, respectively) for link operation

• Multicast traffic can be filtered based on scope. Also, any traffic with a source address (SA) that is a multicast address should be blocked. Network administrators should be aware that the capabilities of firewalls to filter multicast or anycast traffic are likely limited at this time.

Header Manipulation

The IP header structure was changed in IPv6, and these changes provide new venues to attack hosts and networks. The EHs in particular can be used in environments that do not pay attention to their usage.

Characteristics

The routing headerbased security threats that were mentioned earlier in this chapter are not the only ones to exploit the EHs in attacks. The other EHs can also be used by an attacker in at least three different ways:

• Manipulate EHs with contents that have to be processed by network elements or hosts.

• Chain a large number of EHs to force the security devices and mechanisms to do long lookups into a packet, possibly beyond their capabilities, to get to the information that reveals an attack. This approach could provide the means to hide an attack.

• Use large-size EHs or a large number of EHs to drain the resources of the devices that have to deal with the EHs.

Poor IPv6 stack implementations could be particularly targeted with the help of EHs.

Note

It is important that hosts enforce the standardized rules for handling EHs. Firewalls should be able to filter based on EHs. The IDSs should be able to alert when detecting noncompliant EHs.

Best Practices

Network administrators might have a limited ability to control the IPv6 stacks deployed on the hosts, so the best defense against this type of attack is to filter out traffic with any EHs that are not supporting deployed services. The routing header is of particular interest because of its use for various protocol implementations.

Note

It is also important to understand the default handling of EHs by the network elementsthat is, their capability to process multiple or large EHs.

Fragmentation

IP packet fragmentation can serve two purposes to threaten a network. First, it can be used to hide an attack from firewalls or IDSs. These devices would have to reconstruct the packets to discover attack patterns. Overlapping fragments and out-of-order fragments can further complicate the job of detecting possible attacks. Second, IP packet fragmentation can be used to overwhelm network elements that are supposed to do fragmentation or handle these fragments in any special way.

Characteristics

IPv6's perspective on how and where fragmentation should be performed in a network has a significant impact on the threat level of fragmentation attacks. The fact that only end hosts are allowed to perform fragmentation (see RFC 2460 for details) protects network elements from certain types of attacks. The other aspects of fragmentation in IPv6 security are as follows:

• No fragment overlapping should be allowed in IPv6. An attacker could send a stream of fragments and then follow up with fragments that carry the attack information. The receiver's reassembly algorithm overwrites the original fragment that contained harmless information and therefore passed through security checks with the new fragment containing the attack. This type of attack can be stopped by enforcing the "no-overlap" rule at the network or end-user stack level.

• The impact of tiny-fragments types of attacks can be reduced. An attacker could choose to send small-enough packets that would push the information that reveals an attack into the second fragment of the stream. The security measures generally act on the information in the first fragment, so the attack can be masked. Because RFC 2460 recommends the minimum packet size of 1280-bytes, network policies can be implemented where all packets (except for the last fragment) of smaller size are dropped. One drawback of such policies is their impact on applications that rely on smaller packets, such as Voice over IP (VoIP). At the same time, the PMTU Discovery algorithm implemented by some IPv6 protocol stacks could be adversely impacted by the policy mentioned above. For example, the algorithm can start the search at 1500-byte frames that might be too large for the PMTU. Then drop to 750 (binary search), which would be dropped because of the policy. All the subsequent packet sizes in the binary search steps would be dropped, leading to a falsely unsuccessful search.

  Note

  Hosts can still send smaller packets and can be proven inconvenient if they have to be analyzed by the firewalls.

  
  

• Out-of-order fragments can still be used in attacking poorly implemented IPv6 stacks. This is a threat for hosts, but could be a threat for network elements if the traffic is destined to them.

Best Practices

The following are recommended best practices for dealing with the fragmentation security threats:

• Dropping the fragments smaller than 1280 bytes could help mitigate the "tiny-fragments" threats, but such a policy could impact services that benefit from using small-size packets (VoIP).

• The "no overlapping fragments" rule should be enforced by all devices.

• Deny fragments destined to network elements such as routers.

• Devices that monitor the traffic based on layer 3 and 4 information for security risks should be able to handle the case where EHs push upper-layer information into the second fragment. In these cases, some level of reassembly might be necessary.

Layer 3/Layer 4 Spoofing

An important aspect of an attack and even a common attack strategy is the spoofing of the layer 3 and layer 4 information about the originator. It makes the source untraceable, and it can force the device whose address was spoofed to have to deal with the response to the attack.

Characteristics

Most aspects of IPv6 spoofing threats are similar to IPv4. Tunneling mechanisms provide a new venue of attack where the spoofing weakness of both protocols can be used. A few protocol specifics must be considered in the case of this class of threats:

• Layer 3 spoofing relies on replacing the real source address of the attacker with a random one (in use or reserved) or with that of a victim. In IPv4, the typical mitigation technique is filtering based on RFC 2827 and to identify traffic with SAs incongruent with its source. The implementation of RFC 2827 verifies only that the SA is on the expected subnet, so an attacker could still spoof the address of other users on the same subnet. The same mitigation technique can be used for IPv6, but its addressing leads to some specific characteristics:

  - The assignment policies and the aggregation properties of the IPv6 addressing scheme allows for easier implementation of RFC 2827 filtering. Organizations can therefore contain rogue traffic with simple access control lists (ACLs).

  - The larger address space implies a larger number of interface IDs, which can still be spoofed despite RFC 2827 implementation.

  - IPv6 also offers the option to spoof layer 3 addresses in EHs. In particular, routing headers can be used as carriers of spoofed information.

  Note

  Currently, no mechanisms can trace the source of spoofed traffic down to the interface ID of the SA. Any implementation would involve a correlation between layer 3 and layer 2 information on hosts. User-tracking tools, such as Campus Manager 4.0 discussed in Chapter 10, "Managing IPv6 Networks," can be used to help identify misbehaving hosts. As mentioned earlier, privacy extensions can make the tracking process more difficult.

  
  

• Layer 4 spoofing relies on getting the victim to react to a fake application. There is no difference between IPv6 and IPv4 in terms of supporting and combating this type of threat.

• Tunneling mechanisms can provide ways to further hide the source of attacks through spoofing, as discussed later with regard to 6to4 tunnels.

Figure 9-2 shows a spoofing attack leveraging a 6to4 tunnel. The spoofed address in this case is the anycast address of the 6to4 relay router. The attacker can similarly spoof the address of other IPv6 nodes.

Figure 9-2. Spoofing Attack Using a 6to4 Tunnel

The 6to4 relay forwards the inner part of the packet, removing the IPv4 header (which makes it difficult to trace the source of the packet). There is no packet amplification benefit intrinsic to this type of attack. The attacker can spoof a global unicast address, but it can also spoof the anycast address of a 6to4 relay router. Several measures can limit this type of threat:

• Verify that the outer IPv4 address matches the IPv4 address embedded in the 6to4 IPv6 address.

• Block tunneled packets that embed the IPv4 anycast address used for the 6to4 relays (192.88.99.1).

These measures can be implemented on all devices supporting 6to4 tunneling. The impact of such attacks is not dramatic because no amplification mechanisms can be leveraged with them. You can find a complete analysis of the security threats related to 6to4 tunnel deployments in RFC 3964.

Best Practices

The most powerful tool currently available for combating spoofing is the implementation of filtering, based on the recommendations of RFC 2827. Effective filtering allows networks to contain spoofing traffic generated within and to narrow down to the subnet level the location of the attacker.

Note

In the case of IPv6, only the traffic sourced from addresses in the blocks currently allocated by IANA should be permitted: 2001::/16, 2002::/16, 2003::/16, 2400::, 2600::, 2A00::, and 3FFE::/16.

The Unicast Reverse Path Forwarding (uRPF) feature performs a similar function, and it is currently available for IPv6. This feature is discussed in further detail later in the chapter in the section "Unicast Reverse Path Forwarding."

The tunnels can be secured using IPv4 IPsec to reduce the threat of spoofing. This can easily be done in a controlled environment, but can also be implemented in open environments with the help of Internet Key Exchange (IKE).

The use of end-to-end IPv6 IPsec should help reduce the number and forms of spoofing attacks.

Host-Initialization and Address-Resolution Attacks

The attacks in this category target the host-initialization process of acquiring an address and other operational information such as default gateway and DNS servers. They also target the process of resolving the layer 3-to-layer 2 address binding. The attack can disrupt these processes or try to redirect a host's traffic to a compromised device. In IPv4, these threats target protocols such as Address Resolution Protocol (ARP) and Dynamic Host Configuration Protocol (DHCP). Several features are used in IPv4 to protect against these types of attacks (DHCP snooping attacks, for instance).

Characteristics

The host bootstrap process and the layer 2 address-resolution process were modified in IPv6, leading to IPv6-specific host-initialization and address-resolution attacks:

• DHCPv6 remains a host-initialization option. It is also often considered in conjunction with stateless autoconfiguration. DHCP-PD (Prefix Delegation) is also used to provide prefixes to routers. In all these instances, the protocol faces attacks similar to the DHCP potential attacks in IPv4.

• Stateless autoconfiguration is a host-initialization feature specific to IPv6 and implemented in ICMPv6 as discussed in Chapter 2 of this book. The router solicitation or router advertisement (RA) messages can be spoofed to provide the host with the wrong initialization information or with the address of a compromised device acting as a gateway. An attacker can also interfere with a host's initialization process by replying to its Duplicate Address Detection (DAD)-driven neighbor solicitation.

• The renumbering capabilities of IPv6 are based on the RA packets. An attacker can modify the RAs to trigger a renumbering of all the hosts on a network segment. The consistent use of the AH would close this security hole.

• Neighbor Discovery (ND) performs the IPv4 ARP functionality. In its original definition detailed in RFC 2461, no security mechanisms are built in to the protocol, so it is as vulnerable to attacks as ARP. Using IPsec between the nodes would involve prohibitively large management overhead because it implies static associations.

Note

The threats to ND are discussed in detail in RFC 3756. Work done in the Securing Neighbor Discovery (SEND) working group of IETF led to the recently published RFC 3971, which provides non-IPsec security mechanisms for addressing the ND threats:

• A mechanism for certifying routers with a trust anchor that a host consults before accepting a router to be its default gateway.

• Cryptographically generated addresses generated with the help of a private and a public key and used to verify the ownership of an address used in ND messages.

• Introduction of a signature based on the RSA-based cryptographic scheme that is used to protect all ND messages.

• A timestamp and a nonce (random number used only once) option were introduced to prevent replay attacks.

SEND enabled hosts can operate together with non-SEND hosts.

These threats are particularly relevant in environments where the physical layer is not secured (such as wireless environments).

Best Practices

These types of attacks imply a breach in the physical access of the network, which clearly provides the attacker with many opportunities, regardless of protocol. Addressing this security breach should be the first step in mitigating such problems. With layer 1 and layer 2 secured based on specific mechanisms (Public Secure Packet Forwarding, for example), the attention can shift to layer 3 security solutions. In the case of IPv6, static neighbor configuration for critical systems could be a way to mitigate address-resolution attacks. Manual address configuration can be a temporary solution to threats based on the stateless autoconfiguration process.

Broadcast-Amplification Attacks (Smurf)

Broadcast-amplification attacks are a type of denial-of-service (DoS) attack in which an ICMP echo is sent to the broadcast address of a prefix and with the spoofed address of the victim. All hosts on the destination prefix in turn send an echo reply to the victim, overwhelming it.

Characteristics

In IPv6, there is no concept of broadcast. To get any amplification with such an attack, the destination address (DA) can at best be multicast. RFC 2463 clearly states that an ICMP reply should not be generated for packets that have a multicast DA, a layer 2 multicast address, or a layer 2 broadcast address. If all stacks implement the RFC properly, it provides a good level of protection against this type of attack.

Best Practices

No major best practices can be recommended in this case other than traffic filtering for unnecessary multicast traffic to decline the attacker any amplification venues. To complement the constraints provided by RFC 2463, it could prove useful to also block traffic that has layer 3 multicast SAs.

Routing Attacks

A network's routing functions can be impaired in multiple ways. Routing process resources can be drained through flooding attacks or by simulating transitional states such as route or neighbor flapping. Attackers can also attempt to insert their devices in the routing topology or compromised routers and corrupt the routing information.

Characteristics

Routing protocols did not change significantly in IPv6, so there are minor differences in the structure of routing attacks for the two versions of IP. The relevant change is the fact that although Border Gateway Protocol (BGP; see RFC 2545), Intermediate System-to-Intermediate System (IS-IS) and Enhanced Interior Gateway Routing Protocol (EIGRP) still use Message Digest 5 (MD5) authentication for the routing updates; Open Shortest Path First version 3 (OSPFv3; see RFC 2740) and Routing Information Protocol next generation (RIPng; see RFC 2081) use IPsec (Authentication Header and Encapsulating Security Payload) for their communications with neighbors. The IPsec-based protection provides an increased level of security compared with the previous mechanisms.

Note

IPsec protection can be integrated in EIGRP, but as of this writing it has not been implemented yet. IS-IS benefits from the fact that it exchanges routing information using layer 2 packets, which are more difficult to spoof.

Time-To-Live (TTL) checks can also be used to ensure that routing updates are not coming from farther away than what would be expected based on the size of the network managed. Such updates could be spoofed messages used for an attack.

Best Practices

Several basic best practices are recommended to protect the routing processes:

• Routers should be secured from unauthorized access.

• Secure the communication between the routers through IPsec wherever the feature is supported or through traditional authentication mechanisms.

• Implement any flooding control mechanisms that could protect the router resources, and the routing protocol control messages should be a high priority.

Viruses and Worms

The most damaging security threats remain viruses and worms that operate at the application layer. They impair primarily hosts, but some side effects can impact the IP infrastructure, too.

Characteristics

Considering the OSI layer affected by this type of threats, there should be little difference between their operation in an IPv4 or an IPv6 world. The most significant difference to note is the fact that the larger addressing space makes it impossible for viruses to spread in an IPv6 environment by scanning active hosts on prefixes other than that of the infected device. As mentioned earlier, such a process would take too much time to be of practical value. On the other hand, after a host is compromised, a virus could potentially use all nodes' multicast traffic to impact other hosts on the same link.

Best Practices

The typical security measures implemented in IPv4 against this type of threat can be used in IPv6, too. You can complement perimeter security via firewalls and IDS systems with up-to-date antivirus software on the hosts.

Transition-Mechanism Attacks

The mechanisms developed for a seamless and gradual migration from IPv4 to IPv6 offer new attack venues through which attackers can leverage weaknesses in the security policies and capabilities of both IPv4 and IPv6.

Characteristics

The tunneling and translation concepts used in IPv6 migration mechanisms have been used in IPv4, too, and that means they share the same types of vulnerabilities. Therefore, the threats enabled by IPv6 migration technologies neither new nor unique:

• Dual-stack environments are threatened over both IP protocols.

• IPv6 tunneling mechanisms require new ports to be open in the edge firewalls.

• Similar to IPv4, automatic tunnels are more susceptible to attacks than manual tunnels. Well-known tunneling resources such as 6to4 relays can be particularly targeted. In the case of IPv6, you can mitigate this problem if you secure the tunnels with the help of IPv4 IPsec wherever possible.

• The IPv6-to-IPv4 translation mechanisms have similar vulnerabilities as NAT in IPv4. They are also responsible for hiding sources of attacks behind the translated addresses.

Best Practices

The security best practices for mixed IPv4 and IPv6 environments have to take into consideration the various ways in which IPv6 can be deployed in existent networks:

• On dual-stack devices, similar security tools and features should be implemented for both protocols, both within the network and at the network perimeter.

• Leverage IPv4 IPsec to secure IPv6 tunnels whenever possible. If IPv4 IPsec cannot be used to secure the IPv6 tunnels, static tunnels should be preferred over the dynamic ones wherever possible. Firewalls should open access only for the ports of deployed and operated tunnels.

• Devices performing protocol translation should be viewed as potential gateways for attacks. At a minimum, the security measures discussed for the various threats should be implemented for each protocol on the two sides of the translation.

A Note on Mobile IPv6 Security

Mobility is a feature intrinsic to IPv6, so it implies IPv6-specific security concerns. Sniffing, man-in-the-middle, DoS, and masquerading attacks are all threats to Mobile IPv6. A great deal of work went into securing the feature to ready it for deployment. IPv6's easy leverage of IPsec is helpful; however, it is not always applicable to many environments that intend to use MIPv6. Many of the devices used in mobile networks, such as mobile phones or PDAs, do not have the computational power to fully implement IPsec. So along with this obvious mechanism for securing communications in IPv6, new lighter security mechanisms had to be created.

Chapter 8, "Advanced ServicesIPv6 Mobility," focuses on mobility, and includes a section on security.

Threats with Similar Behavior in IPv4 and IPv6

Several familiar threats behave similarly whether they are executed over an IPv4 or an IPv6 infrastructure. For IPv6 deployments, you must be mindful of these types of attacks and implement protective measures based on experience gained securing IPv4 networks.

Sniffing

The process of capturing traffic in transit from one host to the other is called sniffing. It can be done with various tools, such as TCPdump or Ethereal, and the captured information can be investigated for information that can open other access venues for the attacker.

Assuming that the attacker cannot get the keys used for IPsec, the encrypted packets will be of no use to him. IPv6 with IPsec can, under these conditions, eliminate the threat of sniffing. For the time being, however, IPv6 is not more secure than IPv4 with respect to this type of attack.

Application Layer Attacks

Most attacks occur at the application layer, so the transport layer features are irrelevant. IPsec, if used consistently and universally by the hosts, can prove beneficial to trace the source of an attack. On the other hand, the general use of IPsec reduces the benefits that IDSs provide because they cannot search for attack patterns inside the encrypted packets. Ultimately, hosts must protect themselves at the application layer.

Rogue Devices

Rogue devices are unauthorized devices inserted in a network as an instrument for an attack. They can be or act as switches, routers, access points, or resources such as DNS, DHCP, or AAA servers. IPsec can help prevent interaction with such devices.

Man-in-the-Middle Attacks

A device that manages to insert itself in the communication path between two hosts represents a man-in-the-middle attack. IPsec can protect against such attacks so long as the attacker cannot get the key used to encrypt the communication.

Flooding Attacks

Flooding attacks are meant to busy out infrastructure or host resources. They can disrupt the packet-forwarding or control-plane functions of the network. Rate limiting can be used to mitigate such attacks. On dual-stack interfaces, it is likely that IPv6 traffic is rate limited more aggressively to protect the existent, revenue-generating IPv4 services.

6PE Security

Based on their operational similarities, 6PE and IPv4 VPNs can share the same security policies. On the other hand, 6PE's role of a "global VPN" for offering IPv6 Internet access services opens the door to other possible attack vectors. 6PE's use can expose a service provider's infrastructure to potential attackers. Following are some of the threats that should be considered and the corresponding countermeasures:

• IPv6 users can discover aspects of the IPv4 infrastructure. 6PE's dependency on the underlying IPv4 Multiprotocol Label Switching (MPLS) network can lead to information leaks. To avoid such problems, the 6PE deployment should avoid using IPv6 addresses that incorporate IPv4 information. For example, it should not use 6PE router IPv6 loopback addresses constructed from its IPv4 loopback address. IPv6 traceroutes should be explicitly blocked because they could reveal the IPv4 addresses of the P-routers. An alternative is to configure P-routers (via the no mpls ip propagate-ttl forwarded command) not to propagate TTL for traceroutes.

• The IPv4 service can be impacted by IPv6 attacks on 6PE routers. If the same provider edge (PE) router supports both IPv6 (6PE) and IPv4 services at the same time, an attack over IPv6 will impact the IPv4 service, too. To protect against such attacks, the IPv6 addresses of the 6PE routers should not be advertised outside the provider network. ACLs can also be used to control access to 6PE routers. Control-plane protection mechanisms (see the subsection later in this chapter) can also be used to guard the PE router resources against IPv6 attacks. However, the best way to avoid this type of exposure is to deploy PE routers and Route Reflectors (RRs) dedicated to the IPv6 service.

The key security concern of enabling 6PE in a network is that it could reveal IPv4 infrastructure information. The best practices mentioned previously for addressing this issue should be implemented even if 6PE is used only for a trial service.

A Note on VPN Security

Up to this point, the analysis has focused on the characteristics of the threats and the mitigation best practices from the point of view of both unicast and multicast IPv6 services. The subject of securing MIPv6 was also covered, so the only major service left unmentioned is VPN.

There is no significant difference between securing VPNs in IPv4 and IPv6. In both CE-based and PE-based VPNs, the same concepts apply. The security aspects of IPv6 VPNs are discussed in Chapter 7, "VPN IPv6 Architecture and Services." For more details about IPsec VPNs in IPv4, refer to IPSec VPN Design by Vijay Bollapragada, et al. At the time of this writing, however, the features needed to secure IPv6 VPN services were not yet available.

Note

Whenever an IPv4 IPsec VPN session is available, it can be used to secure the transport of IPv6, too.

One interesting security challenge is raised by the elimination of NAT in IPv6. Although it provides some protection, NAT should never be considered a security feature. Nevertheless, in IPv4 it provides the fringe benefit of hiding the internal network addressing and topology from the outside world.

In IPv6, the lack of NAT makes it impossible at this time to open up an IPv6 VPN toward the rest of the world without exposing the internal addressing and structure of the network. Tight perimeter security can protect the IPv6 network against attacks. The negative impact of removing NAT is being analyzed within the v6ops IETF working group (see draft-vandevelde-v6ops-nap-01.txt), and workarounds for this particular issue are starting to emerge. The "Topology Hiding" section of Chapter 8 describes a possible elegant way to hide the internal topology of a private network with the help of MIPv6.

Note

The security best practices used for deploying 6PE and discussed in the previous section are applicable to the deployment of 6VPE, too.