spacer

Technical and Economic Assessment of
Internet Protocol, Version 6 (IPv6)

IPV6 TASK FORCE
U.S. DEPARTMENT OF COMMERCE
National Telecommunications and Information Administration
National Institute of Standards and Technology


Previous Section Table of Contents Next Section

3 SECURITY IMPLICATIONS OF IPv6

3.1 Comparing IPv6 and IPv4

A number of commenters contend that IPv6 will provide a greater level of security than is available under IPv4. NTT/Verio states that because IPv6 was “designed with security in mind,” it is inherently more secure than IPv4, which does not have integrated security fields. [ 171 ] Other commenters note that support for Internet Protocol Security (IPsec) is “mandatory” in IPv6, but only “optional” in IPv4, which should lead to more extensive use of IPsec in IPv6 networks and applications. [ 172 ] BellSouth suggests that incorporating IPsec into the IPv6 protocol stack may reduce incompatibility between different vendors’ implementations of IPsec. [ 173 ]

The virtually limitless address space available via IPv6 can also further network security. Many common IPv4-based network attack scenarios begin with “brute force” address and port scans of entire subnets, sites, or even the Internet as a whole. In typical IPv4 deployments, once an assigned address prefix is known, an attacker only has to scan between 28 subnet and 216 site addresses (about 250 and 65,500 addresses, respectively) to find every host device on that network. The 64-bit space for individual interface IDs in the IPv6 address structure, on the other hand, is so vast that brute-force scans of the available address space are practically impossible. [ 174 ]

To the extent that deployment of IPv6 can enhance network security, the potential benefits to organizations and individuals can be significant. However, empirical estimates of the cost of cybersecurity breaches vary widely because of differences in what is included in the cost estimates and disincentives for companies to publicly disclose the number of breaches or level of damage. Studies that focus on IT costs, such as the 2004 Computer Security Institute/FBI Computer Crime and Security Survey, have reported total losses from cybersecurity breaches of approximately $142 million in 2004. [ 175 ]

The evidence gathered in the Task Force’s examination of IPv6 indicates that several potential security benefits can be realized from the eventual adoption and use of IPv6 by government, the private sector, and the Internet as a whole. At the same time, the greatest potential security benefits appear to be associated with the long-term evolution to new security paradigms, significantly different than those commonly employed in today’s networks. As a result, the potential security benefits outlined above must be balanced against what might be considerable costs to complete the design and development of new security models and the potential increased risks to incrementally deploy and transition to them in existing operational networks.

A number of factors may also limit the possible security benefits of IPv6 deployment in the near term. For example, although the expanded IPv6 address space may eliminate address and port scanning-based network attacks, network administrators may also lose the ability to perform brute-force address scans for the purposes of security auditing and testing. Many popular IPv4 security analysis tools are fundamentally based upon address scanning. Thus finding and identifying misconfigured or compromised hosts that are deliberately “hiding” on an IPv6 subnet may be as difficult as attacking them from the outside. This implies that in IPv6 networks both network administrators and would-be attackers must look elsewhere (e.g., DNS, server logs, neighbor discovery caches) to gather lists of active hosts.

Furthermore, although IPsec support is mandatory in IPv6, IPsec use is not. In fact, many current IPv6 implementations do not include IPsec. [ 176 ] On the other hand, though optional, IPsec is being widely deployed in IPv4. [ 177 ] There appear to be no appreciable technical differences in the way that IPsec is implemented in either protocol, and several commenters state that there are no significant functional differences in the performance of IPsec in IPv6 and IPv4 networks. [ 178 ] Any differences in performance are attributable to the presence of NATs in most IPv4 networks, which interfere with E2E communications using IPsec. [ 179 ] Thus, to the extent that NATs persist in IPv6 networks, they may reduce the security benefits available via the new protocol. [ 180 ]

Furthermore, experts generally agree that implementing any new protocol, such as IPv6, will be followed by an initial period of increased security vulnerability and that additional network staff will be necessary to address new threats posed by a dual network environment. [ 181 ] For instance, IPv6 provides support for various configuration capabilities (e.g., neighbor discovery, address auto-configuration, router discovery, renumbering) and control (e.g., path MTU discovery). [ 182 ] These capabilities are richer and better integrated than the auto-configuration capabilities typically found in today’s IPv4 networks and, as noted above, should result in reduced administrative costs associated with the operation of large-scale networks and potentially more streamlined implementations of some protocol functions.

Although there are clear operational advantages to these autoconfiguration and control capabilities, IPv6’s fundamental reliance on their operation also creates new threats and vulnerabilities associated with their potential misuse. This fact, coupled with a desire to support end-to-end (or host-based) security architectures in which trust among local network nodes is not assumed, requires that new levels of scrutiny be given to the security of the IPv6 Internet Control Message Protocol (ICMPv6) and its uses in neighbor discovery, and address auto-configuration. In addition, most IPv6 auto-configuration mechanisms make significant use of multicast, anycast, and scoped addressing capabilities. Care must be taken to ensure that network security systems limit the extent to which these new modes of addressing are not exploited as new attack vectors by compromised hosts. [ 183 ]

Additionally, IPv6 inherently supports modes of addressing other than unicast (e.g., multicast, anycast, scoped unicast) that are not typically found in IPv4 operational deployments. Although these new addressing capabilities present significant opportunities for the development of new network services, security mechanisms and practices for these new modes of addressing are not as mature or well understood as those for global unicast. Additional efforts are needed to develop security solutions for IPv6 that can enable secure multicast and unicast communications while at the same time ensuring that these capabilities do not create new vulnerabilities in the networks in which they are deployed.

Although IPv4 may have presented similar security concerns when first implemented, it currently benefits in its comparison with IPv6 from 20 years of identifying and addressing security issues. As IPv6 becomes more prevalent, many security issues will likely arise as attackers give it more attention. On the other hand, the experience gained from running IPv4 networks may help bring security levels in IPv6 networks up to the level of current IPv4 networks at a faster pace. [ 184 ]

3.2 Reevaluating Existing Security Models

More broadly, in order to fully use the capabilities of IPv6 and IPsec to provide security on an end-to-end basis, enterprises will likely need to reexamine their existing security models. [ 185 ] Most enterprises currently implement security measures at the perimeter of their corporate networks (e.g., with firewalls). Such deployments commonly consist of a very limited number of interconnection points where network links are typically partitioned into external (i.e., those that permit communications with the outside world), internal private, and internal public segments (e.g., for servers that are visible to and reachable from outside the protected network). Middle-box security devices sit at the intersection of each of these segment types carefully enforcing site-wide security policies, providing security services, and monitoring traffic for security events. [ 186 ] Virtual private networks (VPNs) (i.e., IPsec tunnels) are often used to securely connect one trusted network to another and NAT devices often are inserted to allow the internal-private parts of the enclave to use private addressing.

The advantages of perimeter-based security models are that they focus site security definition, management, enforcement, and auditing at a very limited number of points in the network. Typically, these perimeter security points are under the total control of enterprise security organizations and are some of the most highly maintained and monitored assets in enterprise network infrastructures. Centralized monitoring and audit functions also allow for easy integration with other corporate information assets such as equipment inventories, employee directories, and the like.

If an enterprise allows its employees to establish communications with non-enterprise users on an end-to-end basis, the enterprise will have to explore other approaches for securing its employees and the enterprise network from security threats. In fact, the growing importance and acceptance of mobile devices (e.g., laptops, PDAs, IP phones, sensors), self-organizing networks and systems (e.g., mobile ad hoc networks; service-oriented software architectures; and peer-to-peer systems), and environments with untrusted local links (e.g., public wireless access points, multi-access residential broadband) may compel organizations to explore end-to-end or host-based alternatives to their traditional perimeter security models. [ 187 ]

In either event, the enterprise will need to plan carefully to ensure that the new security model does not expose the enterprise to external threats. End-to-end security models are inherently more complex than perimeter-based architectures and, as security experts frequently point out, “complexity is the enemy of security.” [ 188 ] To date, moreover, development and standardization of the security management infrastructures and enforcement technologies necessary to support host-based security architectures appear to be immature. In order to support hybrid, distributed models of security policy management, enforcement, monitoring and audit, considerable research and development remains to be done. As a result, design, standardization, and testing of commercially viable technologies for security policy information models, distributed enforcement mechanisms, distributed monitoring mechanisms, and auditing technologies probably must precede practical deployment of host-based security architectures in large scale environments.

A key to widespread use of IPsec is the creation of a public key infrastructure (PKI), which is necessary to effectively manage widespread IPsec operations. PKI is an important element in the combination of software, cryptographic technologies, and network services that enable individuals and enterprises to protect the security of communications sent over the public Internet. These mechanisms allow Internet users to validate the identity of each party to a communication or transaction, to verify that documents or communications have not been altered or corrupted during transmission, and to protect information from interception during transmission. [ 189 ]

Commenters noted that the current absence of PKI and associated trust models is a significant impediment to widespread use of IPsec. [ 190 ] In this regard, the social and business aspects of establishing identities and trust relationships (e.g., privacy concerns and legal considerations) may be more difficult to resolve than the technical issues. [ 191 ] Until these issues are resolved and the required security infrastructure is created (a process that could take several years), IPv6 is not likely to stimulate any more use of IPsec than IPv4 does today. [ 192 ]

The implications of IPv6 and IPsec deployment for law enforcement are similarly unresolved. The potential widespread use of IPsec to encrypt communications may reduce law enforcement agencies’ ability to monitor criminal activities over the Internet, particularly when IPsec is used in conjunction with IPv6 mobility. [ 193 ] In term of network traceback capabilities, to the extent that deployment of IPv6 enables the assignment of static, globally unique IP addresses to more end-user devices, adoption of IPv6 could in theory enhance the traceability of illegal or harmful communications back to their source. [ 194 ] Nevertheless, IPv6 users could still employ numerous standard and non-standard techniques (e.g., auto-configured addresses, unique local address, NATs) to give themselves a similar degree of anonymity, and thus limit traceability of their communications. [ 195 ] As a result, deployment of IPv6 may not provide clear advantages over IPv4 regarding law enforcement’s tracking of IP addresses.

Furthermore, IPv6 has a “privacy extension” option in its autoconfiguration feature that enables users to randomize their IPv6 addresses or to generate temporary addresses that are independent of the identification label embedded in user devices. [ 196 ] Such addresses are traceable to the ISP or customer demarcation point but are more difficult to trace beyond those points. As a result, it may be challenging for law enforcement authorities to trace a specific node or device as it moves between attachment points or over extended periods of time. [ 197 ] Authorities will have to develop new tools and procedures to address these potential problems. [ 198 ] Overarching these concerns, moreover, are the difficulties determining the origination point of a message that has “hopped” across multiple nodes of the globally-dispersed Internet.

3.3 Security in Transition

Security concerns about either IPv4 or IPv6 are not limited to the capabilities and vulnerabilities inherent in the individual protocols. As noted above, most experts believe that a number of years will be required before IPv6 becomes the dominant Internet protocol. As a result, enterprises assessing the merits of adopting IPv6 must also consider the security issues that will arise during the transition period when both IPv6 and IPv4 are being used.

Although IPv6 supports several mechanisms to facilitate interoperation among IPv4 and IPv6 networks (e.g., dual-stack, tunneling, and translation), each of those transition mechanisms was designed with specific scenarios and requirements in mind. Careful selection and control of their use in actual deployments is required to minimize security breaches. Enterprises that operate dual-stack equipment, for example, will have to address the vulnerabilities of both protocols. Dual-stack nodes may provide global IPv6 connectivity to systems that assume private IPv4 address semantics. Dual-stack operation can raise other security problems if consistent security policies are not created for both IPv6 and IPv4 traffic. If a firewall is not configured to apply the same level of screening to IPv6 packets as for IPv4 packets, the firewall may let IPv6 pass through to dual-stack hosts within the enterprise network, potentially exposing them to attack. [ 199 ]

Enterprises that achieve interoperability via tunneling could also expose themselves to external attacks and threats. IPv6 packets encapsulated in IPv4 tunnels could pass through IPv6 firewalls and launch attacks on IPv6 network host equipment. [ 200 ] Additionally, tunneling mechanisms that communicating parties do not have an active hand in establishing are susceptible to packet forgery and denial of service attacks. [ 201 ]

More work is required to incorporate IPv6-suitable requirements into existing IPv4 security architectures. Because IPv6 is a different protocol that raises different security issues than does IPv4, IPv6 security policies that are simply cut-and-paste translations of existing IPv4 policies will not be adequate. Careful evaluation and tests of security systems (e.g., firewalls, intrusion detection systems (IDS), auditing tools) should also be conducted to determine their capabilities to support both IPv4 and IPv6, as well as specific transition mechanisms. In particular, evaluation of firewall and IDS capabilities for deep packet inspection of tunneled and translated packet formats may be required. Such evaluations should include an analysis of the impact and support of multicast, anycast, and privacy addresses. Security test and audit tools that employ address and port scanning may need to be modified to deal with IPv6 address space issues.

Finally, organizations must develop security plans for dealing with IPv6 traffic, regardless of their decisions and schedules with respect to whether and when to transition to IPv6. IPv6 capabilities already exist in most networks with recent host and router deployments. The fact that IPv6 capabilities are shipped by default in many common host and router operating systems implies that they may be “turned on” at any time, either on purpose, by accident, or for malicious purposes. Some systems may ship IPv6, and/or any one of its transition mechanisms, enabled by default. On some existing platforms, enabling the IPv6 protocol automatically enables various transition mechanisms.

These realities, coupled with the fact that bad actors are rapidly adopting IPv6 and are already using it to initiate attacks and hide malicious processes and communications, suggest that all organizations should develop explicit plans to provide, or prevent, IPv6 communications. Failing to do so will create the real potential that IPv6 will appear and be used on an organization’s networks either by accident or for malicious intent. [ 202 ]

Although none of these transitional security concerns are insuperable, organizations planning to implement IPv6 must be aware of them and develop the necessary security policies to address them. Although IPv6 transition mechanisms have been carefully designed for specific interoperability scenarios, there is still much to be learned about the practical impact of their deployments in large organizations. Additional resources will likely need to be devoted to the development of large-scale test and evaluation capabilities, to the evaluation of the impact of various transition mechanisms on typical security architectures, and to the development and documentation of best practices for new security policies and management mechanisms capable of ensuring the security and stability of networks in transition.

In summary, it is likely that in the short term (i.e., in the first three to five years of significant IPv6 use), the user community will at best see no better security than what can be realized in IPv4-only networks today. During this period, more security holes will probably be found in IPv6 than in IPv4, and IPv4 networks will continue to have at least the same level of security issues as they do currently. In the long term (i.e., 15 to 20 years after first significant IPv6 use), security may improve as a result of increased use of end-to-end security mechanisms. Such a result assumes that significant R&D investment and widespread changes in networking occur, particularly in network security architectures and security management mechanisms.


Previous Section Table of Contents Next Section


FOOTNOTES


[171] NTT/Verio Comments at 13. See also Microsoft Comments at 11 (IPv6 is a “new, more secure protocol” that could help make North America a “Safe Cyber Zone”).

[172] See, e.g., Cisco Comments at 3; GSA Comments at 6; MCI Comments at 4. IPsec is a set of protocols developed by the IETF to support the secure exchange of packets at the IP layer. IPsec has been deployed widely to implement Virtual Private Networks (VPNs). IPsec consists of two optional security headers: Encapsulating Security Payload (ESP), which can provide both encryption and integrity-protection, and Authentication Header (AH), which provides only integrity-protection. The ESP header is more widely used. Both headers support two modes—transport and tunnel. In transport mode using ESP, IPsec protects only the data portion (payload) of each packet but leaves the header untouched. In tunnel mode with ESP, IPsec protects both the payload and the inner header (that of the ultimate recipient), but leaves the outer header untouched. On the receiving side, an IPsec-compliant device decrypts and authenticates each packet. For IPsec to work, the sending and receiving devices must agree on secret (symmetric) keys, which are used to provide encryption and integrity-protection. This is accomplished through a protocol known as Internet Key Exchange (IKE), which also allows the peers to mutually authenticate using digital certificates or other methods, and which negotiates the IPsec protections to be provided and the cryptographic algorithms to be used. See internet.com Webopedia, “IPsec,” at http://www.webopedia.com/TERM/I/IPsec.html (last visited July 12, 2005).

[173] BellSouth Comments at 3.

[174] See Cisco Comments at 3; Public Hearing Transcript, supra note 41, at 77-78 (remarks of Latif Ladid, NAv6TF). In order to fully realize this benefit of the IPv6 address space, care must be taken to avoid overly simplistic interface ID assignments (e.g., sequential, embedded IPv4 addresses). The benefit can be best realized in large networks by employing random privacy addresses or cryptographically generating addresses.

[175] Lawrence A. Gordov, et al., “2004 CSI/FBI Computer Crime and Security Survey” at 10, at http://www.reddshell.com/docs/csi_fbi_2004.pdf (last visited July 12, 2005). Additionally, at least 45 percent of respondents reported spending three percent or more of their IT budget on security, and approximately 53 percent of respondents reported unauthorized use of computer systems within the last 12 months. Id. at 4 (Fig. 5), 8 (Fig. 11).

[176] See, e.g., Alcatel Comments at 4; BellSouth Comments at 3; Cisco Comments at 3, 17; Internet2 Comments at 3; VeriSign Comments at 9. Although most parties believe that increased use of IPsec will improve security, other commenters are less certain. Motorola asserts that IPsec, in its current form, cannot defend against denial of service attacks. Motorola Comments at 4. BellSouth questions whether IPsec can strictly eliminate “spoofing.” BellSouth Comments at 4. More broadly, VeriSign suggests that IPsec may have been rendered irrelevant by the rise of attacks and security threats for which IPsec-based solutions are either unhelpful or counterproductive. VeriSign Comments at 2. Other commenters note that IPsec provides only network-level security and, as a result, may need to be supplemented by other measures. See Alcatel Comments at 3 (need to secure critical subsystems such as neighbor discovery and routing); Electronic Privacy Information Center (EPIC) Comments at 2 (need to secure applications).

[177] See Qwest Communications International Inc. (Qwest) Comments at 4; VeriSign Comments at 2.

[178] See BellSouth Comments at 3; Cisco Comments at 3; Internet2 Comments at 3.

[179] See Internet2 Comments at 3; MCI Comments at 5. Cisco asserts that work-arounds are becoming available that will permit E2E IPsec even across NATs. Cisco Comments at 3.

[180] Some commenters suggest that the removal of NATs to implement IPsec fully may reduce security for some users. See, e.g., Motorola Comments at 3. Other commenters suggest that deployment of IPv6 may be hindered by the absence of IPv6-compatible security “tools” (e.g., firewalls, intrusion detection systems). See Public Meeting Transcript, supra note 41, at 80 (remarks of Stan Barber, NTT/Verio), 147-148 (remarks of Marilyn Kraus, Department of Defense). Development and deployment of such tools, like the continued use of NATs, may interfere with E2E communications using IPsec.

[181] See Cisco Comments at 14; Network Conceptions Comments at 9.

[182] The maximum transmission unit (MTU) is a link layer restriction on the maximum number of bytes of data in a single transmission (i.e., frame, cell, packet, depending on the terminology). See Marc Slemko, “Path MTU Discovery and Filtering ICMP,” at http://alive.znep.com/~marcs/mtu/ (last modified Nov. 12, 1998).

[183] The IETF has taken steps to address some of these concerns through the development of specifications for secure neighbor discovery and cryptographically generated addresses (CGAs). Additional work remains to complete additional specifications (e.g., proxy neighbor discovery) and define best common practices for the secure use of IPv6 auto-configuration capabilities. While IPv4 makes less extensive and required use of auto-configuration technologies, its control protocols (e.g., ARP, ICMP) have many similar vulnerabilities to insider attacks and abuse, but there is little development on the horizon to address the issues in a manner similar to IPv6. See generally Sean Covery and Darrin Miller, “IPv6 and IPv4 Threat Comparison and Best-Practice Evaluation (v1.0)” at 9, 15-16 (appended to Cisco Comments).

[184] See Internet Security Alliance (ISA) Comments at 2.

[185] See, e.g., Public Hearing Transcript, supra note 41, at 59 (remarks of Latif Ladid, NAV6TF), 149-151 (remarks of Preston Marshall, DARPA).

[186] Perimeter-based networks can also extend security protections further into the network (i.e., “defense in depth”). More commonly, there are few explicit security mechanisms at the lowest levels of the protected network (e.g., individual hosts or work stations), instead relying on “local trust” at the subnet, or site level. One obvious ramification of this approach is that at some level, insider threats may well go undetected and undeterred.

[187] See Public Hearing Transcript, supra note 41, at 156-157 (remarks of Preston Marshall, DARPA). The deployment of IPv6 itself may contribute to the obsolescence of traditional perimeter security architectures because many of its capabilities (e.g., end-to-end connectivity, tunneling, encryption), if enabled, make perimeter control of network communications difficult. Basic IPv6 packet construction also complicates inspection of its data by security middleboxes.

[188] See Richard Graveman, “IPv6 Security Top Ten – A Quick Warm-Up Exercise,” at 5 (Nov. 2004), available at http://www.ipv6seminar.com/index.html (on file with author).

[189] See, e.g., Verisign, Inc., “Understanding PKI,” at http://verisign.netscape.com/security/pki/understanding.html (last visited Dec. 21, 2004).

[190] See BellSouth Comments at 3; Cisco Comments at 3; Hain Comments at 4; NAv6TF Comments at 9; NTT/Verio Comments at 15.

[191] See BellSouth Comments at 4.

[192] See id. at 3-4.

[193] See NTT/Verio Comments at 16. This tension mirrors that experienced by users and network administrators. Although implementation of IPsec allows users to protect the secrecy of their communications traffic, IPsec encryption can reduce security for network administrators by denying them the ability to monitor the content of each packet stream for hostile content. See Hain Comments at 4. IPsec-based packet encryption may also defeat network security screening activities by firewalls and intruder detection systems.

[194] See Cisco Comments at 3. Enhanced traceability could make it more difficult to engage in anonymous online conduct. See EPIC Comments at 2-3.

[195] See NTT/Verio Comments at 13-14.

[196] See EPIC Comments at 3.

[197] See Cisco Comments at 4.

[198] See NTT/Verio Comments at 16.

[199] See S. Roy, A. Durand, and J. Paugh, “Issues with Dual Stack IPv6 on by Default,” at 10 (§ 3.3) (July 7, 2004), at http://www.ietf.org/proceedings/04aug/I-D/draft-ietf-v6ops-v6onbydefault-03.txt.

[200] See id. See also United States Computer Emergency Readiness Team, “US-CERT Federal Informational Notice FIN05-095,” at 1 (Apr. 5, 2005), at http://www.us-cert.gov/federal/archive/infoNotices/FIN05-095.html (on file with author). Attackers can also use IPv6-to-IPv4 translation to hide their identity and location and thus defeat defensive traceback efforts. Covery and Miller, supra note 183, at 20 (§ 3.1.9.1).

[201] Covery and Miller, supra note 183, at 19 (§ 3.1.9.1).

[202] See Michael Warfield, “Security Implications of IPv6,” at 29 (Nov. 2004), available at http://www.ipv6seminar.com/index.html (on file with author).


Home | Publications | Newsroom | Policy | International | Spectrum | Grants | Research
National Telecommunications and Information Administration, U.S. Department of Commerce
1401 Constitution Ave., NW Washington, DC 20230