Security Mechanism for IPv6 Router Discovery based ...

Proceeding of the 2013 IEEE International Conference on RFID Technologies and Applications, 4 – 5 September, Johor Bahru, Malaysia

Security Mechanism for IPv6 Router Discovery based on Distributed Trust Management 1,3

Supriyanto, 2Raja Kumar Murugesan,3Azlan Osman and 3Sureswaran Ramadass 1

Dept.of Electrical Engineering, Universitas Sultan Ageng Tirtayasa, Indonesia 2 School of Computing and IT, Taylor’s University, Malaysia 3 National Advanced IPv6 Centre, UniversitiSains Malaysia, Malaysia [email protected], [email protected], [email protected], [email protected]

Abstract—IPv6 requires the support of other protocols such as neighbor discovery and ICMPv6 for its functioning. Neighbor discovery includes router discovery, and redirect. Router discovery is used by an IPv6 host to discover the presence of routers and network parameters. It enables the host to configure list of default gateway, list of address prefixes, Maximum Transmission Unit (MTU) in the link and hop limit setting for sending IPv6 packets. Failure to complete the initialization process will cause the network to have no IPv6 addresses, disabling it from sending any IPv6 packets and communication with others. As the original router discovery standard does not specify a security mechanism for it, they are vulnerable for any exploitation. This paper investigates the current router discovery mitigation methods such as ADD, SAVI, TRDP and RA Guard. The investigation would further increase the understanding on their weakness so that it could be used to formalize a new security method for router discovery. We propose a new security mechanism based on distributed trust management. Theoretical analysis of this mechanism shows a decrease in bandwidth consumption compared to ADD on Secure Neighbor Discovery mechanism up to 3.15 times lesser. Keywords: Neighbor Discovery, Router Discovery, IPv6, Trust, Security

I. INTRODUCTION Internet Protocol version 6 (IPv6) was intended to address the current IPv4 address depletion problem. The new protocol provides many advantages such as simple header format enabling faster IP packet transmission and address auto configuration that enables an IPv6 host to generate its IP addresses. Address auto configuration processes is done by a network layer protocol called neighbor discovery protocol (NDP) [1]. NDP works on top of five informational forms of ICMPv6 messages. Therefore, the format of NDP is following the ICMP format with several options to provide specific information on both router discovery as well as neighbor discovery. Router discovery (RD) is a process that discovers the presence of a router in the link and provides network

parameters for the link including prefix, MTU and hop limit value. In a link local network, a router is a neighbor of an IPv6 host that also acts as a default gateway. RD in IPv6 is very important to initialize a new IPv6 host in order to be ready for communication. From the router discovery process, a new host receives information on prefix used in the link that would be used to generate IPv6 address, network parameters such as hop limit and MTU that could be used for transmitting IPv6 packet and information about default router in the link. This host initialization leads the host to be ready to communicate locally and globally. The standard on NDP for IPv6, RFC 4861, explains about securing the neighbor discovery messages using Secure Neighbor Discovery (SEND)[2] and IPsec [3]. However, there is no explanation on how to use the two security protocols on IPv6 link local communication including router discovery. The authors of [2] explain how SEND prevent the neighbor discovery threat and vulnerability listed in [4]. However, several studies on implementing SEND on protecting RD such as [5] also faced some problems on SEND such as computation exhaustion, bandwidth consumption as well as no confidentiality. These studies show that the implementation of SEND is very limited. Therefore, authorization delegation discovery (ADD) that is part of SEND on protecting RD is also limited in terms of implementation. As a result, RD in IPv6 is still vulnerable. This paper investigates some current security mechanisms on IPv6 link local communication especially RD that covers SEND, Router Advertisement Guard [6], Source Address Validation Improvement (SAVI) [7] and Trusted Router Discovery Protocol [8]. The rest of this paper is as follows: Section 2 gives an overview of RD, Section 3 gives the related works on securing RD processes, Section 4 proposes a new security mechanism to prevent RD process from malicious activity based on trust based management. Theoretical analysis of the new mechanism is provided in Section 5. Section 6 concludes this work.


II. OVERVIEW OF ROUTER DISCOVERY IN IPV6 One of the important information required by a host on IPv6 communication is the address of at least one operational router on the same subnet. This could be used later to define the first hop routing, set packet hop limit as well as default gateway. The processes to get this information are called router discovery (RD) that enables the host to send packet both the internal network and outside the local network. In IPv4, RD is done by ICMP Router Discovery Protocol [9], a specific protocol that regulates how a host discovers a neighboring router. However, IPv6 removed this protocol and integrates RD function in neighbor discovery protocol. RD in IPv6 uses a pair of important ICMPv6 messages called Router Solicitation (RS) and Router Advertisement (RA). Both RS and RA follow the format of ICMPv6 messages with options extension. Figure 1 and Figure 2 is the format of RS and RA on IPv6 RD [1]. There are five options defined in RFC 4861 which are source link layer address, target link layer address, prefix information, redirected header and MTU. However, neighbor discovery messages could use zero, one or more options. The standard has determined RS message could only use source link layer address option to inform about host link layer address. While RA message could use more than one option that includes source link layer address, prefix information and MTU. Type = 134

Code = 0

Checksum Reserved

Options

Figure 1. Router Solicitation Message Format

RS message is sent by a host to request appropriate information to on link router as well as inform its link layer address. In the other hand, RA message is sent by on link routers for respond to the RS message received or periodically sent to inform its presence to all nodes in the same link. Flags on RA message are used to inform the host address configuration type implemented in the network. The router discovery messages are used to conduct host to router communication that include discovering router in the subnet, discovering prefix used in the link, both Internet and link parameters as well as address auto configuration. As an IPv6 packet, RS and RA messages are encapsulated by IPv6 main header. In order to know the IPv6 packet is from a sender in the same link, hop limit value of packet containing RS and RA message is 255. There are two types of source IPv6 address on RS message, if the IPv6 host does not know all about IP address, it would use unspecified address (::) as its source address to multicast RS message to all routers in the link (FF02::2). In case the

host has a known IP address, it uses the address as its source address. Routers immediately reply the RS message by sending unicast RA message to the host with some information about itself (lifetime, reachable time, retransmission time), hop limit in the link and three options including its source link layer address, MTU as well as prefix information options. Routers also send a routine advertisement to all on link host to inform both the router and network status. Type = 134

Code = 0

Checksum

Cur Hop Limit

Flags

Router Lifetime

Reachable Time Retrans Timer

M

O

Reserved

Figure 2. Router Advertisement Message Format

III. RELATED WORKS ON SECURING ROUTER DISCOVERY RFC 4861 explains mitigation methods to protect the messages by setting the IPv6 hop limit value to 255 that indicates the packet is from a first hop or from the same subnet. Only this kind of IPv6 solicitation or advertisement is considered as valid. The receiver would discard whatever packet from outside the local network by verifying the hop limit value. However, this mitigation technique is not enough considering many other threats and vulnerabilities on RD as listed in RFC 3756 [4]. To increase the security mechanism on RD, IETF and other researchers proposed some security mechanism. This section investigates the current mechanism on mitigating RD. 3.1 Authorization Delegation Discovery (ADD) It is a part of SEND protocol on securing RD processes. SEND mandated to use a certificate format and introduced two new ICMPv6 messages, certificate path solicitation (CPS) and certificate path advertisement (CPA) to do this. Standard on SEND [2] described the importance of authorization for router to act as default router as it is very easy for attacker to send a rogue RA. ADD is used by host to verify a router using a trust anchor. This could be done by sending CPS message to request a certification path between the router and host’s trust anchor. The router then replies by sending CPA message. In the time a host still has a valid certification path it does not need to send CPS as there is trusted router act as default router. Otherwise, the router should not be trusted if it cannot provide a certification path to the trust anchor. In order to get trust certificate from host’s trust anchor, it may form a


certification chain with several intermediate routers (CAn-1) in the certification path until the trust anchor. This mechanism involves a host to validate each certificate chain by verifying the whole certification path. This could force the host to give more effort on calculation of the certification chain. The calculation is costly for an end-host especially in wireless network. In addition, transmission of all the certificates between the end host and the local router in wireless network tends to produce packet loss[8]. This is a form of centralized trust management that is dependent on the certificate authority (CA). When the CA encounters a problem the entire certification process will fail [10]. This router authorization requires many operations for generating, verifying and signing the certificates that also can affect router performance that could be targeted by DoS attack[5]. In addition, the neighbor discovery processes on SEND uses CGA option and RSA option for all NDP messages [2]. As described in RFC 3971, the two options contain cryptography mechanism that requires more processing time. In terms of RD mechanism, the RS and RA message also have to carry the two options. This make the RD operation is very heavy and computationally expensive [2]. 3.2 Source Address Validation Improvement (SAVI) SAVI was proposed to verify the sender address by binding the IP address, port address and MAC address [11]. Validation includes three meaning which are authorized, unique and traceable. An address has to be unique both locally and globally and it has to be traceable, meaning the source host location could be verified. In the case of local network, the validation is done by snooping link local communication processes. It will capture trusted information of an IPv6 host such as port, MAC address and IP address. Based on the information, SAVI protocol creates a dynamic binding between the three address types [7]. The SAVI protocol works as a filtering device, packet containing matching information would be forwarded otherwise, discarded. SAVI is a filtering based security mechanism that prevents spoofed IPv6 packets from local scope network. However, SAVI does not cover other vulnerabilities on IPv6 local network such as flooding attack and DoS attack. In addition it could be exposed to new attack vector when the binding anchor is spoofable [12]. Operation of SAVI faces some difficulty on multiple addresses interface as well as dynamically address scheme [13]. Therefore, the Internet draft proposing SAVI framework has not been approved as standard by IETF[14]. 3.3 Trust Router Discovery Protocol (TRDP) TRDP [8]introduced two pairs of ICMPv6 messages required by both host and router. The first pair is Trusted Router Passport Solicitation (TRPS) and Trusted Router Passport Advertisement (TRPA). TRPS is sent by host with a TA (trust anchor) and nonce to assure that a particular

TRPA is linked to the TRPS that triggered it. Router will respond by sending an encrypted TRPA. The host could take the sender of TRPA as its default access router. The second message pair is Trusted Router-to-Router Passport Solicitation (TR2PS) and Trusted Router-to-Router Passport Advertisement (TR2PA). These messages are used by access router and intermediate routers on the certification path to get a passport from trust anchor. The routers send TR2PS to the trust anchor include nonce and TA copied from TRPS. After receiving the TR2PS, the trust anchor generates a passport to be sent to access router as a content of TR2PA. This mechanism was intended to reduce the end host on processing certificate chain on ADD by introducing the intermediate router. However, the mechanism is slightly complicated due to the addition of ICMPv6 messages as well as more routers required. Since, there still requires a centralized certification authority and certificate signing, this mechanism is also costly. Besides, it needs the intermediate routers. 3.4 Router Advertisement Guard (RA Guard) RA Guard[6]is installed on nodes in the middle such as layer 2 switch to do filtering based on certain criteria that include link layer address of the sender, port on which the frame was received, IP source address and prefix list. The RA Guard has to examine an incoming RA message and decide whether to forward or block the message. The mechanism could be stateless meaning the filtering is done based on the frame information compared to the layer 2 configuration. It also could be stateful, in which the RA Guard learns dynamically on legitimate RA sender and store the information for the following RAs. The RA Guard was reported vulnerable to various attack vectors in [15]. The attack vector could be from the use of IPv6 extension header as well as fragmentation. This is because implementation of RA Guard just looks at the next header field of IPv6 packet on its filtering mechanism. The two types of IPv6 extension header will be indicated by different value with the typical ICMPv6 message. This could make the filtering work fail. Furthermore, RA Guard does not offer protection when the IPv6 traffic is tunneled as discussed in [16]. IV. TRUST BASED SECURITY MECHANISM FOR IPV6 RD in a local link communication is messages exchange between an IPv6 host and local router. The messages are actually two types of ICMPv6 message namely RS and RA messages as shown in Figure 1 and Figure 2. Based on RFC 3756 [4], RD vulnerability is mostly on the RA message including both address spoofing and content changing. Therefore, all of the mitigation methods focus on securing RA message. The weakness of the four methods in related works could be classified into two categories: heavy calculation and uncovering most of IPv6 features. In one hand, ADD of SEND and TRDP use heavy calculations and long process. While SAVI and RA


Guard uncover some IPv6 features such as multiple address interface, extension header and fragmentation. The root cause of the heavy and long process in the current security mechanism is due to the centralized system on trust management and the use of encryption mechanism. In order to decrease the calculation process and time, we propose a new security mechanism called Trust Based Security (TBS) for IPv6 that based on decentralized trust management. It means there is a trust community in IPv6 LAN that distributes the trust between members in the local network, thus all nodes trusts each other without any specific Certificate Authority (CA). To do this, a mechanism to make trusted community is required. The TBS trust construction uses the concept of distributed trust management in[17], [18] and [19]. Since NDP in IPv6 contains small information transferred in local network, the use of complex encryption mechanism is avoided. Alternatively, we use hash function algorithm[20]to provide integrity of the NDP message including RS and RA message. Therefore, receiver could recognize the sender’s message and trust them based on the trusted message. To do this, receiver would verify the incoming message by applying the same hash algorithm used in the sender. If the integrity of the message is verified, the receiver then creates an entry on its neighbor cache for the solicitation sender. Typical neighbor cache in NDP mechanism contains IP address, link layer address and reachability states. In TBS mechanism, we add another column in the neighbor cache table called trust states. This trust status would determine what trust states of neighbors that could be trusted, distrust and uncertainty. Sender of solicitation message (host) generates RS message with a trust option called Trust Solicitation Option (TSO) as depicted in Figure 3. The TSO contains three main fields including message generation time (Ts), Sequence Number and a message authentication hash value. The generation time is important to prevent DoS attack on the solicitation sender. The sender stores the generation time and set a time t to receive solicited RA message as reply of the RS sent. The DoS attack could be avoid by limiting the received RA message within t second. The sender then only receive RA message and discard other RA message after the t second. Type

Length

Reserved

Ts (message generation time) – 4 bytes Sequence Number – 1 byte Message Authentication – 20 bytes Figure 3. Trust Solicitation Option

Sequence Number field is required to prevent recurring attack. The number is generated randomly for each message to avoid duplication of the message. Thus, receiver would

recognize the legitimate message and reply by an appropriate RA message. The last field is a message authentication containing 20 byte SHA-1 [21] hash algorithm from message header especially IPv6 Hop Limit, Source IPv6 address and Source MAC address. This field is proposed to prevent the masquerade attack on changing the RS message content. The RS message is sent multicast to all routers in the same link (FF02::2). All routers would receive this RS message and process it according to the standard in RFC 4861. However, TSO is a new option in NDP message. The routers should consider the availability of this option. Upon receiving this option, routers should verify the message especially on the message authentication. It must do the same hash algorithm on default Hop Limit 255, source IP address taken from IPv6 header and MAC address of sender taken from frame that encapsulate the RS message. If the RS message with TSO is trusted, it means that the verification result is in a valid state, the routers then create an entry on its trust neighbor cache for the RS sender. However, due to the sender is a new host in the network with source address unspecified, the trust state is uncertain. Later, when the sender with the same MAC address send trusted information, the trust state could be updated to become trusted, otherwise the trust state is distrusted. The router then, generates a RA message to respond to the RS message. The RA message should carry trust advertisement option (TAO) as depicted in Figure 4.

Type

Length

Reserved

Sequence Number – 1 byte Message Authentication – 20 bytes Figure 4. Trust Advertisement Option

TAO contains the general fields of NDP option, 1 byte sequence number to prevent recurring attack and 20 bytes hash output of SHA-1 generated from access router’s information including IP address and MAC address. This field is proposed to give integrity of the router information attached in the RA message. As discussed in Section 2, router information includes router lifetime, reachable time, retrans timer and NDP option attached on the RA message. The receiver which is the RS sender will verify the RA message by conducting the same hash algorithm to router information and compare the result with the hash output in the end of RA message. Apart of sending RS with TSO to all routers, the sender also sends NS to all solicited multicast nodes in the link to get router’s information from other nodes using the same mechanism as illustrated above. Upon the solicitation, sender receives the reply NA, it will validate the message by comparing hash value obtained from the NA and the one from router through RA message. In certain amount of time t from message generation time Ts sender will stop


receiving advertisement. It will discard whatever message that comes after t. It will update trust states in its NC and default router list when receiving the same information, otherwise discards the information and retransmits both RS and NS to get new information.

8000000 6000000 4000000 2000000

V. ANALYSIS TSO and TAO are proposed to prevent RD processes from any NDP messages exploitation. The two new NDP options are intended to offer two security properties including integrity and availability. We do not consider the confidentiality property due to the NDP messages in general are not a confidential data. It uses multicast that ensure all nodes could receive the messages. The integrity property can be achieved by the message authentication field using one way hash function as discussed in [22] and [23]. The receiver could verify the integrity by run the same hash algorithm for 255 default Hop limit value, source IP address obtained from the IPv6 header and source MAC address get from the frame. If the comparison between the two hashes output result in the same value, the message is received and create an entry in the NC. The use of SHA-1 as one way hash function on providing message integrity is simpler and cheaper than RSA signature. As discussed in [24], RSA signature has increased the processing time on SeND up to 99% to those without RSA signature as shown in Table 1. This is because RSA requires a minimum of three processes: encryption in sender site, decryption in receiver and key exchange management. These will introduce more processing time compared to SHA-1. To make sure the processing time comparison between SHA-1 and RSA signature, we run the two algorithms in the same machine. The result is shown in Figure 5. Average processing time for SHA-1 is 0.028 ns compared to 6.39 ns for RSA. TABLE 1 RSA PROCESSING TIME IN SEND Protocol NDP SeND without RSA SeND

Processing Time (ms) 0.34 0.44 75.97

As discussed in [4], most of the threats on NDP other than message modification is DoS. TBS is intended to prevent DoS attack on IPv6 link local communication that is generally done by flood the target node using NDP messages. DoS prevention could be done using the message generation time field. Sender stores the Ts and calculates the time of receiving RA message based on the generation time. It will discard any RA or NA message come after a predefined time t. Discarding the unintended message as soon as possible would prevent DoS attack [25].

0 1 3 5 7 9 11 13 15 17 19 21 23 SHA-1

RSA

Figure 5.Processing Time Comparison Between SHA-1 and RSA

With 29 bytes extra on TSO and 25 bytes on TAO, traffic overhead is lesser than the usage of SEND that add about 368 bytes [26] in each message. Table 1 shows the detail comparison of theoretical bandwidth consumption (Kbps) between TBS and SEND that includes ADD for router authorization. The bandwidth calculation uses equation (1) with r is the number of access router in the local network. Bandwidth = (S + r (A)) x 8 / RTT Kbps

(1)

S is the size of solicitation message while A is the size of advertisement message and RTT is round trip time that is assumed same in the same local network. TABLE 2 BANDWIDTH CONSUMPTION OF ROUTER DISCOVERY Original RD 560+944r

SEND 3504+3888r

TBS 1009+1331r

Table 2 demonstrates how Trust Based Security (TBS) increases the bandwidth consumption compared to the original router discovery without any security mechanism to about 1.5 times higher. However, it can decrease the bandwidth consumed by SEND up to 3.15 times lesser with one access router connected. VI. CONCLUSION IPv6 is emerging Internet technology that will be applied on any electronic devices. As the incident of security risks and breaches on Internet is increasing, security should be taken into consideration for IPv6 and its supporting protocols including NDP. Even though many mechanisms were proposed to secure NDP, the implementation is still minimal due to their heavy implementation mechanism. This paper proposes VTBS that uses decentralized trust management by introducing TSO for solicitation message and TAO for advertisement message. The new mechanism could prevent NDP from

Proceeding of the 2013 IEEE International Conference on RFID Technologies and Applications, 4 – 5 September, Johor Bahru, Malaysia [16].

Cisco, Implementing First Hop Security in IPv6, 2011, Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA.

[17].

Blaze, M., J. Feigenbaum, and J. Lacy, Decentralized Trust Management, in Proceedings of the 1996 IEEE Symposium on Security and Privacy1996, IEEE Computer Society. p. 164.

[18].

Abdul-Rahman, A. and S. Hailes, A distributed trust model, in Proceedings of the 1997 workshop on New security paradigms1997, ACM: Langdale, Cumbria, United Kingdom. p. 48-60.

[19].

Li, H. and M. Singhal, Trust management in distributed systems. Computer, 2007. 40(2): p. 45-53.

[20].

Coron, J.-S., et al. Merkle-Damgård revisited: How to construct a hash function. in Advances in Cryptology–CRYPTO 2005. 2005. Springer.

Narten, T., et al., Neighbor Discovery for IP version 6 (IPv6), in Request for Comments 4861, 2007, Internet Engineering Task Force.

[21].

Kim, J., et al., On the security of HMAC and NMAC based on HAVAL, MD4, MD5, SHA-0 and SHA-1, in Security and Cryptography for Networks2006, Springer. p. 242-256.

J. Arkko, E., et al., SEcure Neighbor Discovery (SEND), in Request for Comments 3971, 2005, Internet Engineering Task Force.

[22].

Tsudik, G., Message authentication with one-way hash functions. ACM SIGCOMM Computer Communication Review, 1992. 22(5): p. 29-38.

Kent, S. and K. Seo, Security Architecture for the Internet Protocol, in Request for Comments: 4301, 2005, Internet Engineering Task Force.

[23].

William, S. and W. Stallings, Cryptography and Network Security, 4/E2006: Pearson Education India.

attack using puzzle. With the small size of TSO and TAO, the traffic overhead is very low compare to SEND mechanism. ACKNOWLEDGMENT This research was supported by the Research University Grant No: 1001/PNAV/846064 funded by Universiti Sains Malaysia, in collaboration with Directorate General of Higher Education, Ministry of Education and Culture, the Republic of Indonesia and Taylor’s University, Malaysia.

REFERENCES [1].

[2].

[3].

[4].

P. Nikander, E., J. Kempf, and E. Nordmark, IPv6 Neighbor Discovery (ND) Trust Models and Threats, in Request for Comments 3756, 2004, Internet Engineering Task Force.

[24].

Gaeil, A., et al. Analysis of SEND Protocol through Implementation and Simulation. in International Conference on Convergence Information Technology, 2007.

[5].

Alsa'deh, A. and C. Meinel, SEcure Neighbor Discovery: Review, Challenges, Perspectives and Recommendations. Security & Privacy, IEEE, 2012. PP(99): p. 26-34.

[25].

Nikander, P., Denial of sService, Address Ownership, and Early Authentication in the IPv6 World, in Security Protocols, B. Christianson, et al., Editors. 2002, Springer Berlin Heidelberg. p. 22-26.

[6].

Levy-Abegnoli, E., et al., IPv6 Router Advertisement Guard, in Request for Comments 6105, 2011, Internet Engineering Task Force.

[26].

Chiu, S. and E. Gamess. Easy-SEND: A Didactic Implementation of the Secure Neighbor Discovery Protocol for IPv6. in World Congress on Engineering and Computer Science 2009, WCECS 2009 2009. San Francisco, USA.

[7].

Zhihui, Y., D. Gengsheng, and W. Junyun. SAVI-based IPv6 source address validation implementation of the access network. inproceeding of Computer Science and Service System (CSSS), 2011.

[8].

Jun, Z., et al. TRDP: a Trusted Router Discovery Protocol. in International on Symposium Communications and Information Technologies, 2007. ISCIT '07.

[9].

Deering, S., ICMP Router Discovery Messages, in Request for Comments 1256, 1991, Internet Engineering Task Force.

[10].

Zhao, M., et al., Decentralized Trust Management for Securing Community Nteworks. Intel Technology Journal, 2009. 13(2): p. 148-168.

[11].

Wu, J., et al., Source Address Validation Improvement Framework, in Draft Internet2012, Internet Engineering Task Force.

[12].

Supriyanto, et al., Survey of Internet Protocol Version 6 Link Local Communication Security Vulnerability and Mitigation Methods. 2013. 30(1): p. 64-71.

[13].

McPherson, D., F. Baker, and J. Halpern, SAVI Threat Scope, in Internet Draft, 2011, Internet Engineering Task Force.

[14].

Wu, J., et al., Source address validation improvement framework.in InternetDraft, October, 2010. Internet Engineering Task Force.

[15].

Gont, F., IPv6 Router Advertisement Guard (RA-Guard) Evasion, in Internet Draft 2011, Internet Engineering Task Force.