IPv6 Secure Neighbor Discovery

INTERNET INFRASTRUCTURES Secure Neighbor Discovery: Review, Challenges, Perspectives, and Recommendations Ahmad AlSa’deh and Christoph Meinel | Hasso-Plattner-Institut Secure Neighbor Discovery is designed to countermeasure Neighbor Discovery Protocol threats. he authors discuss Secure Neighbor Discovery implementation and deployment challenges and review proposals to optimize it. T he Neighbor Discovery Protocol (NDP), one of the main protocols in the IPv6 suite, comprises Neighbor Discovery for IPv6 (Request for Comments [RFC] 48611) and IPv6 stateless address autoconiguration (SLAAC).2 It’s used for several critical functionalities, such as discovering nodes on the same link, determining link-layer addresses, detecting duplicate addresses, inding routers, and maintaining reachability information about paths to an active neighbor. In addition, NDP plays a crucial role in mobile IPv6 (MIPv6) networks, eliminating the need for foreign agents and allowing mobile nodes to join new foreign networks. However, NDP is prone to critical atacks.3 It assumes that all nodes on the link trust each other, but this assumption doesn’t hold for several scenarios, such as over a wireless network, in which anyone can join a local link with minimal or no link-layer authentication. Consequently, malicious users could impersonate legitimate nodes by forging NDP messages to generate atacks. As a result, RFC 3971, “Secure Neighbor Discovery (SEND)” became a standard.4 SEND uses cryptographically generated addresses (CGAs),5 a digital signature, and an X.509 certiication to protect NDP. SEND was designed to ensure message integrity, prevent IPv6 address thet and 2 July/August 2012 replay atacks, and provide a mechanism to verify routers’ authority. Although SEND is a promising technique to protect NDP and make IPv6 a safe protocol, its deployment isn’t easy. SEND lacks mature implementations by network device manufacturers and operating system developers. It’s compute intensive and bandwidth consuming. Moreover, SEND itself can be vulnerable to some atacks. We discuss these implementation and deployment challenges and provide some directions and proposals for facilitating SEND deployment in IPv6 networks, especially for devices with limited resources. Neighbor Discovery Protocol NDP is part of the Internet Control Message Protocol for IPv6 (ICMPv6)6 and uses ICMPv6 message format. It was designed in this position of the IP protocol stack for simplicity and to beneit from IP services, such as security and multicasting. NDP messages consist of an ICMPv6 header, Neighbor Discovery (ND) message– speciic data, and ND message options, which provide additional information, such as link-layer addresses, onlink network preixes, on-link maximum transmission unit information, redirection data, mobility information, and router speciication. Copublished by the IEEE Computer and Reliability Societies 1540-7993/12/$31.00 © 2012 IEEE NDP Messages and Functionalities NDP uses the following ive ICMPv6 messages: Abbreviations ■ router solicitation (RS), type 133—the IPv6 host sends RS to discover the default router and learn network information, such as preixes and Domain Name Server (DNS) addresses; ■ router advertisement (A), type 134—the router that receives an RS message sends back an A message (solicited A) and IPv6 routers send As periodically (unsolicited multicast As); ■ neighbor solicitation (NS), type 135—NS resolves the neighbor node’s IPv6 address to its MAC address and veriies that the node is still reachable; ■ neighbor advertisement (NA), type 136—the node that receives an NS message sends back an NA message with its own MAC address; and ■ redirect message (RM), type 137—the router uses RM to inform other nodes of a beter irst-hop toward a destination. ADD ARP BSD CGA CPA CPS DAD DHCPv6 DoS ECC ICMPv6 IID IPsec MITM NA NDP NS RA RM RS SEND SLAAC WinSEND hese messages achieve various functionalities, including router and preix discovery, parameter discovery, address autoconiguration, address resolution, duplicate address detection (DAD), neighbor unreachability detection, next-hop determination, and redirect. Authorization delegation discovery Address Resolution Protocol Berkeley Software Distribution Cryptographically generated address Certiicate path advertisement Certiicate path solicitation Duplicate address detection Dynamic Host Coniguration Protocol for IPv6 Denial of service Elliptic curve cryptography Internet Control Message Protocol for IPv6 Interface identiier IP Security Man in the middle Neighbor advertisement Neighbor Discovery Protocol Neighbor solicitation Router advertisement Redirect message Router solicitation Secure Neighbor Discovery Stateless address autoconiguration Windows Secure Neighbor Discovery NDP Security and Privacy Implications NDP has some basic protection mechanisms based on its scope. It’s a link-local protocol, so the source address must be either unspeciied or a link-local address, and the hop limit must be set to 255. Also, the routers don’t forward link-local addresses. hus, NDP messages can’t be injected into the network infrastructure from beyond directly connected layer-2 access networks. his shield isn’t enough to completely protect IPv6 local networks. Without securing NDP, IPv6 neighbor discovery is vulnerable to spooing, denial-of-service (DoS), replay, redirect, and rogue router atacks. Spooing. In a spooing atack, a malicious node successfully uses another node’s address or identiier. Atackers can use spoofs to leverage man-in-the-middle (MITM) atacks, create DoS atacks, hide their identities, abuse the trust relation between legitimate nodes, and so forth. Address Resolution Protocol (ARP) spooing is a well-known atack in IPv4 networks. Instead of ARP, IPv6 relies on NDP to carry out address resolution in addition to the other services. Without the IPv6 authentication mechanism, atackers can generate crated IPv6 packets with spoofed source addresses and send them across the network. Denial of service. DoS atacks prevent communication www.computer.org/security between the legitimate node and other nodes, using signiicant system resources. For instance, atackers can generate DoS on DAD to prevent a network node from obtaining a network address. DAD ensures that no address collision exists on the same link. A malicious node might hinder the legitimate host from geting a new IPv6 address by responding to every duplicate address detection atempt with a spoofed message saying “I have this address.” hus, victims would ind out that every IPv6 address they try to use is in use by other nodes on the link and won’t be able to conigure an IP address to access the network. Replay. In replay atacks, atackers capture and change messages exchanged between two nodes. NDP messages are prone to replay atacks. For instance, when host 1 wants to communicate with host 2, it sends an NS messages to retrieve host 2’s MAC address. Atackers on the same link can capture the NS message and change it to take over the traic low between host 1 and host 2. Another example is A message replay. Atackers receive the A, change its parameters, and resend this false router information on the link. Redirect. Redirects are a class of atacks in which a 3 INTERNET INFRASTRUCTURES malicious node redirects packets away from its legitimate receiver to another node. In IPv6, routers use RMs to inform nodes of beter irst-hop routers. Atackers can fabricate such a message and take over routing from the legitimate router, acting as an MITM and intercepting all messages between the two nodes. Rogue router. In this type of atack, a malicious node injects rogue information to poison the routing tables, reroute traic, or prevent victims from accessing the desired network. It’s simple for atackers to conigure a rogue router on an unsecured link, but it’s diicult for a node to distinguish between fake and authorized As, especially for a newly connected node, which can’t validate the routers without an IP address to communicate. hus, a malicious node can advertise itself as a router and send a bogus address preix or advertise itself as a last-hop router to act as an MITM and efectively receive, drop, or replay the packets. Such atacks can cause serious problems because they afect all nodes connected to the same segment. Combinations. Atackers can use several of these atack types simultaneously. For instance, spooing and DoS can be used together: atackers can fabricate packets with a fake source IP address to hide their identity, which makes detecting the atack more diicult. RFC 3756, “IPv6 Neighbor Discovery (ND) Trust Models and hreats,” describes and categorizes some possible NDP atacks.3 In addition, the Hacker’s Choice IPv6 (htp://thc.org/thc-ipv6) already implemented a tool set to atack IPv6. NDP Privacy Implications SLAAC could lead to serious privacy issues. Generating the IPv6 interface identiier (IID) on the basis of the MAC address results in a static IID, which remains constant over time and across networks. Consequently, atackers can correlate the captured traic from a speciic IID to a certain device and track the node. Once atackers determine the user’s location and identity, they can target the user for identity thet or related crimes. RFC 4941, “Privacy Extensions for Stateless Address Autoconiguration in IPv6,” introduces a solution by generating global scope addresses from IIDs that change over time.7 Changing IIDs over time makes it more diicult for eavesdroppers and other information collectors. However, RFC 4941 doesn’t protect against IP address spooing atacks. CGAs can obscure the node IID to protect privacy and achieve anonymity. IPsec for Securing NDP Although the original NDP speciication called for the 4 IEEE Security & Privacy use of IP Security (IPsec) to protect NDP messages, it didn’t specify how to use it. IPsec isn’t suitable for securing the NDP autoconiguration process owing to a bootstrapping problem. With the Internet Key Exchange, the nodes must be addressable before IPsec can be used. With IPsec, Internet Key Exchange can automatically perform security associations exchange when a host already has a valid IPv6 address. herefore, the Internet Engineering Task Force developed SEND to countermeasure NDP vulnerabilities. Secure Neighbor Discovery RFC 3971 is a set of NDP enhancements.4 SEND ofers three additional features to NDP: address ownership proof, message protection, and a router authorization mechanism. To achieve these enhancements, SEND comes with four new options (CGA, RSA signature, nonce, and time stamp) and two ICMPv6 messages for identifying the router authorization process. Cryptographically generated address. he CGA option carries the associated CGA parameters so the receiver can validate the proper binding between the public key (used to verify the signature) and the CGA. he CGA is an essential part of SEND, proposed to prevent address stealing. It authenticates IPv6 addresses without requiring third-party or additional security infrastructure. CGAs are IPv6 addresses, in which a one-way hashing of the node’s public key and other auxiliary parameters generates an IID. hus, a node’s IPv6 address is bound to its public key. he receiver can verify this binding by recomputing the hash value and comparing it to the sender’s IPv6 address’s IID. Figure 1 shows the CGA generation algorithm (see RFC 3972 for more details5). CGA generation begins by determining the address owner’s public key and selecting the proper security-level (Sec) value, then continues the hash2 computation loop until inding the inal modiier. he hash2 value is an SHA-1 hash value over the entire CGA Parameters data structure (the public key and Collision Counts are zeros). he address generator tries diferent modiier values until 16 × Sec-letmost-bits of hash 2 equals zero. Once it inds a match, the loop for hash 2 computation terminates. he inal modiier value is saved and used as an input for hash 1 computation. he hash 1 value is a hash of combination of the whole CGA parameter data structure. hen, IID is derived from hash 1. he Sec value is encoded into the IID’s three letmost bits. he seventh and eighth bits from the let of IID are u and g bits. he u bit (universal/ local bit) is set to 1 to indicate universal scope or to 0 to indicate local scope. he g bit is the individual/group bit (see RFC 4291 for more details8). Finally, DAD ensures that no address collisions are in the same subnet. July/August 2012 16*Sec leftmost hash 2 bits must be zero 0 Compute intensive part Cryptographical generated address (CGA) parameters Hash 2 (112 bits) SHA-1 16*Sec = 0 Final modifier (128 bits) Subnet prefix (64 bits) Collision count (8 bits Public key RSA (variable) SHA-1 Increment modifier leftmost 64 bits Modifier (128 bits) 0 (64 bits) Hash 1 Public key 0 (8 bits) RSA(variablre) • Generate/Obtain RSA key pairs • Pick random modifier • Select Sec value • Set collision count to 0 64 bits Subnet prefix 64 bits (59 bits are in use) 0 1 2 ... 6 7 S e c u g CGA Interface ID u=1 g=1 Figure 1. A cryptographically generated address’s generation algorithm. he address owner (generator) generates or obtains an RSA key pair and selects the proper security-level (Sec) value, then continues the hash2 computation loop until inding the inal modiier, which satisies the condition that 16 × Sec-leftmost-bits of hash 2 equals zero. he hash1 value is a hash of combination of the whole CGA parameter data structure. IID is derived from hash1, and the Sec value is encoded into the IID’s three leftmost bits.. A CGA’s main disadvantage is its computational cost. CGA computations can take a long time, especially for high Sec values. In fact, satisfying the hash 2 condition is the most computationally expensive part of the CGA’s generation algorithm. Multiple hashes are computed over the CGA parameter data structure by incrementing the modiier each time (see Figure 1). RSA signature. SEND uses the RSA signature option to authenticate the sender’s identity. Initially, each node must generate or obtain a public/private RSA pair before it can claim an address. he sender signs the outgoing messages with the private key, which is related to the public key and used in CGA’s generation algorithm. his signature prevents atackers from spooing CGA addresses. Nonce. he nonce option uses a random number to ensure that an advertisement is a fresh response to a node’s solicitation. SEND includes a nonce option in the solicitation message and requires advertisements to include a matching option. his prevents a replay atack in solicited messages, such as NS/NA and RS/A, which can be used for two-way communication, but not for one-way communication messages. Time stamp. SEND uses the time stamp option to ensure www.computer.org/security replay protection against unsolicited advertisements, such as periodic As and RMs. Here, the assumption is that all nodes have synchronized clocks, so the node can prevent replay atacks by carrying out a time-stampchecking algorithm. Router authorization. SEND uses authorization delega- tion discovery (ADD) to validate and authorize IPv6 routers to act as default gateways and speciies IPv6 preixes that a router is authorized to announce on its link. ADD relies on an electronic certiicate issued by a trusted third party. Before any node can accept a router as its default, the node must be conigured with a trust anchor that can certify the router via certiicate paths. So, the node requests that the router provide its X.509 certiicate path to a trust anchor, which is preconigured on the node. he router shouldn’t be trusted if it fails to provide the path to the trust anchor. Figure 2 shows a simpliied view of the router authorization mechanism. In addition to these enhancements, SEND ofers two new ICMPv6 messages to identify the router authorization process: certiicate path solicitation (CPS) and certiicate path advertisement (CPA). A host sends a CPS message, ICMPv6 type 148, during the ADD process to request a certiication path between a router and one of the host’s trust anchors. he CPA message, 5 INTERNET INFRASTRUCTURES (Trust anchor) Certificate authority CA0 Certificate authority certificate 1 Host A Router certificate CR 3 Router R 2 Router certificate request CPS: I trust CA0, who are you? CPA: I am R, this is my certificate CR signed by CA0. Verifty CR against CA0. Start using R as default gateway. Figure 2. Router authorization process.9 he host sends a certiicate path solicitation to ask the router to provide a valid certiicate. he router responds with the certiicate path advertisement that contains the certiicate. he host veriies router legitimacy; if it’s valid, the host accepts the router as default router. ICMPv6 type 149, is sent in reply to the CPS message and contains the router certiicate. New rules describe the preferred behavior when a SEND node receives a SEND-supported message. SEND Deployment Challenges SEND faces limitations in several areas, including computation, implementation, deployment, and security, which might prevent CGA and SEND use and leave NDP messages vulnerable to potential atacks. CGA and SEND Security Constraints he CGA mechanism can prevent thet of another node’s address, because atackers must ind a cryptographic hash value (hash 1) collision. However, CGA can’t provide assurance about the real node’s identity, and it isn’t suicient to guarantee that the CGA address is used by the appropriate node. Because CGAs aren’t certiied, atackers can create new valid addresses from their own public keys and start the communication. For more security, a certiicate authority is necessary to validate the keys. However, address owners use the corresponding private keys to assert their ownership and sign NDP messages sent from the address. herefore, atackers can impersonate other node addresses from a valid public key but can’t sign the others’ messages. CGA veriication vulnerabilities. Atackers can per- form DoS atacks against CGA-DAD messages using CGAs or non–cryptographically generated addresses. 6 IEEE Security & Privacy Atackers can use non-CGAs to respond to each CGADAD message, with “I have this address.” If the collision count reaches 2, CGA generation fails. herefore, the CGA algorithm might need to be extended to verify the DAD message responses before the increment collision count. But in this case, all nodes should support CGA or discard the DAD messages that come from non-CGAs as well as give priority to new CGA addresses rather than non-CGA addresses. Atackers can capture ND messages and change the sender’s CGA parameters, so the CGA veriication process at the receiver side will fail. In this scenario, atackers prevent communication between sender and receiver; however, this can happen with other security protocols. For example, if atackers insert a bogus IPsec datagram, the IPsec at the receiver drops the datagram because the integrity check is bogus. herefore, we don’t see this atack as a major drawback of CGAs. Time-memory trade-of attacks. CGAs are vulnerable to global time-memory trade-of atacks. Atackers can generate a table of valid public/private key pairs in the precomputation phase to reduce the time complexity of the atack on the cost of memory. Researchers proposed a more secure version, called CGA++, to resist this type of atack10. In CGA++, the subnet preix is included in the hash 2 calculation, and all the modiier, collision count, and subnet preix values are signed by the private key corresponding to the public key used. his way, time-memory trade-of atacks can’t be applied globally. Atackers could perform a brute-force search for each address preix separately. However, it’s not easy to impersonate a random node in a network owing to the ample storage necessary to carry out this atack. In addition, CGA++ comes with an added cost due to the signature veriications, and it requires much more time than CGA generation for the same Sec value. Attacks on router authorization. DoS atacks can target router authorization mechanisms. his requires performing many operations for generating, verifying, and signing NDP messages, which can afect the routers’ performance. Atackers might target hosts by sending unnecessary certiication paths, forcing hosts to spend useless memory and veriication resources on them. he host’s numerous computations to generate and verify CGAs and the certiicates chain make it vulnerable to DoS atacks. Additional limitations. SEND doesn’t guarantee coni- dentiality or provide protection against address scanning. It doesn’t ofer information about the node’s privileges on the network; if this functionality is necessary, another infrastructure, such as 802.1X, is required. July/August 2012 Table 1. CGA generation time for diferent security-level values. Device speciications Modern PC (AMD64)10 Machine with 2.67-GHz CPU 11 Duo2 (2.53 GHz) workstation 12 Sec = 0 Sec = 1 Sec = 2 Sec = 3 n/a 0.2 s 3.2 hours n/a (theoretically, 24 years) 93.41 ms 401.99 ms 1.65 hours n/a (theoretically, 12 years) 100 µs 60 ms 2000 s CGA Privacy Constraints Owing to CGA’s high computation complexity, it’s likely that once a node generates an acceptable CGA, it will continue to use it at that subnet. Consequently, nodes using CGAs are still susceptible to privacy-related atacks. However, this issue can be solved by seting a lifetime for CGA addresses. If the lifetime passes, a new CGA with a new CGA parameter should be generated. To avoid the long CGA generation time, we don’t recommend choosing a Sec value greater than 1 for current applications. here should be a balance between lifetime and security level. CGA can achieve privacy protection for a mobile node. When a node moves to a new subnet, hash 1 should be recalculated using the new subnet preix. Consequently, new IPv6 addresses with new IIDs will be generated without needing to recalculate hash 2. he process of generating new addresses costs only one hash calculation. he only concern is the possibility of atackers tracking the node on the basis of its public key if it remains ixed. But tracking the node using its public key isn’t easy. Normally, Internet tracking is done using an IP address. Computation Exhaustion and Bandwidth Consumption he average CGA address-generation time depends on Sec bits. However, it’s impossible to tell exactly how much time CGA generation will take when Sec isn’t zero; it could vary signiicantly because the CGA parameter’s modiier ield is generated randomly. heoretically, the computational complexity of hash 2 consumption increases by 216 for each Sec value. By performing 1,000 tests on an Intel Duo2 2.67 GHz CPU, we found that the average CGA generation time is 402 milliseconds for Sec = 1. Our test on an unrepresentative set of ive samples gave an average CGA generation time of 5,923,857 milliseconds (1 hour and 39 minutes). Accordingly, we don’t recommend Sec values higher than 1 because they require a lot of processing power and time using current technologies. If the generation and veriication values exceed 0.5 second, DAD would fail because it expects to send and receive two ND messages in less than 1 second, as RFC 4861 indicates.1 www.computer.org/security n/a (theoretically, more than 30,000 hours) Table 1 presents a summary of CGA generation times reported in several studies. Each study measured CGA on diferent device speciications. Some of these studies consider the whole CGA generation time, and others considered only hash 2 calculation time. Router authorization and certiicate validation can be heavyweight and complicated. Any node trying to verify router authorization must be prepared beforehand with the anchor certiicate. In addition, routers are provisioned with certiicates that prove their identity. Because this relationship can be a long chain of trust, ADD requires an end node to store and retrieve all the certiicates in the certiication path to verify the authorized router. hus, the node requires veriication of the lengthy certiicates chain, and transporting all the certiicates and keys between routers and hosts increases local network traic. Also, the certiication path information transformation requires many CPS/CPA messages, especially if an error occurs on the network and retransmission is required. SEND requires each node to include the public key and other parameters with the message and to aix its signature with every signaling packet it generates, which means that more than 1 Kbyte is added to each packet. his increases communication overhead and consumes network bandwidth and computational resources. Lack of Sophisticated Implementation Most operating systems support NDP but lack support for SEND. Even though some major vendors, such as Cisco and Juniper, have various levels of support for SEND in their routers, no major operating system provides a good level of support. Current SEND implementations for speciic OS distribution, such as Debian Linux, are basically proofs of concept rather than production-ready sotware. Some of these implementations—send-0.2, NDprotector, Easy-SEND, and Windows Secure Neighbor Discovery (WinSEND)— are done in the user space, and others—send-0.3 and ipv6-send-cga—at the kernel level. DoCoMo’s SEND implementation (send-0.2). NT DoCoMo USA Labs implemented the irst open source SEND. Its implementation (send-0.2) works on Free Berkeley Sotware Distribution (FreeBSD), using the Berkeley Packet Filter interface embedded in a netgraph 7 INTERNET INFRASTRUCTURES node for traic between the kernel and the user-space daemon. he user-space daemon handles the SEND options. he communication between the NDP stack in the kernel and the SEND daemon lows through the chain of netgraph nodes rather than passing through normal layer processing. he send-0.2 implementation has some limitations. First, all network traic must traverse through packetiltering hooks, which introduce signiicant processing overhead. Second, send-0.2 depends on a netgraph subsystem, which is available for the FreeBSD operating system family, making it importable for other operating systems. Users need to have good knowledge of irewall rules (ip6tables), because it’s essential for the application’s coniguration. Finally, DoCoMo USA Labs is no longer maintaining the SEND project— source code is no longer available for download and support has been canceled. NDprotector (htp://amnesiak.org/ NDprotector) is another implementation of CGA and SEND for Linux based on Scapy6 and is limited to the Linux platform owing to its dependency on iproute2, ip6table, and netilter queue. Implementation can be divided into initialization and runtime phases. During initialization, CGA addresses are set up and ip6tables rules are deined. hese rules route all NDP messages to speciic netilter queues. NDprotector’s runtime component takes the NDP messages out of these queues and secures the outgoing NDP messages or veriies the incoming ones. NDprotector supports elliptic curve cryptography (ECC) keys in addition to standard RSA keys. It’s implemented in Python and therefore uses a Python wrapper to access netilter. For packet manipulation, NDprotector uses a modiied version of Scapy6 (scapy6send). NDprotector. Easy-SEND. Easy-SEND is another Linux user-space imple- mentation of SEND developed in Java.13 Easy-SEND is an open source project developed for educational purposes. Easy-SEND doesn’t implement router authorization. WinSEND. WinSEND, a user-space implementation developed in Microsot .NET, is the irst SEND implementation for Windows.14 WinSEND works as a service for Windows families with a user interface to set security parameters for the proper network interface card. he user-space implementations have some advantages, such as avoiding crashing the kernel. However, this means emulating the behavior of a kernel structure, which isn’t always possible. herefore, there are some trial implementations to integrate the SEND with NDP code at the kernel. Native SEND kernel API for BSD (send-0.3). his 8 IEEE Security & Privacy implementation aims to overcome the major drawbacks of DoCoMo’s implantation by implementing a new kernel-user space API for SEND and eliminating the use of netgraph and Berkeley Packet Filter.15 Avoiding netgraph reduces overhead, speeds up packet processing, and makes the implementation more portable to other operating systems. send-0.3 uses routing control sockets to exchange messages between the kernel and the user space. It handles the packets that might be afected by SEND rather than processing all packets, and lets the existing kernels handle the other packets. his implementation uses a kernel module that acts as a gateway between the network stack and the userspace interface. Huawei and BUPT (ipv6-send-cga). Huawei and Beijing University of Post and Telecommunications (BUPT) introduced a SEND implementation (www.ohloh. net/p/ipv6-send-cga) in the Linux kernel IPv6 module. he C code is partially built into the real NDP code at the kernel, where direct access to neighboring caches and the routing table is available. However, cryptographic processing remains in the user space. his work is a research prototype under development and lacks interoperability testing. Bugs that could cause the kernel to crash are expected. Proposals to Facilitate SEND Deployments Researchers have proposed ways to optimize and facilitate SEND deployment. In “Signiicantly Improved Performances of the Cryptographically Generated Addresses hanks to ECC and GPGPU,” Tony Cheneau and his colleagues proposed an improved method for generating CGA by using an ECC key instead of a standardized RSA key.16 For the same security level, ECC has shorter keys, which leads to smaller packet sizes. Accordingly, ECC use is more suitable in resource-limited environments. Another potential idea is delegating the expensive computation to a powerful machine. In “A Quick CGA Generation Method,” a key server performs the computation on behalf of the nodes in advance or oline.17 he work in “Coniguring Cryptographically Generated Addresses (CGA) Using DHCPv6” proposed using the Dynamic Host Coniguration Protocol for IPv6 (DHCPv6) server to manage CGA.18 DHCPv6 is extended to propagate the parameters that a host needs to generate CGA. A host might send a request to a DHCPv6 server to compute the CGA for it. However, these approaches return to a centralized model in which the server might be the target of DoS atacks. Other solutions use cryptographic accelerator cards to compute CGA faster or use parallelized algorithms to compute the CGA modiier. “Multicore-Based July/August 2012 Auto-Scaling SEcure Neighbor Discovery for Windows Operating Systems” proposed implementing a parallelized CGA generation algorithm to speed up CGA computation.19 With the parallel approach, the speed-up time increased substantially by increasing the number of cores in the computing device. To avoid unexpected delays in CGA generation, using a time termination condition can be a practical approach.20 For example, on the basis of the CPU speed, the algorithm recommends a proper value for Sec or a time termination condition. he termination condition also depends on the application requirement; for example, MIPv6 needs to inish the address generation within hundreds of milliseconds. “Stopping Time Condition for Practical IPv6 Cryptographically Generated Addresses” proposed a modiied CGA generation algorithm called time-based CGA, which limits the maximum time that the user/application can invest for CGA generation.11 Time-based CGA takes the upper bound of the CGA running time as an input and determines the Sec value as an output of the brute-force computations. his paper also suggested reducing security-level granularity from 16 to 8 to increase the chances of having a beter Sec value within the time limit. Other approaches tried to avoid SEND’s deployment complexity by using alternative protection models. RFC 6105, “IPv6 Router Advertisement Guard,” proposed using ilters at layer 2 to avoid router authorization and certiicate validation complexity.21 It counters the rogue A problem by applying a layer-2 switching device to identify and block invalid As. However, IPv6 A-Guard still can’t prevent IP address thet if deployed alone. A combination of CGA and A-Guard might be a solution to secure the IPv6 network. Other approaches, such as NDPMon (htp:// ndpmon.sourceforge.net)and Amond (htp:// ramond.sourceforge.net) tools, protect the local network by monitoring the NDP messages to detect malicious activity. However, monitoring techniques can’t prevent atacks; moreover, an atack might damage a network before the administrator can respond. Also, determining the atack node isn’t easy, because atackers can use spoofed addresses. W e ofer the following recommendations and comments regarding CGA and SEND deployments: ■ Don’t use CGA with a Sec value greater than 1, because higher values are impractical for most users and applications with current CPU speeds. ■ A parallelizing CGA algorithm can alleviate the required time for CGA generation by speeding up www.computer.org/security ■ ■ ■ ■ CGA computations and investing the available CPU in CGA computation, especially when the device has multiple cores. Generate key pairs on the ly using a CGA generation program to make it easier for the user and to avoid storing the keys in a particular path before starting the application. his way, the keys won’t be vulnerable to thet. Because there’s no guarantee of stopping CGA generation ater a certain time for a Sec value greater than zero, we recommend using time-based CGA to limit the CGA generation time.11 Because of the router authorization mechanism’s complexity it’s necessary to ind an easy certiicate deployment model for SEND. We recommend using a CGA compound with complementary approaches—for example, using CGA with another detection or monitoring mechanism, such as NDPMon or Amond. Using CGA with A-Guard prevents address thet and detects fake As—CGA protects the local link from address thet, and the A-Guard protects the local link from fake As. For a very secure IPv6 local network, we recommend that all nodes use CGA. herefore, we ask the operating systems vendors to implement SEND. Reducing and eliminating the threats and atacks against the IPv6 network by enhancing the CGA security and making it a simple, lightweight, and deployable authentication mechanism is important. Without these security measures, IPv6 network will be let vulnerable to IP spooing–related atacks. References 1. T. Narten et al., “Neighbor Discovery for IP Version 6 (IPv6),” RFC 4861, Sept. 2007; htp://tools.ietf.org/ html/rfc4861. 2. S. homson, T. Narten, and T. Jinmei, “IPv6 Stateless Address Autoconiguration,” RFC 4862, Sept. 2007; htp://tools.ietf.org/html/rfc4862. 3. P. Nikander, J. Kempf, and E. Nordmark, “IPv6 Neighbor Discovery (ND) Trust Models and hreats,” RFC 3756, May 2006; htp://tools.ietf.org/html/rfc3756. 4. J. Arkko et al., “SEcure Neighbor Discovery (SEND),” RFC 3971, Mar. 2005; htp://tools.ietf.org/html/rfc3971. 5. T. Aura, “Cryptographically Generated Addresses (CGA),” RFC 3972, Mar. 2005; htp://tools.ietf.org/ html/rfc3972. 6. A. Conta, S. Deering, and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Speciication,” RFC 4443, Mar. 2006; htp://tools.ietf.org/html/rfc4443. 7. T. Narten, R. Draves, and S. Krishnan, “Privacy Extensions for Stateless Address Autoconiguration in IPv6,” 9 INTERNET INFRASTRUCTURES 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. RFC 4941, Sept. 2007; htp://tools.ietf.org/html/ rfc4941. R. Hinden and S. Deering, “IP Version 6 Addressing Architecture,” RFC 4291, Feb. 2006; htp://tools.ietf. org/html/rfc4291. “IPv6 Secure Neighbor Discovery: Protecting Your IPv6 Layer 2 Access Network,” Cisco Systems, 2009; www. cisco.com/en/US/prod/collateral/iosswrel/ps6537/ ps6553/whitepaper_c11-602135.html. J.W. Bos, O. Özen, and J.-.P Hubaux, “Analysis and Optimization of Cryptographically Generated Addresses,” LNCS 5735, Springer, 2009, pp. 17–32. A. AlSa’deh, H. Raiee, and C. Meinel, “Stopping Time Condition for Practical IPv6 Cryptographically Generated Addresses,” 26th IEEE Int’l Conf. Information Networking (ICOIN 12), IEEE, 2012, pp. 257–262. S. Jiang, “Analysis of Possible DHCPv6 and CGA Interactions,” drat, 12 Mar. 2012; htp://tools.ietf.org/html/ drat-ietf-csi-dhcpv6-cga-ps-09. S. Chiu and E. Gamess, “A Free and Didactic Implementation of the SEND Protocol for IPv6,” Machine Learning and Systems Engineering, vol. 68, S.-I. Ao, B. Rieger, and M.A. Amouzegar, eds. Springer, 2010, pp. 451–463. H. Raiee, A. AlSa’deh, and C. Meinel, “WinSEND: Windows Secure Neighbor Discovery,” 4th Int’l Conf. Security of Information and Networks (SIN 11), ACM, 2011, pp. 243–246. A. Kukek and B.A. Zeeb, “Native Send Kernel API for BSD,” 2010; htp://people.freebsd.org/~anchie/SeND_ AsiaBSDCon_2010.pdf. T. Cheneau, A. Boudguiga, and M. Laurent, “Signiicantly Improved Performances of the Cryptographically Generated Addresses hanks to ECC and GPGPU,” Computers & Security, vol. 29, no. 4, 2010, pp. 419–431. S. Guangxue et al., “A Quick CGA Generation Method,” 2nd Int’l Conf. Future Computer and Communication (ICFCC), IEEE, 2010, pp. V1-769–V1-773. S. Jiang and S. Xia, “Coniguring Cryptographically Generated Addresses (CGA) Using DHCPv6,” 11 Apr. 2012; http://tools.ietf.org/html/draft-ietf-dhc-cga-config -dhcpv6-02. H. Raiee, A. AlSa’deh, and C. Meinel, “Multicore-Based Auto-Scaling SEcure Neighbor Discovery for Windows Operating Systems,” 26th IEEE Int’l Conf. Information Networking (ICOIN 12), IEEE, 2012, pp. 269–274. T. Aura and M. Roe, “Strengthening Short Hash Values,” http://citeseerx.ist.psu.edu/viewdoc/summary?doi =10.1.1.145.7681. E. Levy et al., “IPv6 Router Advertisement Guard,” RFC 6105, Feb. 2011; htp://tools.ietf.org/html/rfc6105. particularly IPv6 security. AlSa’deh has an MS in scientiic computing from Birzeit University in Palestine. Contact him at ahmad.alsadeh@hpi.uni-potsdam.de. Christoph Meinel is a professor and director of the Hasso-Platner-Institut at the University of Potsdam, where he leads the Internet-Technologies and Systems research group. His research interests include security and trust engineering, Web 3.0, and eLearning. Meinel has a PhD computer science from the Humboldt-University in Berlin. Contact him at christoph.meinel@hpi.uni-potsdam.de. Selected CS articles and columns are also available for ree at htp://ComputingNow.computer.org. Ahmad AlSa’deh is a PhD student at the Hasso-Platner- Institut at the University of Potsdam, Germany. His research interests include networking security, 10 IEEE Security & Privacy July/August 2012