Technical Report N : T2.1_05_PI_R01 Automatic IPSec Security Association Negotiation in Mobile-Oriented IPv6 networks

Transcription

1 1 Technical Report N : T2.1_05_PI_R01 Automatic IPSec Security Association Negotiation in Mobile-Oriented IPv6 networks Stefano Lucetti, s.lucetti@iet.unipi.it I. INTRODUCTION The need for secure and ubiquitous access to information is one of the driving concepts of current research in the networking field. The issue of security is particularly relevant when considering wireless networks, due to the intrinsically open nature of their physical layer. On the other hand, IPv6 and its companion protocols are the evolution of the current IP protocol, and are supposed to represent the keys to the success of any novel communication architecture. In particular, new and emergent services such as the seamless terminal mobility offered by the Mobile IPv6 protocol (regardless of the access technology), or the integrity and privacy guarantees offered by the IPSec protocol are not mere added values, but requirements which cannot be disregarded. Other relevant services, whose necessity has been highlighted during the years of operation of IPv4 networks, include native multicast support, and Quality of Service guarantee. In our work, we have focused our attention on the practical issues that may arise during the deployment phase of an IPv6 network supporting Mobile IPv6 and IPSec. As will be detailed in the next sections, from the practical viewpoint the management and activation of the policies related to the IPSec protocol are quite complex tasks, which typically require user intervention. Interaction with the user is something which has to be avoided as much as possible, since it is at the antithesis of the autoconfiguration paradigm pursued by IPv6 and especially by Mobile IPv6. The outcome of this phase of our work has been the development of a user space daemon which integrates with the IPSec implementation available in the Linux operating system. The task of the daemon is to automate, hiding all the operations to the user, the process of configuring and activating the IPSec Security Association between the terminal of the user and a Security Gateway (SG) which offer to the IPv6 subnet the connectivity towards the rest of the Internet. In the rest of the paper we give a brief overview on the involved protocols, describe one of the operative scenarios in which the developed daemon can be adopted, detail the principle of operation and the interaction of the daemon with the rest of the operating system, and introduce planned integration activities. II. ENABLING TECHNOLOGIES Scalability and integration with advanced services have been the main target of IPv6 design. As a consequence, a set of protocol extensions have been rapidly developed to fulfill various requirements exhibited by modern services and applications. The two most interesting ones are represented by the Mobile IPv6 and IPSec protocols, originally proposed in a IPv4 environment, but which have met major success taking advantage of the peculiarities of IPv6 protocol. The Mobile IPv6 protocol (MIPv6), recently standardized [1], allows any host to be univocally identifiable and reachable by means of a unique IPv6 address, regardless of its actual point of attachment to the network. The description of the principle of operation of MIPv6 is addressed in Subsection II.A. On the other hand, the IPSec protocol is widely used to create VPNs which realize secure communication channels over insecure networks [2][3][4]. IPSec operates at IP layer, differentiating from the other approaches proposed in literature, which operate at Data Link or Transport layer, such as 802.1X architecture [5] or PPTP protocol [6]. IPSec introduces the concept of logical connections, indicated as Security Associations (SA), able to provide stateful security services to the traffic which flows through them. Each IPSec node keeps a SA Database (SAD) and a Security Policy Database (SPD). SPD contains a set of rules with selectors used to match the traffic being processed by a policy; each policy is identified by a Security Policy Index (SPI). The SPI is used to identify which SAD entry contains the secret key, encryption or authentication algorithm, IPSec mode (transport or tunnel), and so forth. The management of SAD and SPD, which includes creation, activation, destruction of entries, can be performed manually by a operator, but due to the overwhelming complexity of such approach, which raises obvious scalability problems, it is often delegated to an automated process. The Internet Security Association and Key Management Protocol (ISAKMP) [7] has been designed to be a generic framework for authentication and key exchange; the Internet Key Exchange (IKE) is the most widely adopted protocol for SA negotiation and keying material provisioning [8]. In our work we refer to racoon, the IKE implementation available for Linux included in the ipsec-tools package [9], a port of the KAME FreeBSD

2 2 Fig. 1. Reference Scenario. implementation. A. Mobile IPv6 Mobile IPv6 (MIPv6) allows any host, indicated with the term Mobile Node (MN), to be univocally identifiable and reachable by means of a unique IPv6 address, regardless of its actual point of attachment to the network. The evolution path of the standardization of Mobile IPv6 begun from the basic concepts already present in the Mobile IP protocol developed for IPv4, but natively including all its extensions and optimizations (for instance the Route Optimization procedure), and taking into account the features offered by the new version of the IP protocol. The principle of operation of MIPv6 is briefly summarized in the following. Each MN is statically identified by an IPv6 address, indicated as Home Address, which belongs to the home network of the MN. When the MN moves to another IPv6 subnet, indicated as foreign (or visited) network, it acquires a second IPv6 address, by means of stateless or stateful autoconfiguration. Such address is called Care-of Address (CoA), and will be used to actually deliver the packets to the MN. In such sense, the Home Address guarantees the identification of the MN, whereas the CoA allows its reachability. As soon as the MN acquires a new CoA, it must register it with the Home Agent, in order to allow the packets addressed to its Home Address to be forwarded to its new actual position. The registration procedure is initiated by the MN, which sends a Binding Update (BU) message to the Home Agent, notifying its CoA, and asking for a binding acknowledgement (BA), which is subsequently sent back. According to [10], signaling between MN and the Home Agent is protected using IPSec. The Home Agent intercepts the packets directed to the MNs for which a valid active binding is present in its cache, and forwards them to the registered CoA using IPv6 in IPv6 encapsulation. The interception of the packets by the Home Agent is the analogous of the proxy ARP procedure used in Mobile IPv4, and is indicated as Proxy Neighbor Discovery. Note that in the MIPv6 terminology, any node which communicates with a MN is called Correspondent Node (CN). The reverse path (MN to CN) is analogous; packets are tunneled from the MN to the Home Agent, and then forwarded to the CN. To avoid the triangular routing that such procedure causes and to restore direct communication between MN and CN, a routing optimization procedure is considered in the standard. The MN informs all the CN with which it is communicating of its new CoA by means of a BU message. An appropriate security procedure, namely Return Routability mechanism, is used to avoid security attacks related to the falsification of such messages. All the applications running at the MN and the CN are not aware of the movement of the MN and of its routing address change; more generally, transport layer protocols are not aware too. Consequently, all the ongoing TCP connection are not affected by MN movements, which result to be almost transparent to the end user, if we exclude the temporary loss of connectivity during handover. Furthermore, MIPv6 does not impose any requirement on the FN, apart the provisioning of a valid public IPv6 address, and is therefore promptly available on any IPv6 domain. It is noteworthy to stress that the MN itself is identified by the Home Address, through one of its network interfaces. If the MN connects to a visited network by means of the same network interface on which the Home Address is associated, the term horizontal handover is used. On the contrary, if the MN also changes the network interface used to connect to the network, i.e. disconnecting from a Ethernet plug and associating to an Access Point, the term vertical handover is used. To summarize, each MN is identified by its Home Address (eventually used in the DNS table for its domain), but the packets addressed to it are routed according to the registered CoA. III. REFERENCE SCENARIO The reference scenario is depicted in Figure 1; such scenario is quite general, and can be easily mapped in a number of different operational network architectures. The problem assessed in our work is the automatic setup of an IPSec SA between the mobile host, typically indicated as Road Warrior (RW) and the SG of the currently visited IPv6 subnet.

3 3 As far as a single subnet is concerned, we assume that both wired and wireless connectivity is available. The natural candidate for wireless access is IEEE , in its various versions, but it is possible to think to different wireless access technology (such as Bluetooth). Wireless access is continuously acquiring popularity due to a number of advantages with respect to wired networking, such as easiness and limited intrusivity of installation, possibility of rapid deployment or reconfiguration or impossibility of conventional cabling deployment in particular sites (archeological or historical sites and buildings). The adoption of a wireless access, however, raises some problems as far as the security aspects are concerned. In wireless communications eavesdropping of the communication by a malign user is possible, as well as the injection of unauthorized traffic into the network. IEEE i [11], recently ratified, is an extension to the base standard which aims to solve the security issues, highlighted by several researchers [12][13][14], related to the poor design of Wireless Equivalent Privacy (WEP) algorithm, the former authentication, access control and encryption protocol designed for WLAN. However, i is not yet widely adoptable, because older existing WLAN devices do not have the sufficient computation power to sustain the complexity of the new encryption standard adopted by i, the Advanced Encryption Standard (AES). Furthermore, in the case of the adoption of different wireless access technologies, there is the necessity to separately manage the security issues related to the specific technology. To overcome such limitations an approach based on IPSec rather than a plethora of ad hoc solutions is preferable, and has been adopted in the scenario. In detail, each SG acts not only as a router to interconnect the subnet to the others, but performs authentication and access control. Any wireless (or wired) host which connects to the subnet, after having successfully passed the layer 2 authentication (if any) is not entitled to directly communicate with other hosts, but must set up an IPSec tunnel which terminates at the SG. Only communications taking place over such tunnels are routed by the SG; the result is that only authorized hosts can effectively use the access network. Unauthorized user not only are unable to access the resources of the network, but cannot intercept other communications taking place over the wireless network, because they are secured by strong cryptographic encryption. The management of the IPSec SA raises some practical issues related to the need for the user to adequately prepare the racoon configuration file with the necessary pieces of information. In particular, the user of a mobile host is required to manually modify the SG IPv6 address at any change of its point of attachment. Apart from the fact that the SG address is not known a priori to the user (nor the SG knows all the possible addresses of the mobile host which may require the instauration of an IPSec SA), requiring the user to modify the configuration file breaks the automatic configuration and transparent mobility potentially offered by the MIPv6 protocol. The developed daemon, which we have called mipsd (acronym for Mobility-oriented IPSec Daemon), operates at the RW; it interacts with the racoon daemon at any change of IPv6 subnet allowing to set up the IPSec SA with the SG without requiring any kind of intervention by the user. IV. MIPSD DESCRIPTION As far as IPSec implementation is concerned, we have adopted the KAME one, currently integrated in the mainline 2.6 linux kernel tree. Other implementations are available, but KAME one promises to be the most widely supported, because of the complete set of functionalities. The developed mipsd daemon communicates with racoon through a unix-socket, taking advantage of a pre-existing protocol defined in the racoon daemon for management and debugging purposes. Such protocol has been extended to allow mipsd to interact with racoon, issuing a subset of commands to such daemon. The principle of operation of mipsd is rather simple: it starts listening to configurable network interfaces for ICMPv6 Router Advertisement messages, in order to detect the connection to an IPv6 subnet. After that the interface has acquired a valid IPv6 address by means of stateless autoconfiguration (waiting for the Duplicate Address Detection procedure to complete), it flushes the existing SAD and SPD, and informs the racoon daemon of the SG IPv6 address. The negotiation of the new IPSec SA is then performed by racoon, triggered by a hot-restart signal from mipsd. The scheme depicted in Figure 2 represents the core flow-chart of mipsd daemon; Figure 3 represents the sockets used by mipsd to communicate with the kernel and the other entities. In the initial phase (not represented in the scheme) two sockets are opened: a unix-socket to establish a connection with racoon and a PF_INET6 socket to listen for the ICMPv6 Router ADVertisement (RADV) messages received on all the available network interface. Indeed, the first step is represented by a recvfrom() system call that, according to the ICMP6_FILTER applied to the socket, reads only ICMPv6 RADV messages. The subsequent step performs a check on whether the received message comes from the correct network interface (the one specified in the command line) or not. Since the SO_BINDTODEVICE option, set in the socket, may result buggy in some linux implementations, mipsd verifies the correctness of the scope_id of each incoming message. ICMP messages which lack of the prefix information option are discarded to ensure the correct execution of the following steps. According to the value of the Router Address flag of the RADV Prefix Information Option, the SG address is read from the ICMPv6 message itself or built combining the advertised prefix with the Interface ID of the link-local address from which the message has been received. If the obtained SG address differs from the current active one (if existent) the mipsd

4 4 Fig. 2. mipsd core flow chart. Fig. 3. Reference Scenario. assumes that the node is connecting to a different (new) IPv6 subnet. Concurrently, the stateless autoconfiguration process determines the new node address, and performs the Duplicate Address Detection operations in order to validate it. After the acquisition of the SG address, mipsd checks if a configurable timeout from the previous IPSec SA reconfiguration has expired; if not, it starts the whole process over, to avoid ping-pong phenomena which can occur when multiple RADV originated by different routers are received by the node. The remaining actions are related to the interaction with the racoon daemon and the linux kernel, by means of the developed APIs (racoonlib and setkeylib) and existing libraries (ipseclib). In short, mipsd flushes the existing SAD and SPD, forces racoon to reconfigure the SA using the new endpoints and add the new policy in the SPD. In the current configuration, the SG is configured to accept IKE negotiation from any host. Afterwards, the identity of such host is verified by means of appropriate credentials; currently, the credentials of MN and WAG, to be used during Phase 1 of IKE, are granted by X.509 certificates. Figure 4 describes a typical situation, in which a wireless MN associates with the Access Point, acquires a valid IPv6 address, and then perform the authentication with the SG prior to be able to communicate with the rest of the network. Next step in the development path of mipsd foresees its integration also with the MIPv6 Linux implementation [15], once that it will become available for 2.6 kernel series. A further extension to be addressed is the distribution of the X.509 certificates, which are needed to set up the IKE Security Associations. Currently, this is done statically, but this obviously poses severe scalability issues. Our plan is to integrate the system with the extensions DNSSEC, as specified in [16-19].

5 5 Fig. 4. Summary of signalling at the wireless IPv6 subnet. V. CONCLUSIONS We have developed a user space daemon which integrates in the IPSec architecture available in Linux. The proposed daemon allows any host, acting as a IPSec Road Warrior, to connect to an IPv6 subnet and automatically, without any user intervention, configure and activate an appropriate IPSec Security Association with the relevant Security Gateway. The utility of the daemon is straightforward if the integration with Mobile IPv6 protocol is taken into consideration. Indeed, Mobile IPv6 lets node movements to be completely transparent to the overlying protocols (and to the user). Having to manually operate to configure new IPSec SA at each subnet change would dramatically reduce, or nullify, the utility of the MIPv6 protocol. REFERENCES [1] D. Johnson, C. Perkins, J. Arkko, Mobility Support in IPv6, IETF RFC 3775, June 2004 [2] S. Kent, R. Atkinson, Security Architecture for the Internet Protocol, IETF RFC 2401, November [3] S. Kent, R. Atkinson, IP Authentication Header, IETF RFC 2402, November [4] R. Atkinson, S. Kent, IP Encapsulating Security Payload (ESP), IETF RFC 2406, November [5] IEEE. Standard for Local and Metropolitan Area Networks, Port Based Network Access Control, IEEE STD 802.1X-2001, November 2001 [6] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn, Point-to-Point Tunneling Protocol (PPTP), IETF RFC 2637, July 1999 [7] D. Maughan, M. Schertler, M. Schneider, J. Turner, Internet Security Association and Key Management Protocol (ISAKMP), IETF RFC 2408, November [8] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), IETF RFC 2409, November [9] [10] [2] J. Arkko, V. Devarapalli, F. Dupont, Using IPSec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents, IETF RFC 3776, June 2004 [11] IEEE Standard, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Medium Access Control (MAC) Security Enhancements, IEEE STD i, July 2004 [12] S.Fluhrer, I.Mantin, A.Shamir, Weaknesses in the Key Scheduling Algorithm of RC4, Proc. of SAC 2001 Toronto, Ontario, Canada, August 16-17, 2001, in LNCS 2259 Selected Areas in Cryptography, Springer-Verlag 2001 [13] N.Borisov, I.Goldberg, D.Wagner, Intercepting Mobile Commmunications: the Insecurity of , 7th ACM Int l Conf. on Mobile Computing and Netw., Rome, July 2001 [14] J.R.Walker, Unsafe at any key size; an analysis of the WEP encapsulation, IEEE Document /362, October 2000 [15] Mobile IPv6 for Linux, [16] M.Richardson, A Method for Storing IPSec Keying Material in DNS, IETF RFC4025, February 2005 [17] R.Arends, R.Austein, M.Larson, D.Massey, S.Rose, DNS Security Introduction and Requirements, IETF RFC 4033, March 2005 [18] R.Arends, R.Austein, M.Larson, D.Massey, S.Rose, Resource Records for the DNS Security Extensions, IETF RFC 4033, March 2005 [19] R.Arends, R.Austein, M.Larson, D.Massey, S.Rose, Protocol Modifications for the DNS Security Extensions, IETF RFC 4033, March 2005