Migrating to IPv6 Opportunity or threat for network security?

Migrating to IPv6 Opportunity or threat for network security?

Executive summary Contents 02 Executive summary 03 1. Introduction 03 2. IPv6 security check 03 2.1 Addresses 04 2.2 NAT free operation 05 2.3 ICMP, NDP and stateless autoconfiguration 05 2.4 IPsec 06 2.5 Conclusion 06 3. Securing the IPv4-IPv6 Transition 07 3.1. A new protocol but it s already here 08 3.2. Security check: transition mechanisms 10 3.3. Conclusion 10 4. Our engagement 11 5. Abbreviations and references Today, available IPv4 address pools have been nearly exhausted, making migration to IPv6 inevitable. Especially, large operators connecting millions of subscribers to the Internet will soon need to migrate to IPv6 if they want to stay competitive and continue to grow. Cyber security threats have also become critical in the last few years. Consequently, knowing the impact of migration to IPv6 on the security of IP-based networks is extremely relevant for operators. While IPv6 advocates usually claim that IPv6 provides superior security in comparison to IPv4, a closer look shows that this is not entirely correct. Of course, there are a number of IPv6 features that help to secure a network. On the other hand, new IPv6 features designed for supporting efficient network operation may become dangerous weapons in the hand of attackers. The large scale threats of today s IPv4 Internet, such as worms / viruses / trojans, botnets, Denial of Service attacks, attacks on the domain name system, attacks on web applications, phishing or spamming do not depend on the IP protocol version. They will continue to exist in the future IPv6 Internet. To mitigate such threats, well known security measures like hardening, secure operation and maintenance, usage of cryptographic protocols, perimeter security and traffic separation continue to be the main building blocks for a secure network architecture. As IP layer attacks will try to exploit IPv6-specific functions, existing IP layer hardening rules and firewall policies must be enhanced to cover the IPv6 features and mitigate such threats. During the transition phase from IPv4 to IPv6, which will span years, networks will typically be more endangered. First, the new IPv6 software may not yet be field-proven, so bugs and vulnerabilities must be expected. In addition, lack of administrators experience with IPv6 functions, IPv6 security threats and IPv6 security functions may lead to poorly configured and more vulnerable networks. Security devices like firewalls or intrusion detection systems may initially offer IPv6 support only with a limited feature set and will take some time to reach parity with IPv4 support. Specific IPv4 to IPv6 transition mechanisms like dual stack, tunneling or translation add complexity to the network and increase the attack surface. So in the transition phase, specific emphasis must be put to careful, security-aware operation and maintenance of network nodes and end systems. Security devices must be selected considering their IPv6 capabilities. Transition mechanisms must be used with security in mind. Once IPv6 has really replaced IPv4, the future IPv6 networks can be expected to have the same level of security as today s IPv4 networks. 2 Migrating to IPv6 Opportunity or threat for network security?

Statement 2: IPsec is mandatory in IPv6 IPsec provides encryption and cryptographic integrity protection for all IP-based traffic and is mandatory to implement in IPv6. Counterstatement IPsec used to be mandatory to implement, but this has been changed in the newer version of the standard. Moreover, IPsec has never been mandatory to use. IPsec has a number of issues (e.g., it requires additional mechanisms for key management and peer authentication). It is likely that there will not be significantly more IPsec deployment in the upcoming IPv6 networks than in today s IPv4 networks. 1. Introduction Statement 1: IPv6 was designed with security in mind IPv6 is the newer protocol. It was designed with security in mind and incorporates many of the lessons learned in IPv4. Counterstatement IPv6 was mainly designed to address the exhaustion of the IPv4 address space. It introduces mechanisms that impose new security risks (e.g., autoconfiguration, renumbering, stronger usage of ICMP, multicast, IPv4-IPv6 transition techniques). Now that the Internet Assigned Numbers Authority s (IANA) pool of available public IPv4 addresses has been nearly exhausted, and very soon the Regional Internet Registries (RIR s, like ARIN or APNIC) will have no more IPv4 addresses to assign, it is time to make a move towards IPv6. Especially large operators providing Internet connectivity to millions of subscribers need to act to stay competitive and maintain the option for growth. On the other hand, security threats on the Internet, currently running on IPv4, have become ever more critical in the recent years making it vital for operators to secure their networks against cyber security threats. Consequently, exploring the impact of migration to IPv6 on the security of IP based networks is of high interest for operators. There are a number of popular opinions concerning security aspects of IPv6. Naturally, IPv6 advocates usually claim that IPv6 provides superior security as compared to IPv4. However, one could also argue that Statement 3: NAT free operation in IPv6 IPv6 doesn t need Network Address Translation (NAT), thus decreases the operational complexity and consequently the attack surface, and facilitates deployment of end-to-end IPsec. Counterstatement Absence of NAT may give external attackers slightly more insight into a network. End-to-end IPsec is not always applicable and has also disadvantages inside protected private networks. IPv6 will make networks less secure, as it introduces a number of previously unknown security threats. In the above, three IPv6 security statements are given, each with a counterstatement questioning the message of the security statement. Such high-level arguments do not give a clear indication whether IPv6 will put networks more at risk or less than IPv4. On the other hand, as the move to IPv6 is inevitable for operators, what really matters is to find out how IPv6 features can be applied to help secure the network, to be aware of any security threats imposed by IPv6, and find ways to mitigate them. This paper tries to bring some light into these issues. In the first part, it investigates the security aspects of a number of IPv6 protocol features (section 2). In the second part, it explores the specific security challenges during the transition phase, where both protocol versions coexist, and IPv4 is replaced by IPv6 step by step (section 3). 2. IPv6 security check 2.1. Addresses The most significant difference between IPv4 and IPv6 relates to the size of IP addresses and the respective addressing schemes. Clearly, addressing schemes are quite important with respect to security, because they can have strong influence on the way security policies (like packet filtering rules) can be constructed and enforced. For example, exhaustive brute force search for targets in a given network is not feasible in IPv6 because of the large address space (each network accommodates about 2 64 host addresses). Obviously, there are cleverer ways to locate attack targets than blind scanning, and they work mostly independent of the IP protocol version. Moreover, IPv6 also specifies well known anycast and multicast addresses (see below) that allow locating hosts. In some deployments, low values like 1, 2, 3 are chosen as host addresses, because it is desirable to do so in facilitating usage of the respective address literals (see below). Clearly, these interfaces can be located immediately by an attacker. For the future IPv6 Internet, a hierarchical address scheme is intended, where contiguous parts of the address space represented by an address prefix are assigned to organizations. On the top level there will be the Regional Internet Registries, which will assign address spaces to Internet Service Providers (ISPs), which in turn will assign parts of their address spaces to enterprises. Such a setup reduces routing complexity, and supports security by making the definition of access control lists (ACLs) or spoofing filters much easier. However, enterprises desiring not to depend on a single ISP can rather easily get provider independent addresses. This contradicts the hierarchical address scheme to a Migrating to IPv6 Opportunity or Threat for Network Security? 3

certain extent and will diminish the complexity and security gains that could be achieved by a hierarchical address scheme. Scope of the site IPv6 Internet (global scope) IPv6 also features scoped addresses, i.e., addresses that are only valid in a certain scope, like the local link or the local site 1. This facilitates the restriction of communication to specific scopes, which makes certain attacks from outside this scope impossible. However, implementing such type of communication restriction may not be trivial and may sometimes be omitted for this reason. Also, if a single host uses different addresses in different scopes, thus assigning multiple addresses to single interfaces, it can become more complex to configure security relevant features like ACLs on routers or firewalls. Figure 1 shows an example of the usage of scoped addresses. A local site, consisting of Ethernet segments interconnected by routers, is part of the IPv6 Internet. Each host, at its interface by which it connects to an Ethernet segment, may use three distinct, differently scoped addresses: one for link local communication only, a unique local address for intra site communication, and finally, a global address for Internet communication. In IPv6, hosts typically choose the 64 bit interface identifier (id) of their IPv6 address by themselves. Using always the same interface id, e.g. by deriving it from the interface s MAC address as specified by IEEE EUI-64 [1] would make a host trackable even when roaming in different IP networks. To avoid this, IPv6 privacy addresses (RFC 4941) have been specified that allow hosts to change their interface ids dynamically. While this enhances privacy, it may also be abused to make it harder to track down malicious hosts that carry out attacks or distribute spam. IPv6 doesn t provide broadcast addresses (referring to all hosts, e.g., 1 The originally specified site local addresses have been deprecated by the IETF. Instead, unique local addresses (RFC 4193) can be used in the scope of a site. link local scopes global address unique local address link local address prefix 2000::/3 prefix FC00::/7 prefix FE80::/64 Figure 1: Usage of IPv6 scoped addresses on a link), but makes heavy use of multicast addresses. IPv6 specifies a number of standard multicast addresses referring to routers, DHCP servers, MIP home agents, etc., which are essentially valuable network resources that may be preferred targets of attacks. Despite some IPv6-inbuilt protection, multicast addresses may also be abused in so called amplification attacks, where a single packet may trigger a flood of response packets that may cause a DoS condition somewhere in the network. To mitigate such threats, multicast packets must be filtered carefully at least at network borders. Multicast packets that can be recognized as illegal should be discarded; other multicast may be limited to a reasonable rate. Last but not least it has to be considered that general IPv6 address literals (like 2001:0db8:5a7b:4cfe:e3a2:4ff1:c63b:4 9a2) can be quite complicated and hard to read or write for humans. Using such address literals directly, e.g., when configuring IPv6 routers or firewalls, seems to be hardly feasible, and even usage of less complicated address literals (like FE80::4321:5678) seems more error-prone than usage of IPv4 address literals only (like 192.168.20.1). (001...) (1111 110...) (1111 1110 1000 0000... 0000...) 64 bits 2.2. NAT free operation With the ongoing depletion of the IPv4 address space, Network Address Translation (NAT) between private and public IP addresses has become very popular and its importance is likely to grow. This is a big burden for the operation of networks and applications, and also breaks security protocols, such as authenticating packet header information or carrying IP addresses in encrypted payloads (which may be considered bad practice but is nevertheless used in some applications). Moreover, it poses new threats, like exhaustion of the available address pool, or getting shared public addresses blocked by malicious behavior. In pure IPv6 networks, NAT should not be needed anymore. Removing NAT decreases the operational complexity and consequently the attack surface, and facilitates deployment of end-to-end security protocols. On the other hand, if all hosts have public addresses, they are more easily reachable and therefore attackable from the Internet as compared to hosts with private addresses, which can only be reached when they have initiated some communication relationship that traverses the NAT device. However, an IPv6 network can be protected against unsolicited communication from outside in a 4 Migrating to IPv6 Opportunity or threat for network security?

straightforward way by deploying stateful filtering at the borders. It must be noted that there can be operational and deployment reasons for NATs in IPv6 networks. For example, NAT can be required to decouple organization-internal addressing from the public addressing. A stateless IPv6-to-IPv6 prefix translation has been defined to establish common ground for IPv6 NAT implementations (RFC 6296). During the transition of the Internet from IPv4 to IPv6, another form of NAT may be required: The translation between IPv6 and IPv4 (e.g. NAT64, see section 3.2). So even a pure IPv6 network may not be operated without NAT as long as there is a need that IPv6-only (client) hosts can access IPv4-only servers. 2.3. ICMP, NDP and stateless autoconfiguration Like IPv4, IPv6 includes an Internet Control Message Protocol (ICMP). IP hosts and routers in general trust ICMP messages and react on them, so malicious ICMP messages are a substantial threat for IP networks. Therefore, ICMP must be filtered at least at the network borders between operators, and the behavior of routers with respect to ICMP must be configured carefully. ICMP is more essential for IPv6 than for IPv4, and is also more powerful. It is typically not possible to block incoming ICMPv6 (ICMP for IPv6) completely at the network border. For example, inside hosts are not able to do path MTU (maximum transmission unit) discovery for paths to outside hosts if the firewall blocks all incoming ICMPv6. Therefore, ICMPv6 filtering must be configured carefully depending on the specific scenario. The IETF has even dedicated an RFC (RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls ) to this topic, which emphasizes the importance of the issue. A certain set of ICMP messages, combined with procedures on how to apply them, constitute the Neighbor Discovery Protocol (NDP). NDP allows stateless autoconfiguration of hosts, i.e., hosts can dynamically get a valid, basic IP configuration (in particular, a globally valid IPv6 address) without the need for a DHCP server that would have to keep state, i.e., keep track of address assignments. An attacker on the local link (e.g., in the same Ethernet) can perform a variety of attacks on NDP, resulting e.g. in DoS or in the attacker becoming able to sniff all communication on the link. Such attacks are in a similar way also possible in IPv4 networks, which do not have NDP, but make use of other protocols like the Address Resolution Protocol (ARP). Various proposals exist to secure NDP. The most comprehensive approach is usage of Secure Neighbor Discovery (SEND). SEND provides cryptographic protection, including peer authentication, and thus gives a level of protection that is not available in IPv4 networks relying on ARP. On the downside, SEND cannot prevent all possible attacks on NDP, and requires significant operational efforts. For example, all hosts need private/public key pairs, and certificates must be generated, signed and distributed. Also, hosts must perform CPU-demanding public key operations, which in turn provides a starting point for CPU exhaustion attacks. Another solution may be source address validation improvements (SAVI, also the name of a respective working group of the IETF) which can be used to prevent source address spoofing within the link scope. Stateless autoconfiguration may also be used by operators to provide the IP configuration for subscriber devices. For example, 3GPP has specified its use in mobile networks. In this case, NDP runs on a point-to-point link, so no external hosts have the possibility to interfere, and specific measures to secure NDP are not required. Note however that there is a trend to assign addresses not via stateless autoconfiguration but using DHCPv6, to add more control. IPv6 uses ICMP also for the Multicast Listener Detection (MLD), by which hosts can register for receiving information destined to different multicast addresses. Again, the trust model is that all hosts on the local link are trusted, and no security is built into MLD. Consequently, a malicious local host can easily attack MLD, and for example cut off all other local hosts from the multicast traffic. 2.4. IPsec IPsec is a framework that provides encryption and cryptographic integrity protection for all IP based communication. This requires and includes mechanisms for authentication of the peers that use IPsec to communicate. IPsec is available for IPv4 as well as for IPv6. IPsec was specified as mandatory to implement in IPv6 nodes. Based on this, and on the fact that IPsec tunnels, once established, provide full protection of all communication running through them, a number of IP related protocols, like routing protocols or mobility protocols, where specified for IPv6 without specific security features, but solely relying on IPsec for security. However, IPsec has turned out to be hard to deploy, and significantly complicates the operation of networks. In particular, IPsec requires peer authentication, either based on the deployment of preshared keys (PSKs), or on public key cryptography. The PSK approach does not scale for large networks, and usage of public keys requires an expensive public key infrastructure (expensive in terms of operational costs). Moreover, traffic encryption does not interwork well with network traffic monitoring or network based intrusion detection systems. IPsec also requires a certain amount of (additional) CPU power, which may not be available on some end devices. Migrating to IPv6 Opportunity or Threat for Network Security? 5

While implementation of IPsec is mandatory, its usage is not. Taking this into account, it can be concluded that IPsec will not be available in all IPv6 devices. It is likely that there will not be significantly more IPsec deployment in the upcoming IPv6 networks than in today s IPv4 networks. This also means that protocols that have in-built security in IPv4 (like OSPFv2) but solely rely on IPsec in IPv6 (like OSPFv3) may be more in danger in IPv6 networks. The IETF is aware of these issues, and is currently preparing an update of the RFC specifying the IPv6 node requirements (RFC 4294). The new version is expected to downgrade the requirement from must implement IPsec to should implement IPsec. 2.5. Conclusion The preceding sections treat some selected features only. Other interesting aspects include the impact of IPv6 extension headers on packet filtering, source routing, the security of IPv6 routing protocols, or the security impact of IPv6-specific support for mobility (Mobile IP in its different flavors, like host based or proxy mobile IP). Even so, it can be concluded that there are a number of IPv6 features that help to secure a network. On the other hand, new features designed for supporting efficient network operation may turn out to be dangerous weapons in the hand of attackers. Surely, a number of threats known from IPv4 networks will persist in IPv6. Some of them might be even identical, like sniffing, flooding or source address spoofing. Others will be adapted specifically to IPv6, but will follow well-known principles, like attacks on link-local protocols (ARP versus NDP), amplification attacks, fragmentation attacks, source routing or usage of bogus addresses. So it will be necessary to adapt available security measures to IPv6, e.g. to issue IPv6-specific hardening guidelines and to define IPv6-specific firewall rules. It can be expected that attacks against IPv6 will become more and more common, as IPv6 itself will become commonly deployed. Some hacking tools have supported IPv6 already for a considerable time, and will be more enhanced as IPv6 gains importance. Still, the specific issues of the IP protocol layer do not touch the principles of designing sound security architectures. Well known security measures like hardening, secure operation and maintenance, usage of cryptographic protocols, perimeter security and traffic separation continue to be the main building blocks for a secure network architecture. After all, the large-scale threats of today s IPv4 Internet, like worms/viruses/trojans, botnets, DoS, DNS attacks, attacks on web applications, phishing or spamming do not depend on the IP protocol version used in a network. 3. Securing the IPv4-IPv6 transition Because of the size of the Internet and its importance for business operations as well as for its users all over the globe, it is obvious that IPv4 cannot just be easily replaced by IPv6. Instead, a gradual transition is taking place involving a long period of coexistence of the two protocol versions. The IETF has considered and standardized various transition techniques, which can be categorized into three classes: Dual Stack, where IPv6 and IPv4 coexist within a network or on a device; Tunneling, where packets of one protocol version are encapsulated within packets of the other protocol version; Translation, which is needed to allow IPv4-only hosts to communicate with IPv6-only hosts. Note that different transition mechanisms may be required to be used simultaneously to cover different capabilities and communication needs. It is obvious, that during the transition and coexistence phase, networks will be more endangered, simply because of the additional mechanisms, the increased complexity and the resulting increased attack surface. Taking this into account, the IETF has dedicated an RFC to this topic (RFC 4942 IPv6 transition/coexistence security considerations ). The following subsections explore the security issues during the transition phase in more detail. 3.1. A new protocol but it s already here Introduction of a new protocol in general raises security risks, in particular such a fundamental protocol as IPv6. So IPv6 implementations may not yet be fieldproven, and bugs and vulnerabilities must be expected. Also additional services like DNS may be implemented erroneously for IPv6 (see e.g., RFC 4074 Common Misbehaviour Against DNS Queries for IPv6 Addresses.) Moreover, administrators cannot be expected to be already experienced in configuring IPv6 functions and particularly IPv6 security functions. This may result in sub-optimal configurations and thus more vulnerable networks. On the other hand, hackers as it is the case so often may be a step ahead and already exploiting IPv6 vulnerabilities. Security devices like firewalls or intrusion detection systems currently offer IPv6 support only with a limited feature set, and sometimes also with limited performance. IPv6 support will only gradually reach feature and performance parity with IPv4. An important issue is that while networks are currently mostly running on IPv4, many end systems (like Linux or Microsoft Windows PCs) already comprise IPv6 functions, and are able to use them, without knowledge or control by the responsible network administrators. Running IPv6 in parallel to IPv4 is mostly supported by end 6 Migrating to IPv6 Opportunity or threat for network security?

IPv4-only traffic monitoring and intrusion detection system (monitors IPv4 traffic) systems as well as by Layer 2 equipment like Ethernet switches (see section 3.2). IPv6 may even be enabled automatically on end systems, without knowledge of their users. This does not only relate to basic IPv6 functions, but also to complex transition technologies like Teredo (RFC 4380, see also section 3.2) that imply massive security threats. So attackers may abuse IPv6 to carry out a variety of attacks, unrecognized by security measures like firewalls or network intrusion detection systems that may be in place but are configured for IPv4 operation only. IPv6 may also be used as a backdoor protocol, to access compromised hosts and carry away stolen information. Figure 2 gives an example of illegal usage of IPv6 within an IPv4-only Intranet. In this example, a malicious user has activated IPv6 on his client, and then activated it also on other hosts, by simply sending NDP messages like Router Advertisements. Subsequently, attacks may be carried out against such hosts. Figure 3 shows an example, how IPv6 may even allow to connect a host within an IPv4 intranet to the IPv6 Internet, making this host reachable for any type of IPv6 traffic, including IPv4 client Illegally activated IPv6 functions Figure 2: Illegal IPv6 usage within an IPv4 intranet unsolicited traffic, from the IPv6 Internet, in spite of the IPv4 firewall deployed to protect the intranet. So how to mitigate such security threats? First of all, network operators need to make a thorough assessment of IPv6 functions and IPv6 security functions available in network infrastructure elements, servers and typical client systems before starting with IPv6. Also, they should not pilot IPv6 as long as the available security mechanisms are not sufficient. It is important to pick the suitable point in time and the suitable scope for the IPv6 launch. Administrators must be trained in IPv6 and IPv6 security well in advance. As IPv6 software may still IPv4 Intranet activate IPv6 in other hosts carry out IPv6 based attacks transfer illegally retrieved data have bugs, careful vulnerability monitoring and timely patching is essential for all IPv6 related software. Even if the launch of IPv6 is not yet planned, awareness of IPv6 and IPv6 security issues needs to be created. As long as the policy is to use only IPv4, one may try to prevent IPv6 usage, by: disabling all IPv6 functions in hosts (e.g. via Microsoft Active Directory Policies); blocking native and tunneled IPv6 at firewalls; using IPv6 aware IDS. However, the preferred approach is not to block IPv6, but to launch it in a controlled and secure way, together IPv6 host Illegal IPv6 peer-to-peer traffic IPv4 client IPv4 only firewall Public relay IPv4 Intranet IPv4 Internet IPv6 Internet Illegally activated IPv6 functions, e.g. Teredo IPv6 in UDP in IPv4 tunnel IPv6 based attack IPv6 host Figure 3: Illegal IPv6 Internet access from an IPv4 intranet Migrating to IPv6 Opportunity or Threat for Network Security? 7

with appropriate IPv6 security measures. This will avoid or at least discourage (unauthorized) usage of multiple transition techniques in a network by different end systems. 3.2. Security check: transition mechanisms Dual Stack A plausible approach to introducing IPv6 is the dual stack approach. Here, hosts and routers can run both IP protocol versions in parallel. On the lower layer, e.g. Ethernet, frames carrying IP packets of different versions can be distinguished, e.g. by the EtherType field in Ethernet, so each of the two parallel IP layers on a network element will only receive packets of the appropriate protocol version, and traffic of the other version is invisible for it. The main security issue for the dual stack approach is simply that now there are two IP protocol versions that may be attacked, and therefore must be hardened, monitored, possibly patched etc. Attackers may even profit from combining v4 and v6 related attacks. For example, the network may be scanned using IPv4. If targets are found, the attacker may try out to derive the correct IPv6 address for the target (which is often done in a deterministic way, like putting the IPv4 address into the lower 32 bit of the interface id and setting the upper 32 bit to a fixed value like 0). The attacker may then abuse the IPv6 access to the target for IPv6-specific attacks. Tunneling Tunneling of one IP version within the other is the second class of transition mechanisms. Tunneling allows IPv6- hosts oripv6-networks to connect via IPv4 transit networks, or vice versa. Early tunneling techniques like Teredo (RFC 4380), ISATAP (RFC 4214) or 6to4 (RFC 3056) focused on providing IPv6 connectivity over IPv4 networks for a rather experimental usage, given that all relevant services in the Internet are still provided via IPv4. Consequently, the importance of these early techniques is decreasing. For example, 6to4 is in the process of being deprecated by the IETF. However, in general, tunneling of IPv6 over IPv4 still remains important, as it allows to continue running transport networks on IPv4, even if end systems have already moved to IPv6, which may be inevitable when new hosts cannot get IPv4 addresses anymore. On the other hand, tunneling IPv4 over IPv6 may become relevant in a later phase, when transport networks have already moved to IPv6, but IPv4 services still need to be supported. An example for this is the approach of DS-lite (RFC6333). Note that tunneling always involves (a specific form of) dual stack at tunnel endpoints, which obviously must support both protocol versions. Figure 5 illustrates various tunnel scenarios. The need to configure tunnels adds complexity to the network configuration. Configuring network security measures Application IPv4 IPv6 Application Transport L2/L1 Transport IPv4 L2/L1 IPv6 Dual stack routers IPv4 L2/L1 IPv6 Dual stack host Dual stack host Application Application Transport Transport IPv4 L2/L1 IPv4 only host This communication is not possible! IPv6 only host IPv6 L2/L1 Figure 4: IPv4/IPv6 dual stack network 8 Migrating to IPv6 Opportunity or threat for network security?

IPv4 IPv6 IPv6 in IPv4 tunneling A dual stack host in a IPv4 network connected to an IPv6 network (e.g. configured tunnel via a tunnel broker or Teredo automatic tunnel) IPv6 IPv4 IPv6 IPv6 in IPv4 tunneling IPv6 IPv4 IPv6 networks connected through an IPv4 network (e.g. configured tunnel or 6to4 automatic tunnel) IPv4 in IPv6 tunneling A dual stack host in a IPv6 network connected to an IPv4 network (e.g. DS-lite ) IPv4 IPv6 IPv4 IPv4 in IPv6 tunneling IPv4 networks connected through an IPv6 network (typically a configured tunnel) Figure 5: Tunneling scenarios like ACLs, firewalls or anti spoofing filters gets more complicated if tunneling is used. While tunneling mostly does not provide protection against attacks (with the notable exception of IPsec tunnels), it may be abused to carry out attacks, such as evading inspection by firewalls or intrusion detection systems. Such systems may not be able to properly inspect traffic inside tunnels, either because of lack of maturity of IPv6 support, or because of inherent difficulties. For example, if IPv6 is encapsulated in UDP over IPv4, and a non-standard UDP port is used, a firewall has no clue that the UDP payload is in fact an IPv6 packet. So administrators must exert specific care when configuring tunneling and configuring security measures like filtering, especially when tunneling is present. A prerequisite is that security devices are capable of supporting tunneling, e.g., by the ability to inspect traffic inside tunnels or to selectively block specific forms of tunneling (e.g., to block Teredo only). Some tunneling protocols provide automatic tunnel establishment, based on specific IPv6 address types that indicate that an address is reachable over IPv4, with the IPv4 tunnel endpoint address encapsulated within the IPv6 address. Here, the network administrator has less control over the tunnels, and the automatic establishment procedures are an additional target for attacks. So applying such mechanisms may pose additional security risks to networks. As before, the only mitigation is careful configuration (e.g., of the endpoints of automatic tunnels), monitoring and applying upcoming security patches timely. Translation If an IPv6-only host needs to communicate with an IPv4-only host, translation between IPv6 and IPv4 is the only option. Once IPv6 has been fully adopted by major services e.g. those provided by Google or Facebook, new hosts may be deployed with IPv6 only, as they can no longer obtain public IPv4 addresses anyway. Translation may become a highly relevant approach then, required as long as there are still services running on IPv4 only that need to be accessible for these future IPv6-only clients. Years ago, the IETF had started to specify translation techniques, namely NAT-PT (network address translation protocol translation). NAT-PT has now been deprecated for various reasons (see RFC 4966), among them security issues. The current approach that allows IPv6 clients to access IPv4 servers is called NAT64 (see RFC6144, RFC6145, RFC6146 and RFC6052). If one IPv4 address per client is not available, only the so called stateful NAT64 is applicable. Stateless NAT64 has also been specified, but requires a dedicated IPv4 address for each IPv6- only host that needs to access IPv4- only servers. NAT64 needs to be complemented by DNS64 which translates IPv4 addresses into IPv6 addresses in DNS responses. Figure 6 illustrates NAT64. NAT64 has very similar security issues as NAT between private and public IPv4 addresses (see section 2.2): It breaks security protocols, in particular some protocols/modes of the IPsec framework and DNSSEC. (The latter may be mitigated by applying DNSSEC between the authoritative name servers and a trusted recursive resolver plus translator, with whom the clients can communicate securely). Moreover, a NAT64 translator adds complexity to the network and is an enticing target for attacks, including DoS attacks aiming at the exhaustion of the pool of public IPv4 addresses. Translation may also facilitate new forms of source IP address spoofing, or help to evade packet filtering. It must Migrating to IPv6 Opportunity or Threat for Network Security? 9

IPv6 address DNS Resolver/translator IPv4 address DNS server IPv6 client IPv6 network IPv4 network IPv4 server Protocol translator Figure 6: IPv6-IPv4 address translation be noted that NAT64 by no means mitigates all of the security issues quoted in RFC 4966 that contributed to deprecating NAT-PT. Mitigation of the threats against translation mechanisms may be achieved mostly by standard security measures, such as: hardening and overload control at translators robust implementation of translation software rate limiting of traffic towards translators Comparison from the security point of view All classes of transition mechanisms add complexity to the network and increase the attack surface. Dual stack may be the clearest approach IPv4 and IPv6 exist in parallel, so they can (and must) be secured in parallel, without significant interdependency. Tunneling approaches interlace the two protocol versions and thus seem to have a slightly higher potential for security relevant mis-configurations and vulnerabilities. Translation allows to run IPv6 only in a network and thus get rid of all the IPv4 related attacks. On the downside, translation adds the translators as complex, endangered additional network elements. It can be concluded that none of the approaches is clearly preferable from the security point of view. 3.3. Conclusion During the transition phase from IPv4 to IPv6 (which, as said, may last many years) networks will typically be more endangered. New IPv6 software may not yet be field-proven and may contain bugs and vulnerabilities. In addition, lack of administrators experience with IPv6 functions, IPv6 security threats and IPv6 security functions may lead to poorly configured and more vulnerable networks. Moreover, security devices like firewalls or intrusion detection systems may initially offer IPv6 support only with a limited feature set. IPv6 support will only gradually reach feature parity with IPv4. Obviously, IPv4 to IPv6 transition mechanisms like dual stack, tunneling or translation add complexity to the network and increase the attack surface. Last but not least, even if IPv6 has not yet been launched by the administration of a network, IPv6 functions may be enabled on hosts within this network without control by administrators, while IPv6 security functions may at the same time not be in place or are not suitably configured. This will leave IPv6 enabled hosts vulnerable to IPv6 based attacks. To mitigate such threats, IPv6 awareness must be created, beginning immediately. In the transition phase, specific emphasis must be put to careful, security-aware operation and maintenance of the IPv6 functions, including the transition mechanisms. Security devices like firewalls must be selected providing IPv6 capabilities that support the chosen transition mechanisms. 4. Our engagement Nokia Siemens Networks guides operators through a secure transformation from IPv4 to IPv6. Our experts help to prepare properly by designing the appropriate solution, accurate implementation and creating awareness to mitigate the potential risks. We have the end-to-end expertise from various successful migration projects and best of breed products to provide pre-tested and mature solutions. 10 Migrating to IPv6 Opportunity or threat for network security?

Our solutions include: Radio transport security for secure tunneling of IPv4 over IPv6 or vice versa with IPSec for the migration of access networks to IPv6. Market leading Evolved Packet Core (EPC) solution ready for IPv6 and dual stack implementations with first roll-out on IPv6. IMS systems already deployed and working in IPv6 mode. IPv6-ready subscriber data management and policy control solutions. Evolved Packet Core security solutions for proper filtering of IPv4 and IPv6 traffic with dual stack or translation for the EPC migration to IPv6. The solution consists of filter systems as e.g. firewalls to connect different protection zones. DNS/DHCP solutions combined with automated IP address management for efficient and safer handling of coexisting IPv4 and IPv6 address ranges inside the backbone and other security domains. These solutions also include registration and name resolutions between two types of addresses supported by DNS64. Strong authentication, authorization and encryption using Fully Qualified Domain Name (FQDN) based X.509v3 certificates are provided for IPv6 endpoints and network elements (3G and 4G). Carrier Grade NAT solution including CG-NAT 44 and 64 products from Cisco and Juniper with a comprehensive service bundle including network audit, Proof of Concept (PoC) testing and delivery based on our CG-NAT implementations with leading fixed, mobile and hybrid operators. End-to-end IPv4 to IPv6 transition consultancy covering IP/MPLS routing, Radio Access, Mobile Backhaul, (Evolved-) Packet Core, Border Network Gateway, Firewalls und Subscriber Data Management Systems. 5. Abbreviations and references Abbreviations 3GPP 3.Generation Partnership Project ACL Access Control List APNIC Asia Pacific Network Information Center ARIN American Registry for Internet Numbers ARP Address Resolution Protocol CG Carrier Grade CPU Central Processing Unit DHCP Dynamic Host Configuration Protocol DNS Domain Name Service DoS Denial of Service EPC Evolved Packet Core FQDN Fully Qualified Domain Name FTP File Transfer Protocol HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure ICMP Internet Control Message Protocol IEEE Institute of Electrical and Electronic Engineers IETF Internet Engineering Task Force id identifier IDS Intrusion Detection System IP Internet Protocol IPv4 IP version 4 IPv6 IP version 6 (the successor of IPv4) IPsec IP secure (an IETF protocol framework for securing IP transport) ISP Internet Service Provider MAC Media Access Control MPLS Multiprotocol Layer Switching NAT Network Address Translation NAT-PT Network Address Translation Protocol Translation NDP Neighbor Discovery Protocol O&M Operation and Maintenance OSPF Open Shortest Path First (an IP routing protocol) PC Personal Computer PSK PreShared Key RFC Request for Comments (IETF standards document) SEND Secure Neighbor Discovery TCP Transport Control Protocol UDP User Datagram Protocol References IETF RFCs are not explicitly listed here; they can be obtained easily by entering their numbers e.g. at http://tools.ietf.org/html [1] IEEE, Guidelines for 64-bit Global Identifier (EUI-64 ) http://standards.ieee.org/develop/regauth/tut/eui64.pdf Migrating to IPv6 Opportunity or Threat for Network Security? 11

Nokia Siemens Networks P.O. Box 1 FI-02022 NOKIA SIEMENS NETWORKS Finland Visiting address: Karaportti 3, ESPOO, Finland Switchboard +358 71 400 4000 (Finland) Switchboard +49 89 5159 01 (Germany) Copyright 2012 Nokia Siemens Networks. All rights reserved. Nokia is a registered trademark of Nokia Corporation, Siemens is a registered trademark of Siemens AG. The wave logo is a trademark of Nokia Siemens Networks Oy. Other company and product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. This publication is issued to provide information only and is not to form part of any order or contract. The products and services described herein are subject to availability and change without notice. www.nokiasiemensnetworks.com