Professional Dissertation Writing
Help in Australia

Secure Neighbor Discovery Protocol: Review and Recommendations

Abstract

The Neighbor Discovery protocol (NDP) is a stateless protocol facilitating link local communication in IPv6 networks. The nodes employ IPv6 NDP to locate other hosts/routers on the link, cover resolution of link layer addresses, duplicate address detections and track reachability status about paths to active nodes. However, link local communication using NDP is susceptible to some severe attacks which if neglected leave the network vulnerable. Attackers can spoof source address of legitimate nodes by forging NDP messages and propel attacks like Denial of Service (DoS) and Man-in-the-Middle (MITM) leading to failure of IPv6 host initialization. To avert this, RFC 3971 advocates employing Secure Neighbor Discovery (SEND) to make the process inviolable. SEND fortifies message tempering, prevents IPv6 address theft including protection against replay attacks and enable validation of routers on the link. Although SEND is a robust link layer security mechanism, its practical implementation is reported to have serious shortcomings like cryptographic algorithms which impact computational complexity including bandwidth utilization, as such negate their implementation and adoption. Moreover the protocol itself fails to provide the confidentiality factor in network. SEND also shortfalls of mature unabridged implementations in commercial operating systems and network devices. In this paper, we revisit the protocol implementation and review its deployment challenges. We also discuss some feasible proposals and recommendations for facilitating practical deployment of SEND in IPv6 networks including resource constrained devices like mobile phones.

Keywords: NDP, SEND, IPv6, CGA , DoS, MITM

1.    Introduction

Internet Protocol Next Generation (IPng) or IPv6 which was designed more than a decade ago provides a tangible and pliable replacement choice for shortcomings of IPv4. The main espousing factor for IPv6 was scarcity of IPv4 address space which was perceived in late 90’s (Chen & Liao, 2017). The gigantic address space of IPv6 is 2¹²⁸ as such negating exigency for NAT and thus dispensing end-to-end connectivity. The protocol extends additional attributes for QoS like Traffic class and Flow label. Furthermore, having a simplified header structure aids in efficient routing. IPv6 employs the services of Neighbor Discovery Protocol (NDP) for Link Local communication. The NDP forms the fundamental element of ICMPv6 and operates using its format. IPv6 nodes use Link Local communication to find other nodes/routers on the link, to ascertain their link layer addresses, to detect any duplicate addresses and to maintain reachability status about paths to active nodes (RFC 3971). Additionally Neighbor Discovery protocol also enacts a principal role in Mobile IPv6 (MIPv6) communication thereby permitting the mobile nodes for seamless handoff between various remote networks. The NDP is pivoted on the presumption that network consists of authentic and entrusted nodes, however with inception of public sector wireless networks; any node can affix to the link with trivial authentication and the scenario changes radically. The attackers can effectuate MITM attacks during the address resolution process thereby redirecting legitimate traffic away from the nodes. Likewise, attacks anchored on host initialization and router selection impedes genuine nodes from joining the link (Anbar, Abdullah, Saad, Alomari & Alsaleem, 2016). This is practicable in situations where spoofed Neighbor Advertisement messages successfully poison node’s neighbor cache. Although designers of IPv6 had recommended IPSec as the innate security protocol dispensing security to IPv6 network operations; however, due to incompatibilities, this security extension is not feasible for securing link local communication. RFC 3971 proposes SEND as the security enhancement for mitigating link local vulnerabilities in NDP (AlSa’deh & Meinel, 2012). SEND uses cryptographic procedures to obviate source address spoofing, safeguards message integrity and also ensures authenticity of routers on the link. Although SEND is a durable method of securing NDP, its implementation into operational networks is equally difficult. The CGA component in SEND is computationally heavy on generation time and bandwidth utilization. This lays a significant impact especially on resource constrained devices like mobile phones. Moreover, CGA’s fails to provide confidentiality factor and can itself be susceptible to malicious attacks. As such, an attacker can create a new and valid address using its own public key, and initiate the communication. Also, SEND does not find any commercial deployments in modern operating systems. This paper carries an in-depth review of Neighbor discovery protocol and explicates discussion over its security implications. The paper also discusses various implementations of SEND and their challenges. Lastly, the paper summarizes existing work and feasible recommendations that will facilitate deployment of SEND in current operational networks.

2.   Neighbor Discovery Protocol

IPv6 Neighbor Discovery is a subcomponent of the ICMPv6 protocol using the same protocol number (58) and structure format of the ICMPv6 messages which include an ICMPv6 header, Neighbor Discovery (ND) message related data, and ND message options which provide additional information about the datagram (AlSa’deh et al, 2012). The ICMPv6 message format is shown in figure 1. The NDP was originally defined in RFC 1920 “Neighbor Discovery for IP version 6 (IPv6)” which was further revised and replaced by subsequent RFC 2461 and RFC 4861. The protocol has no equivalent substitute available in IPv4, however replicates in some operations with its predecessor. The NDP replaces IPv4 functionalities such as ARP (Address Resolution Protocol), ICMPv4 Router Discovery and ICMPv4 Redirect, however with no exact equivalent to Neighbor Unreachability Detection (NUD). The protocol also functions as core element in mobile communications facilitating multihop communication which is vital for route discovery and data forwarding.

RFC 4861 defines the goal of Neighbor Discovery as the protocol used by IPv6 nodes to detect other nodes presence on the network link, to resolve nodes link-layer addresses, to search default routers and to maintain reachability status about the path to on-link neighbors.

To achieve the above tasks, NDP operates using five different messages which are a short block of binary data with well defined fields:

Router Solicitation (Message type 133):  A Router Solicitation (RS) message can be sent by any node at any time requesting all routers in the local network to immediately send Router Advertisement (RA) messages. The Router may also direct RA messages periodically, however initially when a node first powers up, it usually multicasts a RS message in order to get the RA information like network prefixes and DNS server addresses instantly, rather than holding back for the next periodic transmission.

Router Advertisement (Message type 134): A Router Advertisement (RA) message shares local subnet domain information to all nodes in a subnet (link). Every IPv6 configured router must send a RA message after fixed intervals (the time interval is chosen randomly to avoid simultaneous transmissions). It is also obligatory for Routers to reply with RA message in response to a Router Solicitation message received from an on link node.

Neighbor Solicitation (Message type 135): Any IPv6 configured node can send a multicast Neighbor Solicitation (NS) message to obtain destination node’s link-layer address, while also advertising its own link-layer address to the destination node. If a node is doing address resolution, NS messages are directed multicast to the Solicited Node Multicast Address of the destination node. If the node is doing Neighbor Unreachability Detection, they are directed Unicast to the destination node’s link-local address.

Neighbor Advertisement (Message type 136): The Neighbor Advertisement (NA) message is always sent in response to a Neighbor Solicitation (NS) message received from an IPv6 capable node. A node can also propagate new information proactively by sending an unsolicited Neighbor Advertisement message.

Redirect Message (Message type 137): The Routers multicast an ICMPv6 redirect message to apprise a node of a better first-hop node on the way to the intended destination. The Redirect message also notifies whether the destination in place is actually a neighbor on the local link.

Additionally, Neighbor Discovery messages include variable size option fields that provide further information about the message. The type field in the header determines what type of option follows which include Prefix information option, Redirected header option, MTU option. Source Link Layer Address Option and Target Link Layer Address Option.

3.     NDP Security Vulnerabilities

Although IPv6 provides intrinsic support to IPSec for an end to end communication over the network, however this protocol does not meet the security benchmark of NDP for link local communication (Supriyantol, Hasbullah, Murugesan & Ramadass, 2013). The link layer security is an indispensable part of the Internet especially wireless networks which can easily be abused by malicious users sitting inside the network. The security firewalls do not scale up to these threats because their main focus lies on quarantining external threats without caring on what can originate from within the local network. Therefore examining and circumventing vulnerabilities within the local network are inherently important. Though being a link local protocol, NDP provides some basic security owing to its scope. In NDP, the source address of the node is either a link local address or an unspecified address. As such limits the packet hop limit to 255.This in turn means that if a packet is injected from outside the network, the hop limit will get incremented and as such will be dropped by border routers. Also routers on the local link don’t forward such addresses. However, its scope cannot act as a shield for other types of attacks. The NDP security becomes critically important because the protocol is rooted on the assumption that all nodes on the link are not malicious (Baig & Adeniye, 2011). However, this conjecture is nullified in scenarios like wireless networks wherein any random node can join a link with bare minimum authentication and initiate the communication. The attacks on Neighbor Discovery Protocol are not a concern if access to the local link is restricted to trusted nodes; but if a trusted node gets compromised, the other nodes become vulnerable to attacks. Thus resulting in following mentioned attacks being leveraged on compromised nodes.

Denial of Service (DoS): These attacks are very substantial as they drain away the system resources. During the Duplicate Address Detection (DAD) process in IPv6 SLAAC, a node may get blocked from generating an address by a malicious user in the link. The malicious user may respond with a fake Neighbor Advertisement (NA) message to every Neighbor Solicitation (NS) message sent by the legitimate user. Repeated fake acknowledgements indicate that address has already been generated, as such may deny the new node from joining the link and the node would thus remain uninitialized.

Spoofing: In this attack, the malicious node successfully launches man-in-the-middle (MITM) or DoS attack by impersonating other nodes network or link local address. As such, network traffic gets redirected without the knowledge of legitimate user. This is usually achieved by spoofing out senders link layer address in a NS message or spoofing target link layer address in a NA message. As long as spoofed address stands valid, the communication continues. This attack is synonymous with ARP poisoning attack as in IPv4.

Parameter Abuse: The periodic messages advertised by the subnet router contain substantial information utilized by end hosts for setting up their network configuration. One such piece of information is the flag value in RA message that informs the hosts whether stateful DHCP server is available for configuration. If the RA message is compromised, the malicious user could modify the parameter values in such a way so as to disrupt the otherwise legitimate traffic. For example; a malicious user can multicast a RA message and announce that network uses stateful DHCP for address configuration which could trigger other nodes to contact a fictitious DHCP server and not assign any usable IP addresses at all.

Rogue Routers: This attack is a result of false claims made by a malicious node to act a default gateway router for the link. Thus legitimate network traffic gets redirected through malicious node. It’s very basic for a malicious user to configure itself to act as default router on the link, however equally difficult, especially for a newly joined node, to make a clear contrast between spoofed and authorized RA messages.

Replay Attack: In this attack a malicious node fraudulently delays or repeats legitimate data transfer between two nodes. An attacker may spy the data transmission between the source and destination and take away the authenticated information such as encrypted keys. Later, it may contact the destination node and use that key to give proof of his identity and authenticity. This attack could be avoided if the communication between sender and destination is cryptographically encrypted.

Neighbor Un-reachability Detection (NUD) failure: Using NUD procedure, the nodes maintain the reachability information about the other nodes and routers. The node sends a NUD-NS message to the destination node to enquire about its reachability status. If the destination is reachable, it will reply with a NA message. However, if the sender node receives no acknowledgement, it may try again before deleting its entry in the neighbor cache. If abused, an attacker may keep replying with spoofed NA’s in response to NUD-NS messages. This may create a wrong mapping in the neighbor cache of the sender.

In practical environment, a malicious node can use various combinations of the above mentioned attacks. As an example, DoS as well as Spoofing can be combined and leveraged together. The problem further aggravates when an attacker fakes his source IP address to hide his identity and thus makes attack detection strenuous.

3.1  NDP Privacy Issues

The auto configuration process in IPv6 SLAAC is vulnerable to certain privacy issues (Narten, Draves, & Krishnan, 2007; Choudhary, 2009). Utilizing layer 2 address for generation of IPv6 Interface Id (IID) using EUI-64 (Extended Unique Identifier) method results in static IID which remains constant over time. The mapping between MAC address and IID remains constant regardless of what network prefix is used. As such, the attackers can correlate the captured network traffic and track down the node. Once the node location is determined, the attackers can simulate different types of attacks. Thus making it susceptible to some privacy attacks. To avoid this problem, RFC 4941, “Privacy Extensions for Stateless Address Auto Configuration,” resolves to use random number generation for IPv6 interface identifiers that change over time. This constant changing of IID’s makes it extremely difficult for attackers to guess the network. But this constant changing too has significant impact on computation resources of a node and is not recommended. Also, the main drawback with RFC 4941 is that it doesn’t talk about the security against IP address spoofing attacks and are unable to provide proof of address ownership by a node.

4.     Secure Neighbor Discovery – A Cryptographic Solution

To counter security issues with Neighbor Discovery Protocol, Secure Neighbor Discovery (SEND) was proposed by authors (Arkko, Kempf, Zill & Nikander, 2005) and was drafted in the RFC 3971. SEND is feasible in those situations where the physical security of the network link is not guaranteed (example such as wireless networks).Since both the routers as well as hosts use NDP for link local communication, it is thus pertinent to secure such communication channel. The SEND protocol provides protection against address impersonation and replay attacks, safeguards message integrity checks and also checks the authorization of routers on local link. SEND has been developed as a robust technique for protecting IPv6 NDP and provides number of security options such as Cryptographically Generated Addresses (CGA’s), RSA Signature, Timestamp and Nonce. Additionally for router authentication (Aura, 2005), it provides two new ICMPv6 messages: certificate Path Solicitation (CPS) and Certificate Path Advertisement (CPA).

4.1    Cryptographically Generated Address (CGA)

The CGA option is integral to the SEND protocol and is used to avoid address impersonation of a node. This authentication mechanism does not require third party installation service or any additional security framework. CGA are generated by applying a one way hash function on some generated public key and additional parameters (Aura, 2005). This method validates that generated IPv6 address is cryptographically linked to the public key it uses. This coupling can thereafter be validated by re-calculation of message hash digest and its comparison with received IPv6 Interface Identifier (IID).CGA’s also find their application in attesting and certifying a node that sent the packet is actually its owner. To prove this claim, the packet is always signed by the sender with its private key. Thereafter, the public key generated digital signature and other additional parameters are transferred with packet to the receiver. The receiver verifies the digital signature and validates that sender of the packet is actual owner of CGA. Figure 2 depicts the CGA generation algorithm. The algorithm starts by generating owner’s public key and selecting an appropriate sec value. Then, two independent hash values (Hash1 and Hash2) are calculated by owner with the help of generated public key and auxiliary parameters. First Hash2 is generated, which is SHA-1 hash of concatenated public key, a randomly chosen 128 bit modifier, a zero value of 8 bit collision count and 64 bit subnet prefix. The owner tries different values of modifier and loop terminates only when 16×sec leftmost bits of Hash2 are equivalent to zero. The most extortionate component of CGA generation is Hash2 computation and this calculation is done only once, when a new node joins the link. The final modifier so obtained serves as an input to the Hash1 calculation. The Hash1 value is obtained by employing SHA-1 function to the concatenation of entire CGA data structure. From Hash-1, 64 leftmost bits form the IID and value of sec is encoded in its three leftmost bits. The 7^th (“u”) and 8^th (“g”) bits from the left are reserved. Finally, node executes duplicate address detection process to check its address uniqueness on the link.

CGA verification as shown in figure 3 is a reverse process which takes two components as input: the generated CGA address and complete CGA data structure. To check the binding between generated CGA address and public key, Hash1 is re-calculated on the basis of received CGA data structure and is compared with the sender’s IID. If verification succeeds, the receiver comprehends that the received public key indeed belongs address owner. Thereafter, receiver can validate signed messages from the sender by using the public key.

4.2      RSA Signature

SEND uses RSA cryptosystem to validate sender’s identity. The selection of public key crypto system is important as it directly impacts performance and computational cost in CGA algorithm.

Before generation of an address, each node must obtain exclusive pair of public/private keys. The private key is used to digitally sign the message sent by the user and this private key must correspond to the public key used in the CGA generation algorithm. Thus digital signature provides security against impersonation of CGA addresses.

4.3     Timestamp

The use of Timestamp option in SEND provides defense against unsolicited advertisements (periodic Router Advertisement and Redirect Message). To avoid replay attacks, all nodes on the link must have their clocks synchronized.

4.4      Nonce

The Nonce option ensures that an advertisement is a fresh response to a solicitation request sent previously by the node. The nonce option uses a random number in solicitation message and expects advertisements to include matching random number. This in turn ensures that replay attacks don’t occur in solicitation messages like NS/NA and RS/RA using bi-directional communication.

4.5     Router authorization

SEND uses a new third party mechanism known as Authorization Delegation Discovery to certify and validate IPv6 routers on the link to act as default gateways. ADD depends on an electronic certificate issued by a trusted authority and uses this certificate to prove its authorization. Before a node agrees to trust a router to act as default router, it must configure itself with a trust anchor that can help to validate the router via a certification path. Thus node expects the router to produce its X.509 certificate which is issued to a router by some third party trusted authority and trust anchor to this third party trusted authority is already configured on the node. A router that does not validate path to the trust anchor is malicious and shouldn’t be trusted. Figure 4 show the basic working of router authorization process. In order to execute the router authorization process, SEND introduces two new ICMPv6 messages: certificate path solicitation (CPS) and certificate path advertisement (CPA). To request a certification path between a router and one of the node’s trust anchors, a node sends a CPS message. In response, the CPA message is sent that contains the router certificate.

5.      SEND Implementation Challenges

Although SEND diminishes most of the vulnerabilities attached with Neighbor Discovery Protocol, however fails to address the confidentiality factor for the link local security (Arkko et al, 2005). SEND faces number of practical limitations with regard to computation cost, deployment, security issues, mature implementations and pitfalls which create bottleneck its implementation and integration into link local security.

5.1    Computational Cost of CGA

CGA’s generation is substantially cost intensive and bandwidth consuming which interdict their implementation in link local networks. The security parameter “sec” ranging from 0 to 7 is the dominant scaling factor in the algorithm and plays a significant impact on the generation time of CGA (Alsadeh et al, 2012).With single increment of sec value, the complexity of CGA generation increases exponentially by a factor of 2¹⁶. This increase is significant, especially in mobile networks where QoS and handover performance cannot be compromised. The mobile nodes are also restrained by limited resources like memory, processing power, battery and bandwidth, which need cost effective utilization. In (Cheneau, Boudguiga & Laurent, 2010), authors found that for mobile devices, only zero value of sec is practical. Their implementation was carried on a Nokia N800 platform with medium level of security provided by 1024 bit RSA keys. Also authors in (Alsadeh et al, 2012) investigated that on modern computing CPU’s, sec value greater than 1 is not practically workable. It is therefore apparent that robustness of CGA and its defense against security leaks depends on the value of sec. However, selecting a higher sec value causes undesirable delay in address generation time while lower value compromises security of the CGA. So there is a tradeoff between choosing robust security or optimal performance.

Another parameter that affects the CGA performance is the public key cryptosystem used.IPv6 CGA uses RSA for the generation of public/private key pair. Although authors in (Cheneau et al,2010) report that using larger RSA key size does not have significant scale effect on CGA generation time, but RSA key generation time increases substantially when key size gets increased. Therefore in totality CGA generation time gets impacted by key size. Using a smaller key size aids in packet size reduction which in turn is favorable in less bandwidth situations.

5.2     DoS on CGA Verification

DoS attacks are very significant against the CGA verification and may leave node uninitialized. Each time, a node executes Duplicate address detection on a temporary address; the attacker responds back with acknowledgment that address is already assigned. After the value of collision count reaches 3, the node automatically gives up further probes and is thus unable to configure the address. However; there is a catch on the attacker’s potential to execute such an attack (Alsadeh et al, 2012). First, attackers should have access to the communication channel and also must be able to capture the packets. Second, the attack should be executed quickly, i.e. attackers reply acknowledgement should come before retrans-timer value expires. CGA’s are also vulnerable to replay attacks whereby a malicious user can capture the communication channel and store back authenticated messages from legitimate user. The malicious node replays this message at some later point of time. The RFC’s recommend that nodes should use timestamp option with CGA toforestall this attack. A malicious node could also flood valid or invalid messages across the network. The intention is waste the computing resources of destination nodes by keeping them busy with CGA verification process.

5.3     Privacy Issues

As CGA generation is compute intensive, a node that generates the address continues to use it while it’s connected to the given network. This leaves the node vulnerable to privacy attacks. Using same CGA address for longer time intervals enables the malicious user to correlate the network traffic between two communicating nodes. This correlation can be generated by examining the payload contents or characteristics of the packets on the communication link. The malicious node could also try to sniff the communication logs of the servers with which the legitimate node has recently communicated. To mitigate this, RFC 4941 suggests that CGA’s should periodically be remodeled so that it become difficult for an attacker to learn about the network (Narten et al, 2007). In (AlSa’deh et al, 2012), the authors also suggest the use of lifetime for CGA addresses. When the lifetime expires, a new CGA with a new CGA parameter should be generated.

5.4     Global Time-Memory Trade-off Attack

In (Bos, Joppe, Onur & Jean-Pierre Hubaux, 2009), the authors have shown that CGA’s are vulnerable to Global Time-Memory Trade-Off attacks. To leverage such a attack, all an attacker needs to do is to spawn a table of public/private key pairs or repository of interface identifiers which are pre-computed from attackers own public keys. The attacker then queries this database repository to find match for any hash collisions. To avert this, researchers in (Bos et al, 2009) propose a more secure version of CGA called as CGA++. In CGA++, hash2 calculation includes subnet prefix in addition to modifier and collision count which is later on signed by the private key of the owner. Inclusion of subnet prefix in hash2 calculation ensures that attack does not have a global scope. As such, attackers search for hash collisions gets restricted to a given subnet.

However Time-Memory Trade-Off Attack is practically infeasible given the huge amount of storage required to execute the attack. The work in (Bos et al, 2009) shows that in order to execute such an attack; the storage required is gigabytes, where min (n_i) indicates the smallest network size. For example, for impersonating a legitimate node in network of size 2¹⁶, an attacker would require 2^33-16 = 2¹⁷ gigabytes or 128 terabytes of storage. This is not practically workable. CGA++ also includes digital signature verification which adds to the computational cost and time than CGA for the same sec value.

5.5     Lack of Implementation Support

Even though majority of operating systems support NDP, but fail to facilitate SEND implementation. Some of the network hardware vendors like Juniper and Cisco provide some sophisticated SEND implementation in their devices, but as long as operating systems don’t support it commercially, it serves no purpose. Current implementations of SEND include Docomo SEND (send-0.2), NDProtector, Easy-SEND, WinSEND, Trust Router and ipv6-send-cga.

Docomo SEND (send-0.2) was developed by Docomo USA labs as the first open source send project that utilizes the operating system user space. The software can be installed on a Linux Kernel 2.6 or FreeBSD 5.4. The Docomo SEND (send-0.2) offers restricted debugging mode where internal state information and operations performed by the application are visible to the users. To generate keys and addresses necessary for X.509 certificates, it offers two tools: a cgatool and ipexttool (Housley, Polk, Ford & Solo, 2002). The SEND implementation operates in two modes: basic and advanced. The basic mode does not provide on-link router discovery operation while as advanced offers router discovery using certification path and their correspondent trust anchor. The Docomo SEND however poses some limitations. The application fails to control address conflicts during IPv6 DAD process due to its integration issues with the kernel. Also the application requires users to have sound knowledge of firewall rules (ip6tables) in order to configure the application. Lastly, as of today, the Docomo Labs are no longer involved with the SEND project and as such the source code is no longer available for public download.

Easy-SEND is a java based free and open source software facilitating SEND implementation (Chiu & Gamess, 2010).The application provides a mechanism for generating and verifying CGA’s in the Linux user-space and is free from any amendments at the kernel level. Easy-SEND uses ip6tables filtering rules and acts as a firewall between the IPv6 stack and NIC (network interface card).For troubleshooting and learning purposes, the application provides a strong event logger facility for recording all the SEND events. Easy-SEND does not facilitate Router Authorization process and is restricted to the creation of a secure framework for IPv6 hosts.

WinSEND is probably the first user space SEND implementation for windows platform developed in Microsoft.NET by researchers at HPI, University of Potsdam (Rafiee, Alsa’deh & Meinel, 2011). WinSEND uses Winpcap library which has direct access to raw packets at Network Interface Card (NIC) and thus efficiently handles NDP packets. Winsock or Winpcap allows the user to directly transfer data between Network Interface Card (NIC) and upper network layers or vice versa.  WinSEND runs as a service for windows platform with simplified interface to select the security variables for some selected NIC.As of now,WinSEND is not available commercially for public use and is restricted to RFC’s with trail implementations.

NDProtector is an application based on Scapy6 that implements CGA & SEND for GNU Linux operating systems. The application is hinged to linux platform owing to its reliance on ip6table, iproute2 and netfilter queue. The application is released under the open source license with python being the architectural programming language for NDProtector. In addition to RSA encryption, the NDProtector also supports elliptic curve cryptography (ECC) encryption keys.

TrustRouter is another application that implements the Secure Neighbor Discovery Protocol. Although it’s mentioned in SEND RFC, TrustRouter doesn’t perform CGA generation nor does it secure neighbor advertisements. As of now, main aim of this application lies on securing router advertisements in IPv6 networks. The TrustRouter application includes operating system specific classes for Linux, Mac OS X, and Windows to extract router advertisements from network stack of the operating system.

ipv6-send-cga is the SEND implementation  on the Linux platform. This project is developed in C language and maintained by Huawei Technologies Corporation and BUPT (Beijing University of Post and Telecommunications).

Table 1 presents summary of different SEND implementations.

Table 1: Summary of different SEND implementations

6.     Existing Work and Recommendations

A lot of research work has been carried out on proposing ways to optimize and secure SEND implementation in IPv6 and mobile networks.

Since the main bottleneck in CGA generation is the computational cost controlled by the scaling factor “sec”, therefore it seems quite rational to impose upper bound on  the CGA generation time. This is because if higher value of sec is used, still algorithm doesn’t guarantee on the termination of brute force search for modifier. The concept was first conceived by authors in (Aura & Roe, 2009) and later practically implemented in (Alsa’deh ,Rafiee & Meinel, 2012). The author’s employed time threshold as an input to CGA algorithm. When threshold expires, the CGA algorithm stops. The time constraint ensures that brute force search terminates after finite period of time. The secure hash value is determined by selecting that hash value having highest number of zeroes in leftmost bits of Hash2.To choose “sec” parameter automatically, the hash extension length can be rounded to the nearby multiple determinant of “8” or “16” depending upon the granularity level selected. In (Aura et al, 2009), the authors suggest that instead of manual configuration, the security parameters should be chosen automatically due to following reasoning. First, since the cost and security grow along exponentially, thus it’s arduous to assign parameter values correctly. If we choose low sec value, the result will be weak hashes. On the contrary, selecting high sec values cause undesirable amount of delay in finding the suitable modifier. Second, it’s unsuitable for a user to understand the details of the algorithm and to update the parameters periodically. Thus it seems rational to determine the extension length automatically to a feasible value.

Although time threshold condition can be applied to CGA, but at the cost of performance degradation and dissipation of CPU resources (Aura et al, 2009).As an example; if time threshold value of 50 seconds is used and if desired modifier is found only after 2 seconds, then it’s illogical to continue the brute force search for the remaining 48 seconds. The rational idea would be to terminate the brute force search prematurely based on some probability condition (Aura et al, 2009). The approach thus demands a benchmark rule for terminating the brute force search.

In CGA, the granularity factor of ‘16’ is used which increases the maximum hash extension length up to ‘112’ bits. This permits the extended hash length to scale up to 59+ (16×7) =171 bits. Keeping current CPU processing in mind, benefits of such extended hashes is questionable. With normal CPU processing, hash length greater than ‘80’ bits is usually considered secure. In (Alsa’deh et al, 2012) authors recommend that using increment factor of “8” could be a more practical option. Since during CGA generation, the possibility of “8” successive zeroes is more than “16” successive zeroes in search for modifier. Using a factor ‘8’ increases maximum hash extension length up to 56 bits. Therefore total hash length would vary between 59 and 115 bits i.e. (59+ (8×7)) which is more practical given the current CPU speeds. Also smaller increment factor is more feasible for mobile devices which have constrained processing power.

Another approach to improve CGA computation has been carried in (Rafiee, Alsa’deh & Meinel, 2012) where the authors have proposed a multicore based SEND implementation for Windows platform to optimize SEND computations. Their approach automatically checks the number of processing cores available in the system and creates an equal number of working threads so that each thread may run and compute Hash2 condition independently. When any of the created threads satisfy CGA Hash2 condition, the other thread stops. The idea is to parallelize CGA computation so that processing time gets reduced.

In (Guangxue, Wendong, Xiangyang, Xirong, Sheng & Xuesong, 2010), authors propose a novel idea of CGA generation technique that may reduce computational complexity considerably. Their mechanism requires that steps [1-3] of CGA computation which is most time consuming be delegated to some powerful machine like central key server. This key server may also determines the sec value independently and perform the Hash2 computation on its own to find suitable modifier. At a later point of time, when CGA parameter request is received from some newly connected node, the key server will transfer the parameters to the intended node. Since most of the computations in CGA generation are moved to the server node, the generation time of CGA is reduced substantially. The only drawback with this method is the question of how to transfer parameters between node and server securely. Also, this approach takes our thinking back to a centralized model in which the server might be the object for DoS attacks.

RFC 3972 mandates the use of RSA cryptosystem for the generation of public/private key pair and signature. The CGA parameters and signature help the receiver to certify the coupling between the CGA address and the public key. In (Cheneau et al, 2010), authors suggest the use of other encryption systems like Elliptic Curve Cryptography (ECC) and Elliptic Curve Digital Signature Algorithm (ECDSA) which is optimal for resource limited networks like sensor nodes, mobiles etc. As ECC key size is smaller in comparison to RSA key size for the same level of security, this helps reduce size of the CGA parameters which in turn minimize bandwidth utilization and thus is feasible for small capacity devices. Use of ECC/ECDSA also reduces significant computation time for signature generation.

The work in (Cheneau et al, 2010 ; Bagnulo & Arkko, 2007) suggests the use of alternate hash function in CGA as SHA-1 is described to have security issues. The transition to more secure hash function like SHA-256 or SHA-512 is greatly discussed. However available literature also suggests the use of HAVAL hash function as an alternative to SHA-1 especially in mobile devices.

In order to prevent Global time-memory trade-off attacks being leveraged on CGA’s, authors in (Bos et al, 2009) argue that subnet prefix should be included in the calculation of hash2.This offers two advantages. First, the attack vector will be restricted to a given subnet and cannot be applied globally. For other subnet, separate database of attack vector will be needed. Second, the node privacy is sustained, because for every new subnet, user generates new CGA. However subnet prefix inclusion carries some efficiency loss, particularly in mobile environment where a user changes its subnet frequently. To generate new CGA every time may not be a feasible option in mobile devices having limited resources. To not include subnet prefix in the calculation of CGA was the design consideration of Aura (Aura, 2005) for the sake of efficiency, but given the current exponential increase in the computational power of mobile devices, the option seems to be feasible for near future.

To counter Rogue Router advertisement in SEND, RFC 6105 proposes IPv6 Router Advertisement Guard to be installed at layer 2 switches. The switching device would carry out filtering to examine and block invalid RA’s based on certain parameters such as layer 2 address of sender, port number and IP address. However RA was reported as vulnerable to various malicious attacks (Gont, 2011).The attack could be launched by using IPv6 extension headers as well as fragmenting the data packets. The use of CGA along with RA guard is highly recommended (Alsadeh et al, 2012).

Some other approaches in (Barbhuiya, Biswas & Nandi, 2011; Barbhuiya, Bansal, Kumar, Biswas & Nandi ,2013) to secure local networks involve examining the NDP messages and detecting any malicious activity. However monitoring and detection don’t aid in preventing attacks especially when attackers use fake addresses.

Table 2 provides summary of Recommendations based on existing work and surplus literature available.

Table 2: Summary of Recommendations based on existing work

7.    Other Security Mechanisms

Link Local communication and its security is a significant notion in IPv6 that has drawn attention from the global network researchers and designers. In order to ensure its security, traditional measures involve the use of firewall to filter suspicious incoming packets.

In (Khoussainov & Patel, 2000), the authors pinpoint someconclusive flaws of using firewall security on the link local communication. First, firewalls fail to identify those unknown vulnerabilities which are not configured in their rule database. Second, firewalls cannot protect from attacks that are generated from within the network. Attacks originating from within the network are also called non-blind attack (Supriyantol et al, 2013).

The most commonly used security option for securing IP based communication is IPSec, but its practical deployment in link local communication is arduous. IPSec is a combination of protocols providing security at the network layer. The protocol forms the elementary security feature in both IPv4 and IPv6 networks dispensing data authentication, integrity and confidentiality. Although the original RFC’s mandates IPSec service utilization for securing NDP messages, however it does not describe how to use it. IPSec’s coupling with NDP has some potential issues like bootstrapping (Barbhuiya et al, 2013). For proper working of Internet Key Exchange (IKE), working IP stack must be present i.e.  nodes should be addressable and must have a valid IPv6 address. Also manual security association configuration is a cumbersome process in NDP given the bulk size of messages used in NDP. Hence using IPSec for securing NDP is not recommended. In order to oversee vulnerabilities in link local communication not addressed by IPSec, authors in (Arkko et al, 2005; Arkko, Aura, Kempf, Mäntylä, Nikander & Roe, 2002) proposed Secure Neighbor Discovery (SEND) to fortify NDP communication against attackers. However based on the review carried by authors in (AlSa’deh et al, 2012),  and further discussion above, SEND deployment is complex and also does not find any commercial implementation in today’s operating systems. Although authors in (Alsa’deh, Meinel, Westphal, Gawron & Groneberg,2013), have proposed an approach to enable CGA’s integration with IPSec but the idea is only a proof-of-concept, as such implementation of this system in heterogeneous network environments along with security implications involved needs to be discussed and analyzed.

In link local communication, source address spoofing is one of the common ways attackers use to carry malicious activities. Therefore, additional procedures are required for IP source address validation of a given data packet. In (Wu, Ren & Li, 2007) researchers propose Source Address Validation (SAVA) to authenticate the source address. SAVA can be deployed in inter Autonomous System (AS), intra AS, and also local network. The verification prevents spoofing from another node having same IPv6 prefix. This can be achieved by establishing a relationship between a switch port and valid source address or between source address, link layer address and switch port.

In (Wu, Bi, Bagnulo, Baker & Vogt,2011), IETF proposed an improvement over SAVA called Source Address Validation Improvement (SAVI).SAVI mechanism works on the basis of trust created among IPv6 nodes and creates a binding between source address, link layer address and switch port also known as anchor information. SAVI also achieves filtering of packets by forwarding the packets that match filter rules and discarding the other packets that don’t match the filtering rules. The aim of developing Source Address Validation Improvement (SAVI) was to supplement ingress filtering.

Using SAVI, nodes attached to same communication channel are intercepted from spoofing each other’s address. For integration in different heterogeneous networks, SAVI was developed to be flexible and protractile.

Similarly, in (Kukec, Bagnulo & Mikuc 2009; Lin & Bi,2009), several combinations of SAVI and SEND have been proposed to avert the source address spoofing problem in link local communication using NDP.

Table 3 summarizes the link layer security mechanisms.

Table 3:  Summary of Security Mechanisms

8.    Conclusion

IPv6 Link Layer Security is a convoluted problem today that demands time and large scale investment of resources. Link Local Communication using NDP is one of the novel features introduced in IPv6 design. Although the protocol acted as panacea for the limitations of its earlier predecessor IPv4, but it also introduced some serious issues that require substantial solutions. In this paper, in-depth review of the Neighbor Discovery protocol and an analysis of its security implications have been carried out. The paper revisited discussion on the SEND protocol highlighting some of its constraints and summarizing its various implementations. The paper also summarized existing work including some feasible recommendations that will facilitate deployment of SEND. The lack of confidentiality in NDP messages and statelessness suffice as a launch pad for various attacks. Removing and mitigating these vulnerabilities against NDP by improving SEND makes it reliable and robust authentication mechanism for link local communication.

References

1. Chen, Y. S., & Liao, S. Y. (2017). A Framework for Supporting Application Level Interoperability between IPv4 and IPv6. In Advances in Intelligent Information Hiding and Multimedia Signal Processing: Proceeding of the Twelfth International Conference on Intelligent Information Hiding and Multimedia Signal Processing, Nov., 21-23, 2016, Kaohsiung, Taiwan, Volume 1 (pp. 271-278). Springer International Publishing.
2. Anbar, M., Abdullah, R., Saad, R. M., Alomari, E., & Alsaleem, S. (2016). Review of Security Vulnerabilities in the IPv6 Neighbor Discovery Protocol. In Information Science and Applications (ICISA) 2016 (pp. 603-612). Springer Singapore.
3. Alsa’deh, A., Rafiee, H., & Meinel, C. (2012, February). Stopping time condition for practical IPv6 cryptographically generated addresses. In Information Networking (ICOIN), 2012 International Conference on (pp. 257-262). IEEE
4. Rafiee, H., Alsa’deh, A., & Meinel, C. (2011, November). Winsend: Windows secure neighbor discovery. In  Proceedings of the 4th international conference on Security of information and networks (pp. 243-246). ACM.
5. Cheneau, T., Boudguiga, A., & Laurent, M. (2010). Significantly improved performances of the cryptographically generated addresses thanks to ECC and GPGPU. computers & security, 29(4), 419-431.
6. Barbhuiya, F. A., Bansal, G., Kumar, N., Biswas, S., & Nandi, S. (2013). Detection of neighbor discovery protocol based attacks in IPv6 network. Networking Science, 2(3-4), 91-113.
7. Housley, R., Polk, W., Ford, W., & Solo, D. (2002). Internet X. 509 public key infrastructure certificate and certificate revocation list (CRL) profile (No. RFC 3280).
8. Arkko, J., Kempf, J., Zill, B., & Nikander, P. (2005). Secure neighbor discovery (SEND) (No. RFC 3971).
9. Chiu, S., & Gamess, E. (2010). A free and didactic implementation of the SEND protocol for IPv6. In Machine Learning and Systems Engineering (pp. 451-463). Springer Netherlands.
10. Aura, T., & Roe, M. (2009). Strengthening short hash values. See http://research. microsoft. com/en-us/um/people/tuomaura/misc/aura-roe-submission.pdf.
11. Bagnulo, M., & Arkko, J. (2007). Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) (No. RFC 4982).
12. Bos, J. W., Özen, O., & Hubaux, J. P. (2009, September). Analysis and optimization of cryptographically generated addresses. In International Conference on Information Security (pp. 17-32). Springer Berlin Heidelberg.
13. Khoussainov, R., & Patel, A. (2000). LAN security: problems and solutions for Ethernet networks. Computer Standards & Interfaces, 22(3), 191-202.
14. Supriyanto, Hasbullah, I. H., Murugesan, R. K., & Ramadass, S. (2013). Survey of internet protocol version 6 link local communication security vulnerability and mitigation methods. IETE Technical Review, 30(1), 64-71.
15. Arkko, J., Aura, T., Kempf, J., Mäntylä, V. M., Nikander, P., & Roe, M. (2002, September). Securing IPv6 neighbor and router discovery. In Proceedings of the 1st ACM workshop on Wireless security (pp. 77-86). ACM.
16. AlSa’deh, A., & Meinel, C. (2012). Secure neighbor discovery: Review, challenges, perspectives, and recommendations. IEEE Security & Privacy, 10(4), 26-34.
17. Wu, J., Ren, G., & Li, X. (2007, October). Source address validation: Architecture and protocol design. In Network Protocols, 2007. ICNP 2007. IEEE International Conference on (pp. 276-283). IEEE.
18. Bi, J., Wu, J., Li, X., & Cheng, X. (2008, April). An IPv6 Test-Bed Implementation for a Future Source Address Validation Architecture. In Next Generation Internet Networks, 2008. NGI 2008 (pp. 108-114). IEEE.
19. Yan, Z., Deng, G., & Wu, J. (2011, June). SAVI-based IPv6 source address validation implementation of the access network. In Computer Science and Service System (CSSS), 2011 International Conference on (pp. 2530-2533). IEEE.
20. Wu, J., Bi, J., Bagnulo, M., Baker, F., & Vogt, C. (2011). Source Address Validation Improvement Framework. draft-ietf-savi-framework-06. IETF Internet-Draft.
21. Kukec, A., Bagnulo, M., & Mikuc, M. (2009, June). SEND-based source address validation for IPv6. In Telecommunications, 2009. ConTEL 2009. 10th International Conference on (pp. 199-204). IEEE.
22. Lin, P., & Bi, J. (2009, July). A novel send based source address validation mechanism (SAVM-SEND). In Applications and the Internet, 2009. SAINT’09. Ninth Annual International Symposium on (pp. 149-152). IEEE.
23. Rafiee, H., Alsa’deh, A., & Meinel, C. (2012, February). Multicore-based auto-scaling secure neighbor discovery for windows operating systems. In Information Networking (ICOIN), 2012 International Conference on (pp. 269-274). IEEE.
24. Guangxue, S., Wendong, W., Xiangyang, G., Xirong, Q., Sheng, J., & Xuesong, G. (2010, May). A quick CGA generation method. In Future Computer and Communication (ICFCC), 2010 2nd International Conference on (Vol. 1, pp. V1-769). IEEE.
25. Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., & Mohacsi, J. (2011). IPv6 router advertisement guard (No. RFC 6105).
26. Gont, F. (2011). IPv6 router advertisement guard (ra-guard) evasion.
27. Barbhuiya, F. A., Biswas, S., & Nandi, S. (2011, November). Detection of neighbor solicitation and advertisement spoofing in IPv6 neighbor discovery protocol. In Proceedings of the 4th international conference on Security of information and networks (pp. 111-118). ACM.
28. Alsa’deh, A., Meinel, C., Westphal, F., Gawron, M., & Groneberg, B. (2013, November). CGA integration into IPsec/IKEv2 authentication. In Proceedings of the 6th International Conference on Security of Information and Networks(pp. 326-330). ACM.
29. AlSa’deh, A., Rafiee, H., & Meinel, C. (2013). SEcure Neighbor Discovery: A Cryptographic Solution for Securing IPv6 Local Link Operations. In Theory and Practice of Cryptography Solutions for Secure Information Systems (pp. 178-198). IGI Global.
30. Baig, Z. A., & Adeniye, S. C. (2011, December). A trust-based mechanism for protecting IPv6 networks against stateless address auto-configuration attacks. In Networks (ICON), 2011 17th IEEE International Conference on(pp. 171-176). IEEE.
31. Narten, T., Draves, R., & Krishnan, S. (2007). Privacy extensions for stateless address autoconfiguration in IPv6.
32. Choudhary, A. R. (2009, November). In-depth analysis of IPv6 security posture. In Collaborative Computing: Networking, Applications and Worksharing, 2009. CollaborateCom 2009. 5th International Conference on(pp. 1-7). IEEE.
33. Aura, T. (2005). Cryptographically generated addresses (CGA).
34. AlSa’deh, A., Cheng, F., & Meinel, C. (2011, December). CS-CGA: Compact and more secure CGA. In Networks (ICON), 2011 17th IEEE International Conference on (pp. 299-304). IEEE.