Security in an IPv6 network is not substantially different from security in an IPv4 network. Many of the existing well-known IPv4 attacks can be performed with IPv6, so our means for securing data are similar. Just like in the IPv4 world, there will always be unethical hackers who find new ways to break into our networks. The designers of security concepts and the entire computer security community will have to stay alert and keep finding mechanisms to keep pace with the hackers and find ways to protect their networks from new attacks.

If both protocols (IPv4 and IPv6) are used in a network, each protocol needs its own security concept and provisions, which need to be coordinated. IPv6-capable firewalls have filter rules for IPv4 and separate filter rules for IPv6.

Another point to observe is that IPv6 is included in most operating systems and is usually rather simple to configure. Sometimes tunnel mechanisms are activated by default. IPv4 network administrators may believe that they do not have to worry about IPv6, but they don't realize that there may be IPv6 traffic in their network already. This fact is used by IPv6 hackers to intrude into IPv4 networks.

Find the IPv6 traffic in your network by filtering your trace files for 0x86DD in the MAC header or for protocol 41 in the IPv4 protocol type field. You may find a surprising number of Neighbor Discovery messagesa good indicator that you have active IPv6 nodes on your network.

IPsec, while being a good security mechanism, is not the end-all, be-all for security. Most security professionals agree that there is no "silver bullet" in securing a network from internal or external attacks. Combinations of best practices and user training can minimize risks. If you are deploying IPv6 in the near future, there are some security concerns that should be addressed. Be advised that this is not a complete list, as entire volumes of information could be written on the subject.

Native IPv6

When connecting to IPv6 natively, some security issues that should be considered are discussed in the following sections.

Public Key Infrastructure (PKI)

While RFC 4301 specifies the requirement for IPSec in the IPv6 protocol, it does not cover how the keys will be exchanged. You could manually set up preshared keying, but in large enterprises, this task becomes tedious and time-consuming. In such environments, using a central certificate server is ideal. With IPv6, there were no such centralized certificate servers until recently. This has changed with servers that are based on the IKEv2 protocol, which is specified in RFC 4306. Benefits of IKEv2 are its usability on both IPv4 and IPv6 and its simpler implementation. It is not compatible with the first version of IKE, but both versions' header formats are similar enough to run them both unambiguously over the same UDP port.

Firewalls and intrusion detection/prevention systems

While end-to-end IPSec is considered one of the major advantages of IPv6, it also introduces new problems with existing firewalling and IDS/IPSes if ESP is used with encryption turned on. If the packets are encrypted from end to end, how does a border device inspect the packets without decrypting them? Storing all the encryption keys in a central location leaves both a central point of failure and a central location for a blackhat hacker to break into and steal all the encryption keys for the network. One of the ideas that has been presented to the community is a client server model for IDS/IPS (similar to current enterprise-level antivirus protection). A central server or servers keeps a database of attack signatures or network anomaly analysis. A client downloads the signatures locally and the client computer scans the packets itself, alerting the central server if it finds a signature match. Issues in current IPv4 IDS/IPS systems include lack of detection of tunneled IPv6 protocols and a general lack of attack signatures for IPv6-based attacks, although as IPv6 proliferates to more networks, these issues should eventually be solved.

Firewalls that support IPv6 are included in most of the major operating systems, but firewalls that keep the state of connections (Stateful firewalls) are not available in older implementations of Linux or in Windows XP/2003. Cisco, Checkpoint, and Netscreen (Juniper), among others, have Stateful inspection of IPv6 packets in newer versions of their software.

Implementation issues

Vendor IPSec implementations themselves can also cause security issues. For example, in several current IPv6 IPsec implementations, only authentication and integrity services are available using ESP with Null encryption or AH. Not all ESP implementations support the confidentiality pieces, which could provoke a false assumption of the security services available to be deployed if you don't check your vendor implementation.

Many IPv6 implementations are fairly new. This leads to two other possible security issues. The first issue is the lack of IPv6 assessment tools. It is a common practice in the information security field to audit your own network with well-known security auditing tools, and then secure the flaws found with those tools. Many of these popular tools have not been ported to audit IPv6 networks. The second issue is untested code in IPv6 implementations (which also ties into not having the tools to test the implementations). Code that has not been "put through the wringer" is probably going to have more security flaws than code that has been used in production environments.

Neighbor Discovery issues

Other security concerns to be aware of are abuses of the Neighbor Discovery Protocol (NDP), Duplicate Address Detection, and Router Advertising. A quote from RFC 2462 (IPv6 Stateless Autoconfiguration) states:

"If a node determines that its tentative link-local address is not unique, autoconfiguration stops and manual configuration of the interface is required."

This poses a possible Denial of Service attack, as multiple IPv6 addresses can be assigned to a single interface. A rogue workstation could be assigned several thousand addresses and deny other workstations the ability to acquire a link-local address. Or even much simpler, a software responder can be built that always responds with "address in use."

Another point is that link-local addresses can be acquired without preconfiguration. An attacker can get access to a link without any further knowledge about the network. This feature gives a malicious node the opportunity to mount an attack on any other node attached to this link. Possible ways to protect from this are either link-layer authentication or the use of Cryptographically Generated addresses.

Router Advertisement spoofing is another security concern. Since multiple addresses are allowed on a single interface, multiple routes are allowed as well. A booting node sends a Router Solicitation to the all-routers multicast address (FF02::2). Each router on the link replies with a Router Advertisement containing configuration information for the client. This offers up the possibility of sending traffic through a router through which it's not supposed to be sent (allowing traffic sniffing on the rogue router). Obviously, this type of attack happens in the IPv4 world also; it differs only in the mechanisms used. Using the IPsec's AH component or SEcure Neighbor Discovery is a good way to mitigate this risk, among others.

The specification in NDP suggests using IPsec to protect from attacks, without providing more detailed information on how to do this. In many cases, especially in public and wireless networks, the key management used with IPsec is too complex and impractical.

A new specification has been published in RFC 3971 to secure NDP without using IPsec. It is called SEcure Neighbor Discovery (SEND). This approach involves the use of new NDP options to carry public key-based signatures. A zero-configuration mechanism is used for showing address ownership on individual nodes; routers are certified by a trust anchor.

ARP in IPv4 has been replaced with ICMP messages in IPv6. Without using IPsec AH or SEND, however, NDP has many of the security problems that ARP presented in IPv4, such as redirect attacks (malicious nodes redirecting packets away from legitimate receivers), Denial of Service (DoS) attacks, and flooding attacks (redirecting other hosts' traffic to a victim node creating a flood of bogus traffic).

Port scanning

Port scanning has become much more complex, if not impractical. The interface identifier in IPv6 has 64 bits. draft-ietf-v6ops-nap-02.txt states that "an attacker has to send out a simply unrealistic number of pings to map the network, and virus/worm propagation will be thwarted in the process. At full rate 40Gbps (400 times the typical 100Mbps LAN, and 13,000 times the typical DSL/Cable access link) it takes over 5,000 years to scan a single 64 bit space." Go figure. If autoconfiguration is used without the Privacy Option, some parts of the address (e.g., Vendor ID) can be guessed, but it is still a vast space. A simple and good protection is to avoid easy-to-guess addressing schemes, not using words such as BEEF, F00D, CAFE, 1234, and ABCD as part of an IPv6 address, and not using sequentially numbered or easy-to-guess addresses to key infrastructure devices (such as x::1 for routers).

Multicast issues

IPv6 supports multicast addresses with site scope, which can potentially allow an attacker to identify certain important resources on the site if misused. Particular examples are the All Routers (FF05::2) and All DHCP Servers (FF05::1:3) addresses. An attacker that is able to infiltrate a message destined for these addresses onto the site will potentially receive in return information identifying key resources on the site. This information can then be used for directed attacks ranging from simple flooding to more specific mechanisms designed to subvert the device. The risk can be minimized by ensuring that all firewalls and site boundary routers are configured to drop packets with site scope Destination addresses. Also, nodes should not join multicast groups for which there is no legitimate use on the site, and site routers should be configured to drop packets directed to these unused addresses.

Transition and Tunneling Mechanisms

IPv4 is not expected to go away anytime soon. It is very likely that there will be IPv4 nodes on networks for many years to come. IPv4 hosts cannot communicate with IPv6 hosts without some sort of transitioning or tunneling mechanism, which can add complexity to the existing network topology and the underlying code for the network stack. Transitioning and tunneling mechanisms can also be used as backdoors into normally IPv4-only networks.

Using IPv6 as a back door into IPv4 networks has been a known practice since 2002. On December 17, one of the HoneyNet Project's (http://www.honeynet.org) Solaris 8 servers was compromised. The difference between this attack and earlier ones was that this attacker set up an IPv6 tunnel to another country and tunneled out the data he was trying to steal. This bypassed many intrusion detection systems of the time, and it would do so today. This practice has been made easier with the advent of UDP-based tunneling mechanisms designed to allow IPv6 from behind NATs (a practice that was almost impossible before these mechanisms were available). Teredo and Tunnel Setup Protocol (TSP) are two such mechanisms.

Generally, with tunneling one has to make sure that packets that enter the network through a tunnel cannot circumvent incoming packet filters. An attacker from the Internet could, for instance, send an IPv4 packet to the tunnel endpoint (the entry point to our network) that contains an IPv6 packet with an IPv6 Source address out of the range of our internal network. The tunnel endpoint decapsulates the packet and forwards the IPv6 packet to the internal network. The receiver believes that this packet originates from a host from the internal network. One example is that some IPv6 security mechanisms rely on checking that the hop limit is 255 and that a link-local Destination address is used. Such a packet can be introduced in an IPv6 network through a tunnel. Automatic tunnels are more dangerous in that respect because they have to accept packets from any source. So a partial protection can be to configure the tunnel endpoint to accept only packets from a configured tunnel entry point or to use only manually configured tunnels. But the attacker can still spoof that address. Additional filter mechanisms have to be implemented on the tunnel endpoint. draft-ietf-v6ops-ipsec-tunnels-02.txt, "Using IPsec to Secure IPv6-in-IPv4 Tunnels," goes into more details and gives guidance on securing manually configured IPv6-in-IPv4 tunnels using IPsec.

In the 6to4 scenarios, there are special considerations discussed in RFC 3964, "Security Considerations for 6to4." The issues here are that: a) all 6to4 routers must accept and decapsulate IPv4 packets from every other 6to4 router and from 6to4 relays, and b) all 6to4 relay routers must accept traffic from any native IPv6 node. The routing scenarios to be analyzed are as follows:

• From 6to4 to 6to4

• From native IPv6 to 6to4

• From 6to4 to native IPv6

Please refer to the RFC for a detailed discussion of the scenarios and best practices to protect your network.

6to4 tunneling is a well-known transition mechanism for networks that do not currently have native IPv6 connectivity. It consists of using a dual-stacked border router with a routable IPv4 address. The 6to4 router can be used for a Distributed Denial of Service (DDoS) attack using a tool called 4to6DDoS . 4to6DDoS does not require an IPv6 stack to be installed on either the attacking or the victim host. It sends IPv6 in IPv4 encapsulated packets directly from v4 to v4. The routers used for 6to4 tunneling can also be DoS attacked by simply connecting to the router several times with a private IPv4 address. These routers must accept and decapsulate IPv4 packets even if they are forged. They must also accept traffic from any native IPv6 node. 6to4 also does not guarantee symmetric routing, meaning that traffic can take one routing path going to its destination, and take a completely different path upon return. This situation may not be optimal from a security standpoint.

Mapped IPv4 addressing can also cause security issues. For example, if an attacker transmits an IPv6 packet with Source address of ::ffff:127.0.0.1 or ::ffff:10.1.1.1 in the IPv6 Source address field, it is possible to bypass Access Control Lists (ACLs) of the border router or firewall.