In open network environments, anyone can join a local segment with a minimum of authentication. When the neighbor discovery protocol is employed with IPv6, various types of interception attacks in the form of redirection are possible from a malicious local node. A malevolent router on the local link can redirect all the traffic that is sent through it. Arkko, et al. (2002) call this the "malicious last hop router" and describe it as occurring when an attacker masquerades as a last hop router by multicasting legitimate-looking router advertisements (or unicasting), in response to multicast solicitations (p. 79-80). If a host selects the compromised machine as its default router, the attacker has the opportunity to siphon off traffic from the host. Then the invader can send redirect messages to other hosts, and disappear.
IPv6 equipment can be tricked by address spoofing. A device can cause packets destined for legitimate nodes, both hosts and routers, to be sent to some other link-layer address. It is possible by sending a neighbor solicitation (Narten and Nordmark, 1996) with a spoofed source link-layer address, or sending a neighbor advertisement (Narten and Nordmark, 1996) with a spoofed target link-layer address. If the spoofed link-layer address is valid, and the malicious node continues to respond to unicast neighbor solicitation messages, packets can be redirected.
Another redirect scenario can take advantage of the first-hop router's address. An attacker might spoof the link-local address of the current first-hop router as a source address for a packet, and send a redirect message to a legitimate host. Since the host thinks the message is from the first hop router, it accepts it (Arkko, 2002).
The IPv6 neighbor discovery protocol has the potential to expose hosts to denial-of-service attacks. For one, an attacking node can send a router advertisement message (falsely) claiming some prefix of arbitrary length is on the local link. If a sending host thinks the link-local address prefix is valid, it will never send a packet for that prefix to the router. Instead, "the host will try to perform address resolution by sending neighbor solicitations" (Arkko, et al., 2002, p. 80); but the appeals will never be acknowledged, denying service to the attacked host. In another form of neighbor discovery exploit, an attacking node creates bogus addresses using the subnet prefix of the target network, and then streams packets into it. The last hop router must attempt to resolve the addresses and becomes overwhelmed to the point that a legitimate host is unable to obtain an address.
Similarly, the IPv6 address auto-configuration (Crawford, 1996) mechanism has vulnerabilities. An attacking node could send a bogus router advertisement message by specifying an invalid subnet prefix for address auto-configuration. A host could accept the advertised prefix as valid and construct an address with it--then be effectively disabled as its source subnet address is invalid. Another threat identified by Thomson and Narten, (1998) is the possibility that a node could launch a denial-of-service attack by responding to every duplicate address detection attempt. If the attacker claims the address, then the host will never be able to claim it.
IPv6 has many new features compared to its predecessor, IPv4. The IPSec protocol is built-into IPv6, but as discussed here, IPv6 is still vulnerable to interception and interruption attacks, particularly in its neighbor discovery algorithms. These issues can be mitigated; for example, Arkko, et al, (2002) proposes a cryptographically generated address and address based keys to corroborate a response to the interface of an IPv6 address. IPSec is implemented in IPv6 through the use of extension headers and offers complete, end-to-end encryption of the payload--if network administrators agree to the open network architecture.
As is typical, IPv6 technology is only one element of the solution. The U.S. has been complacent about moving forward with IPv6 implementations and is at risk of having networks outdated by those in Asia (Waddington, and Chang, 2002). It is certain that gradually, the industry will move to IPv6 motivated either by address depletion, insider attacks, or from what Utterback (1994) calls a product discontinuity. That is, some application of distributed or mobile computing on IPv6 so compelling it upsets the status-quo. Maybe the refrigerator that does grocery shopping automatically?
Arkko, J.,Aura, T.,Kempf, J., Mäntylä, V., Nikander, P. & Roe, M. (2002). Securing IPv6 neighbor and router discovery. In Proceedings of the ACM workshop on Wireless security (pp. 77-86), Atlanta, GA: Association for Computing Machinery
Cha, A. E. (2005, June 26). Fixes only temporary for infected Internet. The Washington Post, pp. A1, A15.
Charny, B. (2003, July). U.S. shrugs off world's address shortage. CNET News.com, Retrieved July 3, 2005 from http://news.zdnet.com/2100-3513_22-5055803.html.
Cheswick, W., Bellovin, M., & Rubin, A. (2003). Firewalls and Internet security (2nd ed.). Boston: Addison-Wesley.
Cisco Systems, (2005). Implementing security for IPv6. Cisco Systems, Retrieved July 5, 2005 from http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_configuration_guide_chapter09186a00801d65f4.html
Crawford, M. (1996). A method for the transmission of IPv6 packets over Ethernet networks. Request for Comments: 1972, Network Working Group of the Internet Engineering Task Force, Retrieved July 8, 2005 from http://rfc.net/rfc1972.html
Davies, J. (2003). Understanding IPv6. Redmond, WA: Microsoft Press.
Deering, S., & Hinden, R. (1995). Internet Protocol, Version 6 (IPv6). Request for Comments: 1883, Network Working Group of the Internet Engineering Task Force, Retrieved June 12, 2005 from http://rfc.net/rfc1883.html
Deering, S., & Hinden, R. (1998). Internet Protocol, Version 6 (IPv6). Request for Comments: 2460, Network Working Group of the Internet Engineering Task Force, Retrieved July 4, 2005 from http://rfc.net/rfc2460.html
Egevang, K., & Francis, P. (1994). The IP network address translator (NAT). Request for Comments: 1631, Network Working Group of the Internet Engineering Task Force, Retrieved July 3, 2005 from http://rfc.net/rfc1631.html
Fuller V., Li, T. & Yu, J. (1993). Classless inter-domain routing (CIDR): an address assignment and aggregation strategy. Request for Comments: 1519, Network Working Group, Retrieved July 3, 2005 from http://rfc.net/rfc1519.html
Green, D., & Grillo, B. (2005), The State of IPv6: a Department of Defense perspective. DoD IPv6 Standards Working Group, Retrieved June 12, 2005 from http://ipv6.disa.mil/docs/State-of-IPv6-Final-7Feb05.pdf.
Halabi, B. (1997). Internet routing architectures. Indianapolis, IN: New Riders Publishing.
Hinden, R., (1996, June). IP next generation overview. Source Communications of the ACM, 39(6), 61-71.
Information Sciences Institute (1981). Internet protocol: DARPA Internet program protocol specification. Information Sciences Institute, University of Southern California, Retrieved July 4, 2005 from http://rfc.net/rfc791.html
Narten, T. & Nordmark, E. (1996). Neighbor discovery for IP version 6 (IPv6). Request for Comments: 1970, Network Working Group of the Internet Engineering Task Force, Retrieved July 8, 2005 from http://rfc.net/rfc1970.html
Ning, H. (2004, Jan.). IPv6 test-bed networks and R&D in China. In International Symposium on Applications and the Internet Workshops, SAINT 2004 Workshops, (pp. 105-111), Los Alamitos, CA: IEEE Computer Society.
The Open Model:
The term built-in security sounds like it came from the marketing department, but it is appropriate in comparisons of IPv6 to its predecessor, IPv4--albeit hyperbolic. What is built-in is the requirement for IPv6 hardware to support IPSec. IPSec is a framework of open standards developed by the Internet Engineering Task Force. IPSec functions at a low-level (the network) in the layers between the physical wire and a software application. This means that all of the application data encapsulated in the packet is protected as it travels between transmission stations such as routers--ensuring end-to-end security (Cisco, 2005). However, shown in Figure 3, the use of the extension headers to implement IPSec in the packet is optional. Moreover, IPSec depends on the proper handling of keys to be effective (Pfleeger and Pfleeger, 2003). So while security may be designed into the IPv6 protocol, systemic protection still depends on the carbon life form.
The IPv6 addressing structure has its roots in the Classless Interdomain Routing (CIDR) scheme devised in the 1990's to deal with IP address depletion (Fuller, Li, and Yu, 1993; Halabi, 1997). That format consists of an address prefix, a site identifier, and a host identifier. However, compared to an IPv4 address's familiar dotted decimal display (for example, 192.168.0.1), the length and format of the IPv6 address is intimidating. In an arrangement that only a computer could love, the following is a valid IPv6 address in the commonly used colon hexadecimal form: 21DA:D3::2F3B:2AA:FF:FE28:9C5A (note that all leading zeros have been removed, as is allowed for the depiction). There are a plethora of possibilities for address representation, all based on the following structure:
Of note in the unicast category are link-local and site-local addresses. Both are intended for devices to automatically discover and self-configure an IPv6 address (Crawford, 1996; Hinden, 1996). In IPv6 parlance, this is the neighbor discovery protocol (Narten and Nordmark, 1996).
The vision is that IPv6 will support device mobility, but ephemeral communication requires data exchanges that travel end-to-end instead of by geographically fixed gateways. This means a paradigm-shift from the current IP address-screening perimeter firewall security model illustrated by Figure 5. The gateway security model attempts to separate a trusted network from the rest of the world. Unfortunately, faced with of worms, spyware, and viruses, there are no trusted networks anymore! As Green and Grillo (2005) lament, "without end-to-end security, all communications are at risk of being compromised" (p.6). Pragmatically, as Pfleeger and Pfleeger (2003) note, IPv6 brings an "excellent opportunity" to architect an open network security model more than any obligation to upgrade (p. 440). The next figure illustrates the open network model. But IPv6, with its intrinsic complexities, brings another set of security implications.
The Gateway Model:
Copyright © Snyders.US. All rights reserved.
IPv6 is the protocol of the future...
...but, IPv6 brings new security issues.
John R. Snyder, August, 2005
Home appliances have the technology to connect to the Internet, as do ubiquitous cell phones. But Internet Protocol (IP) address-screening firewalls and local network isolation prevent peer-to-peer discovery and transmission scenarios--by design. The legacy security model attempts to separate a trusted network from the rest of the world. Unfortunately, faced with worms, spyware, and viruses, there is no such thing as a trusted network! One form of relief is the end-to-end security offered by IPv6 (IP version six), and its intrinsic payload encryption. IPv6 has other compelling attributes, for example, an address space that is four-times as large as the previous version. Still, there are security implications. This article will briefly review them, and articulate potential interception and interruption threats in the IPv6 neighbor discovery and auto-configuration routines. A cryptographically generated address and address based keys are proposed to mitigate those issues. It is conclusive that IPv6 is the protocol of the future, and has the capabilities for endpoint-to-endpoint security using the open network model.
Sometime in this century, a home refrigerator will automatically discover the local grocery's Internet-based service and request its weekly order. How will the data travel in this endpoint-to-endpoint scenario? Can private data be secure on a public network? Answering the first question was the easy part--it was the genesis of what is now called the Internet. For many years, the Internet was a single network where communications between devices required no intermediary gateways or routers; it was an end-to-end network (Green and Grillo, 2005). As the system matured, it standardized on Transmission Control Protocol over the Internet Protocol (known as TCP/IP), and a format known as IPv4 (IP version four) (Information Sciences Institute, 1981). IPv4 is a robust, easy-to-implement protocol, evidenced by its omnipresence, but lacks intrinsic security considerations. As a result, gateways, firewalls, and local network isolation have become ubiquitous, but vain attempts to provide data privacy and security.
The inventors of the Internet acknowledge that it was an experiment intended only to prototype networking technologies. The original designers were all friends from academia who built the network without security, "and the darn thing got out of the barn" (Cha, 2005, A15). Indeed, that academic network has become the Internet, the communications backbone of the globe. Thirty-years later, one prominent issue is how to ensure the security of peer-to-peer discovery and transmission scenarios. The lack of security in the Internet's foundation has created a plethora of proprietary workarounds resulting in a quagmire. The industry is "losing the Internet arms race" against the bad guys (Cheswick, Bellovin, & Rubin, 2003, p. xiii). Ironically, the most promising relief for the Internet's security related issues comes from a protocol developed primarily to overcome another problem--IP address depletion.
The addresses available in the 32-bit, IPv4 space are just about gone. Many argue that the addresses ran out a long time ago (Cheswick, et al., 2003; Davies, 2003; Halabi, 1997; Hinden, 1996; Pfleeger and Pfleeger, 2003). IP addresses are numbers allocated on a request by a central administrative body, the Internet Assigned Numbers Authority. While the possible range of IPv4 addresses available (232 or 4, 294,967,296) seems astronomical to the layperson, they have not been allocated efficiently and will be depleted sometime in the first half of this century (Charny, 2003; Egevang and Francis, 1994).
For nascent Asia and Europe, the problem of address scarcity is acute. IPv4 cannot support the plethora of devices that will be connected on these continents (Ning, 2004). Europe and Asia are on the short end of the stick as 70-percent of the IP address space is allocated to North America (Waddington and Chang, 2002); they have been the principal drivers for a transition to a next-generation protocol with a larger address space: IPv6 (IP version six). Japan's DoCoMo, the largest Web-enabled cell phone provider in the world, has already deployed an advanced IPv6 network (Charny, 2003). The U.S. has been complacent, but interest in IPv6 has grown since the Department of Defense began planning and building an IPv6-based network to support the warfighter (Green and Grillo, 2005, p. 1). In parallel, an American consortium of academic institutions has been working on a project called Internet2 that leverages IPv6 (Cha, 2005). These efforts substantiate the premise that IPv6 is the protocol of the future for IP-based networks.
In the game of technical innovation--the last one in wins. That is, the most recent design has the benefit of lessons learned from a predecessor's mistakes, and adjustment for changes in the market. Since IPv4 has been deployed the Internet transformed from free-love flower-power to service-denial steal your identity. Some pessimistic experts are suggesting that the Internet will never meet its potential without a major overhaul (Cha, 2005). Until that happens, new protocols such as IPv6 offer some relief from the status-quo. The vision for IPv6 is that it will restore the Internet's original device-to-device communication model--with security (Hinden, 1996). The following sections offer a brief overview of salient IPv6 features, establishing some background for a discussion of security characteristics.
The significant advantage of IPv6 is the length of its address space. IPv6 has a 128-bit address space compared to IPv4's 32-bits. To put this in perspective, Hinden, (1996) describes a scientific study that found, even allowing for typical allocation inefficiencies, the address space of IPv6 would provide "1,564 addresses for each square meter of the surface of the planet Earth" (p.66). And this was the conservative calculation! In theory, 128 bits will express 3.4 x 1038 possible combinations, but the protocol has been design to allow for hierarchal divisions into several layers of subnets, maintaining efficient and logical address allocation over time. This has an ancillary, but intentional benefit for backbone routing infrastructures: reduction of routing table size.
An increase in address space translates to a respective increase in the overhead of processing. To mitigate this, the IPv6 header format has moved all supplementary elements into what Deering and Hinden (1995) describe as "extension headers" (p. 6). The design compromise allows for a reduction in the most "common-case processing cost of packet handling" (p. 3). It certainly reduces the footprint of the IPv6 packet header, illustrated in the first figure below, compared to the IPv4 header, depicted in the figure that follows. Perhaps IPv6 extension headers will be more warmly received than the analogous IPv4 header option field. Most router administrators intentionally set their equipment to discard any IPv4 packets that contain options.
The inclusion of extension headers in an IPv6 packet also reduces the amount of application data that can be sent in a 1,500 octet Ethernet frame--it's a finite space. To ensure the proper formatting, extension headers must either fulfill a 64-bit (8-byte) boundary or use padding for an integral multiple of 8 bytes.
The following figure illustrates an IPv6 packet using all of the extension headers.
Another aspect introduced in the IPv6 specification is a linked-chain of pointers between extension headers. The Next Header field identifies the extension header immediately following the IPv6 packet header. An IPv6 packet will contain an IPv6 packet header with its payload, and zero, one, or more extension headers; extension headers may also employ a Next Header field, linking to a subsequent extension header. The next figure illustrates how the Next Header field maps the contents of the packet for the router to interpret and process. There are two principal takeaways here: