Daniel Palomares

During 2012, the global mobile traffic represented 70% more than 2011. The arrival of the 4G technology introduced 19 times more traffic than non-4G sessions, and in 2013 the number of mobile-connected to the Internet exceeded the number of human beings on earth. This scenario introduces great pressure towards the Internet service providers (ISPs), which are called to ensure access to the network and maintain its QoS. At short/middle term, operators will relay on alternative access networks in order to maintain the same performance characteristics. Thus, the traffic of the clients might be offloaded from RANs to some other available access networks. However, the same security level is not ensured by those wireless access networks. Femtocells, WiFi or WiMAX (among other wireless technologies), must rely on some mechanism to secure the communications and avoid untrusted environments.

Operators are mainly using IPsec to extend a security domain over untrusted networks. This introduces new challenges in terms of performance and connectivity for IPsec. This thesis concentrates on the study of the mechanism considering to improve the IPsec protocol in terms of continuity of service.

The continuity of service, also known as resilience, becomes crucial when offloading the traffic from RANs to other access networks. This is why we first concentrate our effort in defining the protocols ensuring an IP communication: IKEv2 and IPsec. Then, we present a detailed study of the parameters needed to keep a VPN session alive, and we demonstrate that it is possible to dynamically manage a VPN session between different gateways. Some of the reasons that justify the management of VPN sessions is to provide high availability, load sharing or load balancing features for IPsec connections. These mechanisms increase the continuity of service of IPsec-based communication. For example, if for some reason a failure occurs to a security gateway, the ISP should be able to overcome this situation and to provide mechanisms to ensure continuity of service to its clients.

Some new mechanisms have recently been implemented to provide High Availability over

IPsec. The open source VPN project, StrongSwan, implemented a mechanism called ClusterIP in order to create a cluster of IPsec gateways. We merged ClusterIP with our own developments in order to define two architectures: High Availability and Context Management over Mono-LAN and Multi-LAN environments. We called Mono-LAN those architectures where the cluster of security gateways is configured under a single IP address, whereas Multi-LAN concerns those architectures where different security gateways are configured with different IP addresses.

Performance measurements throughout the thesis show that transferring a VPN session between different gateways avoids re-authentication delays and reduce the amount of CPU consumption and calculation of cryptographic material. From an ISP point of view, this could be used to avoid overloaded gateways, redistribution of the load, better network performances, v vi improvements of the QoS, etc. The idea is to allow a peer to enjoy the continuity of a service while maintaining the same security level that it was initially proposed.

List of Tables

Introduction

The Internet Service Providers (ISPs) are facing big challenges in order to manage the amount of mobile data traffic. During 2012, the global mobile traffic represented 70% more than 2011.

Actually a 4G connection generated, in average, 19 times more traffic than a non-4G session.

Moreover, in 2013 the number of mobile-connected devices will exceed the number of human beings, making the aggregate smartphone traffic in 2017 be 19 times greater than it is today [START_REF]Cisco visual networking index: Global mobile data traffic forecast update[END_REF].

Radio Access Networks (RAN) will not be able to face the exponential growth of such traffic.

Thus, in order to avoid overloaded networks, operators would have to offload RAN traffic towards WLANs. While offloading, ISPs must provide the same Quality of Service (QoS) and equivalent trust level. Actually, RAN networks are considered trusted domains whereas WLANs networks are considered untrusted networks. However, one solution that provides a similar trust level over WLANs networks are the VPNs (Virtual Private Networks).

One of the protocols that aims to protect IP traffic is IPsec, which is largely deployed as IPsec-based VPNs. These VPNs are designed to extend a trusted domain over an untrusted network. A VPN requires an End-User (EU) and the access network to agree on some security parameters in order to secure their IP traffic. This is done by establishing security associations (SA) between a Security Gateway (SG) and the EU. This may result in a large cluster of SGs managed by the ISPs at the same time.

The objective of this thesis is to allow IPsec VPN infrastructures to provide high QoS to EUs as well as to ensure continuity of service. More specifically, we want the VPN connections to be resilient to failures. This is what we call High Availability (HA) throughout this thesis.

We also want that ISPs can easily manage the load due to the VPN traffic of their clients (this is what we call Traffic Management or Context Management). As such, when a multinode VPN platform is being used by the ISP, it is able to transfer a VPN connection from one SG to another, introducing the concept of context transfer. Thus, when a VPN session is transferred, this means 2 1.1. Architectures of Interest that all the parameters concerning that session are transferred as well. In fact, there are some scenarios where the possibility to transfer a VPN session from one SG to another has beneficial effects. Some use cases involve load-balancing of VPN traffic among different SGs, handover between different access networks or improvements of fail-over clusters with High Availability (HA) features.

Throughout this chapter, we present some architectures of interest and use cases in section 1.1. Then, we describe the VPN Service and introduce some technical challenges concerning the transfer of the security contexts. We also introduce two main architectures called Mono-LAN and Multi-LAN in section 1.2. Following section 1.3, presents the theoretical positioning of Context Transfer face to Mobility operation. Section 1.4 positions our investigations compared to some related works. Later on in section 1.5, we summarize our contributions to the community during this thesis, and finally, section 1.6 describes the organization of the manuscript.

Architectures of Interest

The goal of this section is to introduce some architectures of interest and scenarios where the IKEv2/IPsec context transfer may be used in real topologies. First, we explain the advantages of transferring the IKEv2/IPsec parameters and how we can use it to build a cluster of IPsec-based VPN service. Then, we present how the context transfer may improve EUs experience in offload scenarios.

Clustering IPsec Security Gateways

This architecture aims to create a cluster of IPsec Security Gateways. IPsec [START_REF] Kent | Security Architecture for the Internet Protocol[END_REF] is a layer 3 protocol aiming to protect IP communications. An End-User (EU) accessing the network must establish a VPN connection with a SG in order to gain access to some services. The goal of the cluster is to render the IPsec services highly available. The traffic between the EU and the cluster is protected with IPsec and the session is authenticated using Internet Key Exchange protocol (IKEv2). Our goal is to create a cluster of SGs aiming to improve the EU experience while protecting the communication with IKEv2/IPsec suite.

Figure 1.1 represents a cluster of SGs. It shows an EU establishing a VPN session with the cluster. For some reason (e.g. an overloaded SG, a failure on the responsible SG, latency, etc.), the SG must transfer its session to another SG within the cluster in order to ensure continuity of the VPN service. By doing so, the EU's experience is improved because this represents less interruption of the communication, as the EU does not need to proceed a time consuming operation to re-establish a new VPN session from scratch. However, the session transfer requires These situations are next referred to as Mono-LAN or Multi-LAN environments respectively (see section 1.2).

Offload Architectures

The mechanism called offload consists in switching the End-Users (EUs) from overloaded Radio Access Networks (RANs) towards some alternate wireless networks (e.g. WLAN like for example WiFi). These networks are more likely to be untrusted (when attaching other operator's access points), unreliable and prone to not handle mobility operations. As a result, some operations like mobility, multihoming or security must be handled by the terminal itself (see [START_REF] Eronen | IKEv2 Mobility and Multihoming Protocol (MOBIKE)[END_REF]).

Once offloading towards the WLANs, operators need to maintain the same level of security as in RANs. For this reason, applying security at the radio layer only (L2) might not be sufficient since the WLAN access point is considered as untrusted when it does not belong to the same service provider. This leads the limitation of offloading only between the same operator's access points. Another solution might be to secure at a higher layer, for example, at the transport layer or above (L4 or more). This means that applications have to be security-aware. Unfortunately,

Architectures of Interest

the applications in the market are reluctant to modify their source code for applying some sort of security (e.g. TLS or DTLS), as the EUs experience might decrease due to additional overhead, bandwidth consumption, additional certificate popups and additional computation.

Furthermore, operators might favor to secure their communication with EUs at the IP layer (L3), as IPsec, to secure IP communications. IPsec not only secures at the IP layer but also secure the layers above. The peer needs to gain access to the multimedia server placed behind the cluster. Once the EU attaches the WLAN Access Point (AP), it obtains its IP address, which is used to establish a VPN tunnel towards the cluster. At this point, the EU gains access to the multimedia server in a secure manner. Since secure attachment is provided at the IP layer with the VPN cluster located in the ISP CORE network, the communication remains trusted even though WLAN APs may be untrusted.

There are some advantages whenever the operator may decide to transfer the VPN session from one SG to another SG within the cluster by implementing IKEv2/IPsec context transfer.

For example, a VPN service provider may want to offer High Availability capabilities, support self-organization of the cluster, avoid overload SGs, improve bandwidth, reduce latency, among other features. However, if this context transfer happens between the same administrative domain where the SGs are configured with a single IP address (IP AD 1 in fig. 1.2), the EU is concerned by any signaling operations. Context transfer is transparent for EUs, as the IP addresses of both extremities of the VPN tunnel remain the same.

IKEv2/IPsec Context Transfer between Different Administrative Domains

In contrast with the precedent use case, figure 1.3 represents the context transfer of the IKEv2/IPsec context between VPN clusters within different administrative domains. When this happens, the IP address of the VPN tunnel changes (from IP AD 1 to IP AD 2). Throughout this thesis, we call this kind of scenario Multi-LAN environments (see following section 1.2.1).

This situation has an impact over the EU, because some IKEv2 signaling must take place in order to update the VPN session associated to the new IP address. The advantage of the context transfer between different administrative domains is that the EU avoids re-authenticating when moving from AD 1 to AD 2. Additionally, the EU continues to benefit from the features of a VPN cluster (e.g. load balancing, high availability, load sharing, etc.). When an EU establishes a VPN with a SG, some cryptographic material and keys are derived between them. When the SG fails, we do not want the EU to re-negotiate all these parameters with another stand-by SG which is supposed to take responsibility of the VPN connection. Thus, the cryptographic material and keys must be shared between the failing SG and the stand-by SG.

These parameters are referred to as the IKEv2/IPsec context and are explained in section 2.2.

We will consider the following architectures:

-Mono LAN: This architecture consists in a set of SGs that own the same IP address.

As represented in figure 1.4a, both SGs share the same IP. However, unless some special mechanism is used, both SGs can not own the same IP address at the same time, due to duplicated IP conflicts (this is discussed in detail throughout the thesis). In this case, the EU does not need to update its IP attachment address when its connection moves from SG1 towards SG2, and the IKEv2/IPsec context is also transferred between both SGs.

-Multi LAN: The second architecture consists in a set of SGs that own different IP addresses. Figure 1.4b represents a Multi-LAN architecture, where SG1 and SG2 have different IP addresses. In this case, when a context transfer takes place, the EU is impacted because it must update its VPN's destination IP address (i.e. one of the extremities of the tunnel). The EU can face this issue by performing specific IKEv2 exchanges like MOBIKE or REDIRECT extensions (see sections 2.6 and 2.7).

The biggest challenge to overcome a failure and to offer HA features concerns the synchronization of counters of the IKEv2/IPsec context. These counters control every incoming/outgoing IP packet protected with IPsec, preventing replay or unauthorized re-injection of previously processed IPsec traffic. These counters are referred together as IKEv2/IPsec counters. They must stay synchronized on both extremities when transferring a VPN session between different SGs. Ensuring their synchronization is a challenge that is addressed throughout this thesis.

Traffic Management of IPsec-based VPNs

Transferring a VPN connection from one SG to another allows an EU to change its point of attachment towards the access network. The main challenge of transferring the VPN traffic concerning an IPsec connection is to enable a SG to transfer all the cryptographic material and derived keys from one SG to another. Traffic management might be confusing with HA feature. However, they differ in the fact that traffic management does not involve failure detection of a SG, while the HA features do detect this situation. As such, traffic management can be triggered whenever it is desirable, whereas HA capabilities are automatically launched once a SG fails.

As represented in figure There are two available mechanisms to handle mobility and redirection of an IKEv2/IPsec context:

MOBIKE [3]
is a mobility and multihoming extension for IKEv2. MOBIKE considers the following scenarios when an EU is connected to a SG using tunnel mode: first, if one of the peer changes its IP address, it can advertise the other node that its IP address has changed. This means that the outer IP address of the tunnel is updated. Note that with MOBIKE, a peer can advertise that its IP address has changed as well as it can be aware of mobility from the other extremity of the tunnel. The second scenario is multihoming.

One of the peers can advertise the other peer of some alternate IP addresses where it is reachable if ever needed. These alternate IP addresses should be used in case the running IP address is not reachable anymore.

REDIRECT [START_REF] Devarapalli | Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)[END_REF] is also an extension for IKEv2. Now let us point out the differences between the context transfer and mobility operations:

1. With Mobility, the communication is established between two entities, the EU and the SG (or the Home Agent). These two entities remain the same before and after mobility occurs. Only the IP address of the EU is changed. On the other hand, with IKEv2/IPsec context transfer, the two entities before the context transfer and after the context transfer are different. In our case the SG is a different piece of hardware (device).

2. Mobility is only focused on the IP address, whereas IKEv2/IPsec context transfer carries all necessary security parameters of the IPsec session. This results from the fact that with mobility the entities remain the same, so both peers are aware of the session parameters.

In this section we mainly pointed out the differences between IKEv2/IPsec context transfer and mobility, as different protocols addressing different issues. This also means that these cases can be used together in a complementary manner. For example, when the IKEv2/IPsec context transfer takes place between two SGs that own different IP addresses (this is what we call a Multi-LAN architecture), then we can use mobility operations together with context transfer.

Both mechanisms can be used as complementary solution, allowing to update the outer IP address of the tunnel as well as maintaining the IKEv2 and IPsec information previously negotiated. In summary, performing mobility and context transfer ensures a fluid continuity of service for a mobile node that changes it attachment IP address between different SGs.

Related work and position of our work

A few publications and works have already been published on IKEv2/IPsec context transfer, and to our knowledge, most of them considered a Mobile IP environment. In fact, when using Mobile IP, IPsec may be used to protect the tunnel between the Mobile Routers and the Home Agents and to protect the signaling between some access router and the EU.

Position towards theoretical proposed architectures

Georgiades et al. exposed a theoretical case of study in [START_REF] Georgiades | Security of context transfer in future wireless communications[END_REF], where IPsec context transfer optimizes the transfer of some security context from a given device to another without renegotiating from scratch all the IPsec parameters. Georgiades et al. also introduced the concepts of homogeneous and heterogeneous security context transfer. This is actually the same analysis we arise when describing a context transfer between the same administrative domains or between different administrative domains. Some authentication protocols (e.g. RADIUS, Diameter) are discussed throughout the article in order to determine the potential parameters during a security context transfer, but no details concerning the IPsec context are given. However, this study does not include any performance test or real implementation nor any simulation.

Similarly, [START_REF] Ayaz | Applying IKE/IPsec Context Transfer to Aeronautical Networks[END_REF] describes also a theoretical study proposition for an aeronautical use case, where an IKEv2/IPsec context is transferred between a Mobile Router and the Home Agent by using Context Transfer Protocol (CXTP [START_REF] Loughney | Context Transfer Protocol (CXTP)[END_REF]). They show that using IKEv2 the IPsec database on both the MR and the new Home Agent, so the communication within the tunnel is maintained. However, the overhead calculation made in [START_REF] Ayaz | Applying IKE/IPsec Context Transfer to Aeronautical Networks[END_REF] does not take into account the additional delays during the CTD (context transfer data) exchanges between the old Home Agent and the new Home Agent. On the other hand, [START_REF] Ayaz | Applying IKE/IPsec Context Transfer to Aeronautical Networks[END_REF] does not give details of IKEv2/IPsec context parameters. Nevertheless, they explain the IKEv2 exchanges needed to establish an IKEv2/IPsec session. No implementation or performance test is conducted neither, although is considered as future work. In contrast, our investigation counts with several testbeds and performance tests.

[6] and [START_REF] Georgiades | Security of context transfer in future wireless communications[END_REF] both introduce different theoretical frameworks for IPsec context transfer in mobility environments (Mobile IP -MIP). In fact, they use MIP for session mobility and MOBIKE extension for IPsec mobility. The Multi-LAN architecture addresses similar mobility use cases. However, we do not use MIP for the terminal mobility. Instead, we only based our mobility operations by using the MOBIKE extension of IKEv2. We believe that using a single protocol (e.g IKEv2) for session mobility, reduces the complexity of the architecture, managed by operational teams and thus favors its deployment. Furthermore, our work is not motivated by mobility but by High Availability and management of SG clusters. Mobility concerns one session whereas High Availability concerns all IPsec sessions of a given SG. This clearly rises scalability issues when all the IPsec contexts have to be transferred from one SG to the other.

To address this issue, we define different manners to synchronize different IPsec databases of different SG and we define different strategies for transferring these contexts. In addition, we do not only define the architectures but we also implement and test the transfer of the IPsec context (see chapter 4).

Allard et al. [START_REF] Allard | Le transfert de contexte : atout pour la mobilité et outil de réduction des coûts pour la sécurité[END_REF] and Ayaz et al. [START_REF] Ayaz | Applying IKE/IPsec Context Transfer to Aeronautical Networks[END_REF] addressed the problem of uniqueness of the Security Parameter Index (SPI) of IPsec Security Associations. The SPI is used to uniquely identify the order to avoid SPI collisions. In contrast, [START_REF] Ayaz | Applying IKE/IPsec Context Transfer to Aeronautical Networks[END_REF] uses HELLO messages (see [START_REF] Devarapalli | Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture[END_REF]) to prevent SPI collisions before the context transfer takes place. In order to address this issue in Multi-LAN environments, we use the solution described in [START_REF] Allard | Le transfert de contexte : atout pour la mobilité et outil de réduction des coûts pour la sécurité[END_REF], as we base our mobility operation solution by using MOBIKE. Allard et al. in [START_REF] Allard | Le transfert de contexte : atout pour la mobilité et outil de réduction des coûts pour la sécurité[END_REF] identified all the parameters for both IKEv1/IPsec and IKEv2/IPsec contexts. However, the transfer of context was implemented for MIP architectures and not High Availability ones, which involve different constraints as presented in section 1.3.

Following section 1.4.2 positions our work from an implementation point of view with [START_REF] Allard | Le transfert de contexte : atout pour la mobilité et outil de réduction des coûts pour la sécurité[END_REF].

Position towards existing implementation

Allard et al. in [START_REF] Allard | Le transfert de contexte : atout pour la mobilité et outil de réduction des coûts pour la sécurité[END_REF][START_REF] Allard | An application of the context transfer protocol : IPsec in a IPv6 mobility environment[END_REF][START_REF] Allard | IKE Context Transfer in an IPv6 Mobility Environment[END_REF][START_REF] Allard | Security Analysis and Security Optimizations for the Context Transfer Protocol[END_REF][START_REF] Allard | An application of the context transfer protocol : IPsec in a IPv6 mobility environment[END_REF][START_REF] Allard | Etude de faisabilité concernant le transfert de contexte pour la sécurité[END_REF] are the only pieces of work that mention the existence of an implementation concerning IPsec context transfer. Allard et al. not only proposed the CXTP protocol to transfer an IKE/IPsec context as in [START_REF] Ayaz | Applying IKE/IPsec Context Transfer to Aeronautical Networks[END_REF], but they also considered other use cases as the Protocol for Carrying Authentication for Network Access (PANA) and Mobile IP (MIP).

In [START_REF] Allard | Le transfert de contexte : atout pour la mobilité et outil de réduction des coûts pour la sécurité[END_REF], chapters 9, 11, 12 and 13 are dedicated to present the PANA context transfer simulation based on a software called OMNet++.

Considering the similarity of our investigation with the work done by Fabien Allard, in the remaining of this section we next position our work against his thesis [START_REF] Allard | Le transfert de contexte : atout pour la mobilité et outil de réduction des coûts pour la sécurité[END_REF]:

Throughout this thesis, we concentrated on the usage of the version 2 of the Internet Key Exchange (IKE) protocol as the mechanism to perform authentication between a node and a SG.

All of the architectures in [START_REF] Georgiades | Security of context transfer in future wireless communications[END_REF][START_REF] Ayaz | Applying IKE/IPsec Context Transfer to Aeronautical Networks[END_REF][START_REF] Allard | Le transfert de contexte : atout pour la mobilité et outil de réduction des coûts pour la sécurité[END_REF][START_REF] Allard | An application of the context transfer protocol : IPsec in a IPv6 mobility environment[END_REF][START_REF] Allard | IKE Context Transfer in an IPv6 Mobility Environment[END_REF][START_REF] Allard | Security Analysis and Security Optimizations for the Context Transfer Protocol[END_REF][START_REF] Allard | An application of the context transfer protocol : IPsec in a IPv6 mobility environment[END_REF][START_REF] Allard | Etude de faisabilité concernant le transfert de contexte pour la sécurité[END_REF], are using MOBIKE to update the IPsec databases after the context tranfer occurs. MOBIKE is an extension of IKEv2 and there are no equivalence for IKEv1. Even though IPsec context transfer for IKEv1 has been implemented by Fabien Allard, the proposed architectures had never been evaluated with a real implementation. In order to evaluate this architecture, a new implementation based on IKEv2 is needed. In addition, IKEv2

proposes multiple extensions that our architectures are using: management of IKEv2/IPsec sessions (i.e. REDIRECT), mobility and multihoming operations (i.e. MOBIKE) and High

Availability protocols [START_REF] Singh | Protocol Support for High Availability of IKEv2/IPsec[END_REF].

Allard et al. implemented the IKEv1/IPsec context transfer on racoon implementation. Racoon is actually deprecated and there is no upgrade to IKEv2. We choose to implement the context transfer on strongswan [START_REF] Steffen | the OpenSource IPsec-based VPN Solution: StrongSwan[END_REF], the reference open source implementation for IKEv1 and IKEv2, and we could hardly reuse the code developed for racoon implementation.

In addition, Allard et al. in [START_REF] Allard | Le transfert de contexte : atout pour la mobilité et outil de réduction des coûts pour la sécurité[END_REF][START_REF] Allard | IKE Context Transfer in an IPv6 Mobility Environment[END_REF] [START_REF] Polqa | Perceptual Objective Listening Quality Assessment -POLQA[END_REF]) for audio streaming services.

In contrast with UDP traffic generator, we tested our architecture with different transport layers like TCP/HLS, UDP/RTSP; measuring the impact at the application layer. Using QoS, we prove that our solution has no major impact on End-User's services. The first scenario considers a cluster of Security Gateways. All of them are seen by the EU as a single IP address. Motivation for moving a session from one SG to the other is to manage the cluster and to provide High Availability features. The difference with Mobile IP environments, is that no interaction is required between the EU and the Security Gateway during the IKEv2/IPsec context transfer (the transfer is transparent to EUs). Also, by providing High Availability, each SG within the cluster is associated to a standby node that takes in charge the traffic in case of failover. In summary, the main differences compared to mobility operations are explained as follows:

1. First, failovers cannot be prepared in advance like in mobility operations. Second, all communications are transferred in a High Availability scenario, instead of one single tunnel during mobility. These two constraints impose to synchronize IPsec databases between the active node and the standby node within the cluster. This shared database requires to be Currently we are not aware of any implementation of this protocol (see [START_REF] Singh | Protocol Support for High Availability of IKEv2/IPsec[END_REF]).

3. When loads keep on increasing, then counters cannot be synchronized anymore. To avoid a re-negotiation of the IKEv2 channel, the EU must implement the synchronization protocol.

The second scenario we considered is a transfer between clusters that have different IP addresses. In this case, interaction between the EU and the clusters is necessary. However, transfer from one cluster to the other is only performed using IKEv2 signaling. In other words, we are not using Mobile IP signaling to perform mobility.

Finally, we present a solution to offer IPsec High Availability features. For this reason, we focus on a mechanism named ClusterIP, consisting in creating IP-based clusters with no dedicated hardware. ClusterIP allows to implement High Availability features and ensure connectivity during failovers of the SGs. The goal of ClusterIP is to share a common IP address with the purpose to build a cluster of machines in order to spread the load of incoming/outgoing IP packets. ClusterIP is based on firewalling rules under Linux environments. However, in order to implement ClusterIP under IKEv2/IPsec environments, we had to use the XFRM implementation that allows to get and set the IPsec sequence numbers.

Contributions

Our first contribution concentrates on identifying the elements composing an IKEv2/IPsec Additionally, we establish an experimental platform, and we perform intensive performance tests.

For instance, we conduct some tests with heavily loaded SGs (several VPN tunnels at the same time), demonstrating how smooth can be an IKEv2/IPsec context transfer, and how interesting is this approach for real deployment by operators.

Our third contribution is related to the Mono-LAN environment and gives an extensive performance comparison between an existing ClusterIP solution and our context transfer approach. Once again, we performed some performance tests with real trafic (e.g. streaming with TCP or UDP), demonstrating the feasability of the proposed solution.

We also approached the IKEv2/IPsec context transfer implementation under Multi-LAN environments. We present a theoretical framework to perform context transfer between SGs with different IP addresses.

Throughout this thesis, we faced some difficulties for addressing an appropriate solution. The first obstacle concerned the complexity and understanding of IPsec together with IKEv2. Both protocols are defined in different standards and involve a massive list of parameters that are negotiated in order to establish a VPN tunnel. However, as in any research project, this is part of an exhaustive study. Then, further investigations lead us to face some development challenges.

Getting inside the source code of strongSwan is a complex task. Understanding the features of this VPN solution represented one of the main difficulties throughout this thesis. The following difficulties concerned mainly networking and security network issues. In addition, our validation tests are also consider as a proof of concept. However, we insisted in running performance tests and measuring the impact on EU's experience for each scenario studied.

Security Services

This section introduces some security services (also defined in [START_REF]Security architecture for Open Systems Interconnection for CCITT applications[END_REF]). Different protocols (e.g. TLS, IPsec, Https) might offer these services at different layers of the OSI model.

Data integrity: the property that data have not been altered or destroyed in an unauthorized manner. In other words, during an IPsec-based communication, data integrity allows verifying that the contents of an IP datagram were not changed, either deliberately or due to random errors.

Data origin authentication: the corroboration that the source of data received is as claimed.

It allows a node to verify that each incoming IP datagram was originated by the claimed sender (source of data).

Peer entity authentication: the corroboration that a peer entity in an association is the one claimed. This service involves the identification and authentication of the peer. Replay detection: consists for an entity to detect that received data are duplicated from a previous exchange. Some data might have been sent in a secure manner by a legitimate entity; but they can be copied and injected again to the same destination. Data are still authentic but they are already processed several times.

Access control: the prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner. For IPsec, access control concerns a host or a Security Gateway. Only authorized hosts or Security Gateways that are intended to establish IPsec communications will be allowed to do so.

IPsec: Security Associations and Databases

IPsec is a protocol that proposes to secure any IP based communication by providing security services (see 2.1). It is defined in [START_REF] Kent | Security Architecture for the Internet Protocol[END_REF].

IPsec Protocols

Authentication Header

The Authentication Header (AH) is defined in [START_REF] Kent | IP Authentication Header[END_REF]. It offers integrity, data origin authentication and an optional anti-replay protection. The AH header (as in fig 2 .3), serves to transport the result of the integrity check over the entire original packet. As no encryption is performed, Authentication Header does not ensure confidentiality and consequently has a much simpler header than ESP. The AH header format depends on whether tunnel or transport mode is used. Figure 2.3 shows in detail how the AH header is built when the original IP packet is being protected using Authentication Header protocol in both transport and tunnel modes.

Encapsulation Security Payload

The Encapsulating Security Payload (ESP) protocol is defined in [START_REF] Kent | IP Encapsulating Security Payload (ESP)[END_REF]. Depending on the configuration parameters, ESP can offer confidentiality, data origin authentication, data integrity and anti-replay services. The ESP header is more complex than the AH header. Figure 2.4 shows in detail how the ESP fields are built using both transport and tunnel modes. Notice that ESP not only adds a header between the IP header and the payload of the packet, but it also adds some fields at the end of the packet. So the fact that ESP fields enclose the original payload, makes security more complex than with AH which only adds an header. Secrets are used as input keys for cryptographic algorithms. Naturally, the simplest idea concerning a shared secret would be to physically exchange it. Then, each peer can associate a host with its corresponding key. Unfortunately, this technique presents security risks when the exchange of secrecy is done under an uncontrolled environment. Additionaly, it is not scalable when deploying major infrastructures.

As mentioned in section 2.2, IPsec offers different security services by maintaining a shared state between the source and the destination of an IP datagram. This state defines the security services provided, as well as the cryptographic algorithms and their input keys. As cited above, maintaining this shared state in a manual fashion is not scalable at all. Hence, IKEv2 was designed to allow dynamic establishment and update of Security Associations, as well as the exchange of secret used as input to the cryptographic algorithms. IKE stands for Internet Key Exchange protocol. IKEv2 (defined in [START_REF] Kaufman | Internet Key Exchange (IKEv2) Protocol[END_REF], [START_REF] Kaufman | Internet Key Exchange Protocol Version 2 (IKEv2)[END_REF]) is an improved version 2 of its predecessor IKEv1 (defined in [START_REF] Piper | The Internet IP Security Domain of Interpretation for ISAKMP[END_REF], [START_REF] Maughan | Internet Security Association and Key Management Protocol (ISAKMP)[END_REF] and [START_REF] Harkins | The Internet Key Exchange (IKE)[END_REF]). Throughout this thesis work, IKEv1 is not discussed at all because it is an obsolete version of the protocol. Henceforth, only IKEv2 is argued.

How does IKEv2 protocol work?

Every IKEv2 exchange consists in a pair of messages: a request and a response. A peer that sends the first request is called INITIATOR, while the other peer is called RESPONDER. Initial exchanges of IKEv2 perform mutual authentication between the peers and establish an IKE Security Association (IKE SA). An IKE SA consists in a userland shared state used to negotiate further Security Associations for ESP and/or AH. Actually, these SAs for ESP and/or AH are referred as CHILD SA or IPsec SA.

Exchange Description: IKE SA INIT

This exchange helps to establish trust settings which ensure future IKE exchanges. Figure2.6

shows an graphic explanation of the IKE SA INIT request and response.

The INITIATOR sends the following information: SPI : security association unique identifier. CERTREQ: if present, this optional field asks for a certificate. At this point, both parties can generate a SKEYSEED, a shared secret from which all keys are derived for that IKE SA. The first key, usually called SK e, is used for encryption. The second one, for integrity, is called SK a. And finally, the SK d, is the key used to derive the keys for the CHILD SAs (once again, keys for encryption and integrity protection).

Exchange Description: IKE AUTH

During the IKE AUTH exchange, both peers authenticate each other, and the first CHILD SA is negotiated. CERTREQ: optionally ask for a certificate.

IDr : optional RESPONDER identity to specify which of the responder's identities it wishes to talk to (i.e. a host running multiple identities).

AUTH : a block of data protected with integrity protection (e.g. digital certificates or pre-shared keys + ID ) SAi2 : cryptographic algorithms proposed for the CHILD SA.

TSi : defines the source address of the traffic forwarded from the INITIATOR of the CHILD SA.

TSr : defines the destination address of the traffic forwarded to the RESPONDER of the CHILD SA.

The RESPONDER sends a response with the following information: SPI : security association unique identifier.

Version Number : set to version 2 (e.g. IKEv2).

IDr : confirms identity by sending the RESPONDER's identity (IDr).

CERT : RESPONDER certificate with the public key to verify the AUTH field.

AUTH : all information which is used to perform integrity protection.

SAr2 : cryptographic algorithms selected for the CHILD SA.

TSi : defines the source address of the traffic forwarded from the INITIATOR of the CHILD SA.

TSr : defines the destination address of the traffic forwarded to the RESPONDER of the CHILD SA.

Authentication of IKE SA

The authentication of the IKE SA could be achieved in three different manners: Pre-shared keys, X.509 Certificates or EAP (Extensible Authentication Protocol).

The easiest method to configure and authenticate IKE SAs is the pre-shared key, where both entities keep the same secret in a secure place. Security risks might be the main drawback of this authentication method due to the difficulty to keep the "shared" secret in a safe place. Also, the shared secret must be distributed among the entities that comunicate, which also represent a risk.

The authentication through certificate X.509 is another way to authenticate endpoints but demands a more complex system. The X.509 certificates use an algorithm based on assymetric cryptography. This method uses two cryptographic keys per user: a public key and a private key.

The certificate authority certifies that both keys are unique per user and are properly linked.

Depending on how these keys are used, the user can ensure integrity protection of the message as well as the identity of the sender. The sender signs the data using its private key and sends it to other users. Thanks to this signature, all recipients can verify the integrity and identity of the message by using the public key of the sender.

However, there are scenarios where the pre-shared key method does not scale well or the distribution of certificates X.509 is too complicated for the administrator (E.g. too much users). Thus, EAP-IKEv2 protocol consists in other way to perform authentication. EAP-IKEv2 uses an additional exchange towards an authenticator EAP server to authenticate endpoints. Details of EAP with IKEv2 can be found in [START_REF] Tschofenig | The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method[END_REF].

Clustering at the IP layer: ClusterIP

Clustering at the IP layer: ClusterIP

ClusterIP is an implementation based on recent Linux kernels (2.6 and higher). It permits load-balancing features without having a physical load-balancer. It is a smooth way to distribute the load of incoming IP packets in a very autonomous manner (each node can decide whether it is responsible or not for each incoming IP packet).

However, let us first introduce the notion of a cluster. In a computer system, a cluster is a group of servers and resources that act like a single system. These are commonly used to offer high availability, parallel processing or load balancing. Cluster members may exchange some data in order to be able to offer these features.

Under Linux kernel distributions, iptables is an implementation which configures, maintains, and inspects firewalling rules. It identifies an IP packet that matches a defined rule. This action is called target. ClusterIP is an extended target module of iptables, allowing to build a cluster of machines that share a common IP address without having a physical machine that performs this task. Indeed, ClusterIP is intended to provide load-balancing and clustering features without having a dedicated load-balancer machine. Thus, ClusterIP consists in a loadbalancer-less cluster on Linux operative system. It simply enables a server to calculate responsibility of incoming IP packets so that the server can decide by itself either it has to treat it or not.

When using a ClusterIP approach, no special hardware is required to benefit from its load-balancing and clustering features. The configured members of the cluster share a common multicast MAC address and thus receive the same packets. Then, a lower-layer mechanism (ClusterIP) filters packets at the IP layer by calculating responsibility through an algorithm (E.g. hashing the IP source of each packet). When used in command line interface, ClusterIP is a parameter of the iptables command.

The following parameters are set when implementing ClusterIP:

-new: creates a new cluster. Must be the first rule in the list of rules.

-hashmode mode: mode of hashing. Must be one of the following: sourceip, sourceip-sourceport, sourceip-sourceport-destport.

-clustermac mac: multicast MAC address of the cluster.

-total-nodes num: total number of nodes within this cluster.

-local-node num: the id number of the local node within the cluster.

-hash-init rnd: a random seed for hash initialization.

Chapter 2. Roadmap of IPsec and IKEv2 protocols 29

The nodes in a cluster usually have two Network Interface Card (NIC). One of the NIC's MAC address is replaced by the shared cluster MAC address and then a common virtual IP address is mapped onto it. The other NIC, being completely independent, can be used for any other purpose, as for example inter-nodes communications (E.g. Hearbeat mechanism, keep alives, etc.). Given the case where a machine counts with only one NIC, it is also possible to install a second virtualized IP address on the same interface.

Originally, ClusterIP does not handle IPsec traffic. However, if an IKE daemon (E.g strongSwan) handles to synchronize IKE SAs states and basic IPsec SAs states, a modified version of ClusterIP that handles IPsec traffic could solve synchronization troubles. The overhead for synchronizing ESP sequence numbers is elevated due to the fact that ESP sequence counters grow too quickly. Deploying IKE and IPsec in a cluster requires the synchronization of some information among all the cluster members. Synchronizing counters might be the major barrier to overcome when it comes to setting up a cluster with IPsec. Originally, IKEv2 and IPsec states were designed more likely to be static. IPsec/IKEv2 data was supposed to remain the same during an IPsec session or VPN Tunnel establishment. For example, if a node that initially established an IPsec tunnel changes its original IP address (E.g. it change its point of attachment and changes its IP address), the node was forced to brake down its connection and to re-initialize a new IPsec tunnel from scratch with the new IP address. MOBIKE allows to update the IPsec SAs (SPD, SAD and PAD) and IKE SAs (information contained in the IKEv2 application). Both peers need to agree on MOBIKE protocol support at the begging, which is is done during IKE AUTH exchange of IKEv2 (see figure 2.8). When lower layers detect that a new IP address is present in the currently used interface, the peer updates its IKEv2/IPsec databases and it sends an INFORMATIONAL message including a notify payload UPDATE SA ADDRESSES. When the other peer receives this message, it updates its IPsec SAs and IKE SAs as well.

MOBIKE -mobility extension for IKEv2

MOBIKE also offers some multihoming features. It allows to built, under priority order, a list of IP addresses where an endpoint is reachable. When connection is lost through the currently used IP address, the other endpoint can reach the peer through the second IP address on the list, then the third, and so on. Servers with more than one network interface can offer this feature. The notify payload which agreggates an IP address is ADDITIONAL IP4 ADDRESS

REDIRECT extension for IKEv2

I n i t i a t o r (MN)

Responder (SG) ----------------------------------------------------------------- ------------------------------------------------------------------

REDIRECT extension for IKEv2

The REDIRECT mechanism is an extension of the Internet Key Exchange protocol (IKEv2) defined in [START_REF] Devarapalli | Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)[END_REF]. It allows a Security Gateway to redirect the traffic flow to another Security Gateway (SG). Therefore, if a SG is being shut down for maintenance, it is possible to REDIRECT the VPN clients to another SG.

A peer can explicitly inform the other peers that it supports the REDIRECT mechanism by adding a notify payload during an IKE SA INIT or INFORMATIONAL exchange. Figure 2.9

shows the details during an exchange. -----------------------------------------------------

I n i t i a t o r (MN) Responder (SG)

Conclusion

ISPs are mainly using IPsec Virtual Private Networks (VPNs) to extend a security domain over untrusted networks. End-Users may secure their communications with theirs ISPs by establishing an IPsec tunnel with a Security Gateway. Hence, ISPs are called to offer higly reliable services with IPsec Security Gateways. On the other hand, an operator might want to migrate an IPsec session from one SG to another for several reasons (e.g. offload, mobility, failure predictive actions, avoid re-authentication, cloud service topologies, among others).

Considering the evolution of mobile networks through the past ten years, ISPs need to face new challenges in terms of security. EUs are increasingly prone to mobility or multihoming operations. In addition, the new cloud services introduce more challenges in order to offer better QoS, as well as high availability to those contents that the EUs want to access wherever they need to.

Throughout this chapter, we introduce the notions of IPsec. Two entities wishing to establish a secure communication, may use the IPsec suite together with the IKEv2 protocol in order to authenticate and encrypt their exchanges.

Further explanations introduce some mechanisms that addresses new challenges facing mobility, multihoming and clustering at the IPsec layer. For example, we briefly introduce ClusterIP (see 2.5), REDIRECT (see 2.7) and MOBIKE (see 2.6) exentions, which improves the performances facing mobility, overload and multihoming issues of IKEv2/IPsec tunnels.

Finally, these mechanisms are also extensively discussed later in chapter 6.

Chapter 3

IKEv2/IPsec Context Definition

Introduction

Operators are mainly using IPsec Virtual Private Networks (VPNs) to extend a security domain over untrusted networks. A VPN is usually established when an End-User (EU) and a Security Gateway (SG) negotiate some parameters referred as Security Associations (SA). For a better QoS, these SGs are geographically distributed so they are as close as possible to EU.

As such, the higher is the level of responsibility of a SG, the higher is the risk to be overloaded and to break down.

This chapter introduces the definition of an IKEv2/IPsec context. When two nodes establish an IKEv2/IPsec-based communication or VPN, a set of parameters are agreed by both extremities of the VPN. In order to secure their IP traffic, some cryptographic information is built on both sides of the tunnel.

Initial exchanges first agree on a secure channel also called IKE security association (IKE SA). This IKE channel permits IPsec entities to negotiate and maintain some security parameters known as IPsec Security Associations (IPsec SA). An IPsec SA consists in some shared information used to secure the IP communications between both extremities of a VPN.

Throughout this chapter, we will also present our investigations related to the extraction (commonly cited as GET) and re-installation (referred as PUT) of an IKEv2/IPsec context.

Notice that both the IKE SA and the IPsec SA are referred together as IKEv2/IPsec context, which is simpler an easier for readers. On the other hand, all the developments of our implementation are done within strongSwan, which is an open source VPN software for Linux environments.

This chapter introduce a mechanism for extracting and reinstalling security associations (both IKE SA and IPsec SA), as well as a mechanism to transfer a given IPsec traffic from one SG

Motivation

IPsec provides a security framework at the network layer allowing IP and upper-layer protocols to benefit from encrypted and authenticated communications. They are mostly used to secure peer-to-gateway or gateway-to-gateway communications (see 2.1 and 2.2), or VPN (Virtual Private Networks). When providing VPN services based on IPsec, an End-User (EU) commonly makes use of the IKEv2 protocol [START_REF] Kaufman | Internet Key Exchange Protocol Version 2 (IKEv2)[END_REF] to negotiate IKEv2 security associations (IKE SAs) and further IPsec security associations (IPsec SAs) towards a security gateway (SG). Figure 2.5

illustrates the tunnel establishment and different exchanges.

In order to reduce delays and improve communications, the path between an EU and the SG should be as short as possible. As such, operators may rely on geographically distributed pool of SGs to provide a high QoS. On the other hand, an operator that offers fail-over capacities should be able to transfer VPN sessions from one SG to another. Motivation may be to spread the workload among different SGs, as well as to provide high availability features in case a SG fails.

The scenario we are considering is an EU that sets up a VPN towards an SG (e.g. SG1) which gives access to a trusted network. The EU is first authenticated by using IKEv2 protocol with either pre-shared keys, EAP-AKA, EAP-SIM, certificates, etc. Then, further IKEv2 exchanges allow to set up the VPN (i.e. IKE SAs and IPsec SAs). At a given time, SG1 is overloaded, whereas some other SGs are not (e.g. SG2). The operator wants to move this VPN session from SG1 towards SG2, so it transfers all the IKEv2/IPsec context. The main goal of transferring all

IKEv2/IPsec Context Detailed Description

The IKEv2/IPsec context contains all the information negotiated through IKEv2 protocol as well as all the information contained in the IPsec databases. Most of the current operating systems implement the SAD and SPD in the kernel while the PAD is mostly a database that exists in the userland space. The SAD, SPD and PAD are defined as follows:

-Security Association Database SAD: contains all the information related to each unidirectional IPsec SA (SPI, concerned protocols, SA's lifetime, algorithms, keys, etc.).

-Security Policy Database SPD: defines how the packets that match the IPsec policies are handled by the device: PROTECTed, BYPASS or DISCARD IPsec.

-Peer Authorization Database: links the SPD with the key management protocol (i.e.

IKEv2

). This database determines if an identity is allowed or not to establish a VPN with the device.

The Security Associations (SAs) contained in the SAD can be configured manually, but this is obviously not scalable when big amounts of IPsec connections are established with different devices. Thus, IKEv2 (see [START_REF] Kaufman | Internet Key Exchange Protocol Version 2 (IKEv2)[END_REF]) is the protocol that sets a secure channel (a. -Cryptographic algorithms: algorithms to protect further IKE exchanges, a Diffie-Hellman Group and a pseudo-random function.

-SKEYSEED: secret key from which all keys are derived for that IKE SA (i.e. SKe encryption key to ensure confidentiality, SKa authentication key to ensure integrity and SKd derivation key master secret that will be used to compute further CHILD SAs keys).

-IKE SPI: IKE SPI stands for IKE Security Parameter Index. It uniquely identifies an IKE SA.

-Lifetime: duration of an IKE SAs. -Message ID counters: the ID counters provide anti-replay for IKEv2 exchanges by increasing the ID counter by one for every emitted IKEv2 message.

-IKEv2 window size: if the window size has a value of "N", it implies that there can be N un-acknowledged IKEv2 requests at any given time during communication.

During the Phase 2 of IKEv2, the INITIATOR sends a IKE AUTH request and the RESPONDER replies with an IKE AUTH response. Now, the nodes consult their PAD in order to authenticate each other. As mentioned, the PAD determines if the identity of a given node is allowed or not to establish a CHILD SA. The PAD is composed of the following information:

-Identifiers: IDi (INITIATOR ID) and IDr (RESPONDER ID). Usually an IPv4/IPv6 address, a fully-qualified domain name, an email address,etc.

-Authentication Method: pre-shared key, EAP, certificates, RSA, etc.

The establishment of the CHILD SA (negotiation of parameters stored in the SAD and SPD) is piggybacked during the IKE AUTH exchange. It is done just once the authentication and the authorization are performed. When Phase 2 is done, both nodes agree on the following parameters of their CHILD SAs:

Concerning the SAD -CHILD SA SPI: a 32 bits unique identifier of the CHILD SA.

-IP addresses: source/destination IP addresses of the IKEv2 compliant nodes.

-IPsec Protocol: AH (Authentication Header) or ESP (Encapsulating Security Payload).

-Sequence number counter: value to control every incoming/outgoing IP packet protected with IPsec, preventing replay or unauthorized re-injection of already processed IPsec traffic.

-Anti-replay window size N: any packet with the sequence number X + N is discarded, where X is the awaited sequence number.

-ESP/AH information: Encryption and/or authentication algorithms, keys, initialization values, key lifetimes.

-Lifetime: time interval or byte count after which a SA must be replaced with a new SA (and new SPI).

-IPsec Protocol Mode: tunnel or transport mode.

-Path MTU: maximum size of an IPsec packet that can be transmitted without fragmentation.

Concerning the SPD

-IPsec Protocol Mode: tunnel or transport mode.

-Header's IP Address: source/destination IP addresses of the IKEv2 compliant nodes.

-Source/Destination IP addresses of the communications: if transport mode is being used, these addresses are the same as those used for routing purposes, whereas in tunnel mode these IPs concern the end-points of the communications (which could be an internal IP address of a protected subnet).

-Upperspec: upper-layer protected protocol (HTTP, FTP, HTTPS, among others).

-Policy rules: DENY, BYPASS or PROTECT the targeted traffic. The IPsec-CXT between two SGs can be performed with CXTP protocol (see [START_REF] Loughney | Context Transfer Protocol (CXTP)[END_REF]), mobility operations (e.g. MOBIKE) or with REDIRECT extension of IKEv2. However we will first concentrate in just extracting and re-installing the IKEv2/IPsec context before its transfer. The transfer of an IKEv2/IPsec context is discussed in detail in chapter 4 and 6.

In order to improve the management of an IKEv2/IPsec , we initially define two operations:

GET and PUT. GET extracts the IKEv2/IPsec context for a given tunnel, whereas PUT makes installation of it. Details of an IKEv2/IPsec context are described in [START_REF] Palomares | Mechanisms to Ensure Continuity of Service for IPsec/IKEv2 Based Communications[END_REF].

Implementation

Our implementation is based on StrongSwan 4.5.0 [START_REF] Steffen | the OpenSource IPsec-based VPN Solution: StrongSwan[END_REF], a widely used IKEv2 open-source implementation for linux environments. Its multi-threading design meets today's requirements.

As IPsec is a complex protocol, strongSwan has a very modular style. A daemon called starter initializes the IPsec framework and launches the different daemons defined through configuration (whether to perform encryption/authentication or not). This daemon is initiated as a thread, a master daemon creates simultaneous processes and feeds them with different information. A data bus is created in order to interact with the user interface. This data bus is called stroke, and it interacts with charon. Thus, this is how strongSwan works as a highly parallelized application.

StrongSwan is configured through the following files:

strongswan.conf defines the parameters of strongSwan at launching time.

ipsec.conf stores the configuration concerning each CHILD SA (i.e. how the connection must be secured).

ipsec.secrets defines the PAD which contains the parameters required to authenticate the peers. It also contains information related to the private keys and the methods to perform authentication.

StrongSwan can be launched through command-line interface with root privileges as follows: ipsec start. Once strongSwan is launched, a tunnel is initiated by running the command ipsec up <conn-name> (<conn-name> is the name of the session as in the configuration files).

We implemented two functions in order to successfully recover a whole IKEv2/IPsec context.

That is, we GET a context and store it into a plain text file. We also implemented a function to PUT (re-install) an IKEv2/IPsec context into a SG directly from the previously stored plain text file (see figure 3.1 to observe the graphical representation). Both GET and PUT functions are implemented in strongSwan, which communicates with the kernel through the Netlink XFRM API in linux. This API has recently been modified in order to solve issues concerning the IPsec replay sequence counters synchronization. Netlink XFRM allows to modify these counters at any time in order to synchronize them. This feature is very useful when clustering security gateways. On the other hand, the lookup of the IKE SA and CHILD SA inside strongSwan is done through its connection name (we refer to it as "<conn-name>" in the examples): the command ipsec get <conn-name> performs GET whereas the command ipsec put <conn-name> performs PUT.

ipsec get <conn-name>: The command ipsec is intercepted by the strongSwan daemon.

The command get launches the function that recovers the IKE SA + PAD + CHILD SA.

The lookup of the IKE SA and its corresponding CHILD SA is done through its name "<conn-name>". Finally, it creates a plain text file in the temporary directory (/tmp/) with all the information.

ipsec put <conn-name>: The command ipsec is intercepted by the strongSwan daemon.

The command put launches the function that installs the IKEv2/IPsec recovered context from a plain text file. The IKE SA and CHILD SA are introduced in strongSwan with the name:"<conn-name>".

Testbed

Our platform is composed of two desktop stations. Both operating systems run over Ubuntu (v12.04LTS in the IPsec EU, and v11.10 in the SG). Our tests are performed locally on the same SG and permit to test the interaction with the IPsec stack.

First of all, we focused on measuring the time to establish a single VPN session towards a SG. Then, we increment the number of VPN session to perform load tests on the platform. We also measure how an interruption of service at the IPsec layer impacts upper-layers transmissions (like HTTP). For example, refer to figure 3.5a to see in details all the exchanges while performing GET and PUT at the IPsec layer during and HTTP download. We focus in studying the impact of this interruption. Tests are performed with HTTP traffic over Ethernet links.

The results are represented in graphs with a box-and-whiskers style (also called quartiles). This kind of representation is mostly used to plot statistical data. For every measurement made (around 100 samples per measure), the box-and-whisker figure indicates: (i) the smallest observation, (ii) the lower quartile, (iii) the upper quartile, (iv) the largest observation and (v) the median. The space between the lower and upper quartile represents 50% of the samples (see

figure 3.2).
During the tests, we used Traffic Control in order to vary the bandwidth limit during the HTTP download and thus study the impact over different transmission rates. To generate statistical results, 100 measurements were done. The tests have been measured by using the command time, which writes a message to standard output giving timing statistics about this program run. The outputs of time are (i) the elapsed real time between invocation and termination of the command, (ii) the user CPU time and (iii) the system CPU time. We considered the value of the elapsed real time in order to evaluate our stats results. For simplicity, we will refer to elapsed real time as time. This is how we measured the time it takes for a given command to run.

Performance tests & Results

Performance tests & Results

The different testbed measurements are performed over Ethernet links (some of them with different bandwidths). We load the SG by establishing different numbers of VPN tunnels for each TCP connection granulated by its port number. For example, a TCP connection using port 80 will not traverse the same tunnel as a TCP connection using port 81. They will use different cryptographic material and thus different IKEv2/IPsec tunnels.

First Test -VPN Establishment Time

The first test measures the time for establishing IKEv2/IPsec tunnels between two end-points (see figure 3.3). The tunnels were initiated one after the other to avoid half-opened IKE-SAs. This is not a stress test but a load test. Figure 3.3 gives the results for initializing 10, 100, 200, 300, 400, 500, 700 and 1k tunnels. We can clearly see that the time measured is proportionally higher as the amount of VPNs rises. Establishment of 10 tunnels takes 0.31s to 0.41s, whereas 1000 tunnels may take 0.89s up to 1s for a single VPN establishment. All the other measures (i.e. 100, 200, 300 tunnels ...) show results between 0.3s and 1s for a single VPN establishment. VPNs) takes more likely 13ms-15ms to perform a GET over a single VPN whereas for a not loaded SG these times are around 5ms up to 12ms. This dispersion can be explained due to the semaphores for controlling access to an IKE SA. This means that an IKE SA can be in use by any process within strongSwan, and thus increasing the time to GET the desired IKE SA. Then, we proceed to PUT these ten [START_REF] Allard | An application of the context transfer protocol : IPsec in a IPv6 mobility environment[END_REF] previously randomly chosen VPNs for each scenario (10,100,200...). The time that the script takes to PUT these connections is divided by ten [START_REF] Allard | An application of the context transfer protocol : IPsec in a IPv6 mobility environment[END_REF].

Second Test -GET and PUT Times

Performance tests & Results

This results in the average time to PUT a single VPN active session. Figure 3.4b shows the measurements concerning the PUT function for all the scenarios. It represents the time that a SG takes to install a single IKEv2/IPsec context from a file. We observe that strongSwan takes a range of 2ms up to 22ms to perform a PUT of a single VPN.

Third Test -Upper-layer's Reactivity

We observed the reactivity of upper-layer protocols facing interruptions at the IPsec layer on SG's side. The test consists to GET and PUT a single VPN connection during an HTTP download.

We perform this with different traffic rates (controlled with Traffic Control implementation for 3.6. How can we transfer an IKEv2/IPsec context? linux [START_REF] Devera | HTB Linux queuing discipline manual -user guide[END_REF]). Figure 3.5a illustrates a protocol representation of what happens during this test.

Initially, a VPN is established between an EU and the SG. Then, we start an HTTP download by using the command wget. The source file is placed on the EU's side whereas the SG is configured as the destination. Even if in real life, an EU (and not the SG) is usually the destination when downloading files from the Internet, we chose this methodology in order to analyze the impact of a SG facing interruptions at the IPsec layer. Thus, after the download has been performed during five (5) seconds, we GET the whole IKEv2/IPsec context on the SG, causing it to loose connectivity with the peer. The EU continues to send ESP packets as it is unaware of the GET function performed on the SG side. We considered different interruption times (T S Time Sleeps of 10, 30 and 60 seconds) before performing a PUT function. Finally, once the IKEv2/IPsec context is reinstalled, we observed the time to finish the HTTP download. As we carry HTTP traffic over an IPsec protected communication, we set the HTTP parameters through wget to be as flexible as possible facing interruptions. Also, as we measured different traffic rates during the downloads, we changed the size of the file being downloaded (because big size files would take too much time to download at lower rates). Table 3.1 shows the different file sizes used for each traffic rate. 5c and3.5d) shows the download times for each interruption T S . We observe that at lower traffic rates (less than 3000kB/s), the measures are very stable because the quartiles are very thin. For higher traffic rates (more than 3000kB/s), the download time is unstable and so the quartiles are more spread and thicker. On the other hand, the three graphs have a similar behavior. Even though they are all offset by their corresponding interruption time. Finally, this test represents the impact of the interruption at the IPsec layer during an active session.

How can we transfer an IKEv2/IPsec context?

There are different approaches for transferring an IKEv2/IPsec context:

-RFC4067 Context Transfer Protocol (CXTP) [START_REF] Loughney | Context Transfer Protocol (CXTP)[END_REF] introduces a generic mechanism that allows context transfer between SGs. In our scenario, Context Transfer Protocol (CXTP) is the protocol we could use to transfer an IKEv2/IPsec context between Security Gateways whatever the context is. One issue when using CXTP under this scenario is that the EU is actually involved during the SG migration, thus increasing the number of messages exchanged between the EU and the IPsec SG. CXTP can be triggered by one of the SGs (network controlled) or by the EU itself (mobile controlled, or controlled by the EU). In both cases, a message named CTAR (Context Transfer Activate Request) must be sent from the EU towards one of the IPsec SGs during the context transfer.

-Mobility Related Documents: [START_REF] Eronen | IKEv2 Mobility and Multihoming Protocol (MOBIKE)[END_REF] and [START_REF] Migault | MOBIKE eXtension (MOBIKE-X) for Transport Mobility and Multihomed IKE SA[END_REF] address EU's IP mobility and multihoming (this is clarified in 1.3). When an EU changes its IP address, the IKEv2/IPsec contexts are no longer valid and the EU looses connectivity. An IKEv2 INFORMATIONAL exchange allows all concerned SAs to be updated and thus let the node remain connected and protected with IPsec. This might be confusing with IPsec-CTX except that IPsec mobility concerns the same SG, whereas IPsec-CTX concerns different SGs. However, mixing IPsec-CTX with mobility operations can be an approach to transfer an IKEv2/IPsec context. We will consider this in chapters 6.

-Allard [START_REF] Allard | IKE Context Transfer in an IPv6 Mobility Environment[END_REF] addresses the IPsec context transfer between two Security Gateways with an implementation using IKEv1 and CXTP protocol. In contrast, our work is positioned using IKEv2, which involves differences compared with IKEv1 (see section 2.3.1 in [START_REF] Frankel | IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap[END_REF]): less signaling, mobile friendly ( [START_REF] Eronen | IKEv2 Mobility and Multihoming Protocol (MOBIKE)[END_REF] and [START_REF] Migault | MOBIKE eXtension (MOBIKE-X) for Transport Mobility and Multihomed IKE SA[END_REF]), better performance and less complexity.

-RFC5685 Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) [START_REF] Devarapalli | Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)[END_REF] proposes an extension to IKEv2 which redirects an IKEv2/IPsec session from one gateway to another. It does NOT pre-authenticate the EU prior to the connection towards a new Security Gateway (SG). The EU needs to renegotiate a new SA with the new SG.

Conclusion

We introduced the IKEv2/IPsec context and we proposed a mechanism to dynamically GET and PUT an IKEv2/IPsec context using strongSwan. We studied through a real implementation the time to establish an IKEv2/IPsec session, as well as we measured the time to extract and re-install a security context. Finally, we measured the impact for upper-layers through different interruption times at the IPsec layer during an HTTP-based download. We show the impact of GET and PUT fucntions locally. Following chapters will consider measuring the impact of the transfer of an IKEv2/IPsec context between physically different SGs. Additionally, for the use We concentrate on how to build a cluster of SGs based on a HA plugin designed by strongSwan, which uses a target extension of iptables for Linux-based systems (ClusterIP). We describe the main issues to overcome HA within IPsec. We also measure how HA events may affect the EU experience, and provide recommendations on how to deploy ClusterIP. During an active IKEv2/IPsec tunnel, we simulate a failure on the active SG and evaluate the impact over upper-layers while the ClusterIP mechanism automatically switches from the active SG to the passive SG.

Note that the IP address remains the same while transferring an IKEv2/IPsec context in a Mono-LAN environment, these actions are transparent to End-Users. They are actually interpreted as a simple interruption of the communication and no signaling is needed between the End-User and the SG. It is important to distinguish a mobility event from an IPsec context transfer due to a failover. We have already discussed this in 1.3, but we give more details in this chapter. In fact, a mobility means that an EU changes the outer IP address of the IPsec tunnel but the IKEv2/IPsec parameters remain in the same nodes. On the other hand, during a failover event, all the previous negotiated IKEv2/IPsec parameters must be transferred towards a new SG which ensures the continuity of a VPN session.Thus, the affected EUs attaches a new SG.

We concentrate on the methods that ensure IPsec availability as well as the continuity of an IPsec service. This mainly involves the transfer of a tunnel between different SGs. We also evaluate how an EU is affected when this happens.

The scenario we consider is an EU that wishes to reach an HTTP server placed within a trusted network protected by a SG. The EU first establishes a VPN towards a SG in the trusted network. Hence, the SG authenticates and protects the traffic between the EU and the HTTP server. We use strongSwan [START_REF] Steffen | the OpenSource IPsec-based VPN Solution: StrongSwan[END_REF] to establish these tunnels. In order to provide HA capacities, we use ClusterIP, allowing to build a cluster of SGs that share a common IP address without having a physical machine to perform this task. Thus, each SG determines from the incoming packets whether it is responsible for it or not.

Test-bed

Our testbed consists in a cluster of two SGs configured with a common IP address. When a EU establishes a VPN towards the cluster, one of the SGs is considered the active SG, whereas the other member is considered the passive (also known as stand-by SG). The active SG is the one that takes responsibility of the tunnel, whereas the passive SG is waiting to become the newly

Position of our Work & Related Work

Concerning High Availability within IPsec, there exists similar works and approaches:

-Yu [START_REF] Yu | An ipsec seamless switching mechanism with high availability and scalability by extending ikev2 protocol[END_REF] proposes to solve availability issues on IPsec by simulating a cluster mechanism for IPsec gateways. As far as we know, this is the only article that addresses similar issues.

Its seamless switching mechanism aims to spread SAs among both active and passive SGs.

The author does not recommend a High-Reliable link between SGs in order to communicate the SAs, but the article mentions that the members of the cluster could be deployed in different network segments. The seamless switching process consists of adding a notify payload during the IKE AUTH exchange in order to establish two tunnels (one VPN towards the active SG and a second stand-by VPN towards the passive SG of the cluster).

The passive SG receives the IPsec information from the responsible active SG and installs a passive VPN towards the EU. Finally, there is also a mechanism of seamless switching to transparently change from the active-to-passive SG and to synchronize ESP replay sequence number. On the other hand, the case of a heavily loaded SG is not considered.

The results are based on simulations and not in real implementation. By contrast, our

IKEv2/IPsec and High Availability Constraints

IKEv2 and IPsec were primary designed for static configurations. The IKEv2/IPsec contexts have been designed to remain installed in the same device during a session or VPN tunnel establishment. However, todays requirements demand facilities to profit from mobility, handover, offload or even VPN session migration between SGs. This situation leads often to new extensions. For example: MOBIKE extension for mobility [START_REF] Eronen | IKEv2 Mobility and Multihoming Protocol (MOBIKE)[END_REF], MOBIKE-X draft for mobility and multihoming [START_REF] Migault | MOBIKE eXtension (MOBIKE-X) for Transport Mobility and Multihomed IKE SA[END_REF] [37] [START_REF] Migault | Multiple Interfaces IPsec Security Requirements[END_REF], CXTP and mechanisms to transfer security contexts [START_REF] Loughney | Context Transfer Protocol (CXTP)[END_REF] [11] [START_REF] Palomares | Mechanisms to Ensure Continuity of Service for IPsec/IKEv2 Based Communications[END_REF] or a High Availability protocol to synchronize counters [START_REF] Singh | Protocol Support for High Availability of IKEv2/IPsec[END_REF].

The huge demand on mobile data have increased the demand on system's availability. This Even though the amounts of IKE messages do not represent as much traffic as the IPsec traffic, the synchronization of messages ID is critical due to the very strict control of the IKE SAs when setting up a VPN tunnel and a very narrow window size.

IKEv2/IPsec Counter Synchronization

The IKEv2/IPsec suite aims to protect IP traffic. However, IKEv2 and IPsec act at different layers. IKEv2 is an application layer protocol which queries and responds to port 500 and 4500 in order to negotiate a secure channel between two endpoints sharing an IKE Security Association (IKE SA). On the other hand, IPsec is a protocol that takes place at the IP layer and protects the traffic according to IPsec Security Associations (IPsec SAs) policies, which are previously negotiated through the IKE SA secure channel. All IKEv2 exchanges consist of a request-response pair of messages. It is mandatory to retransmit a request until it has been acknowledged. The IKEv2 window mechanism allows to send some IKEv2 requests without receiving a response, but once the window's limit is achieved, the oldest request MUST be acknowledged resulting in a window increase by one. This window is managed through the IKEv2 counters called: Message ID. Each IKEv2 message header includes its corresponding message ID, so that IKEv2 can strictly control the window as well as all unacknowledged messages. When the message ID is n and the window size is w, only IKEv2 messages between n + 1 < Message ID < n + w can be processed. If no acknowledgment is received after a long period of time, then the IKE SA is deleted. The anti-replay parameter of the IPsec Security Association is called sequence number counter. When the Anti-Replay service is enabled, it controls every incoming/outgoing IP packet protected with IPsec. Note that IPsec ALLOWS a sender to skip forward by sending a higher sequence number. Remember also that a duplicated usage of a sequence number is forbidden.

Thus, when the sequence number counter is n and the window size is w, any message with sequence number < n -w + 1 will be discarded. A big window size (E.g. 1024) means that a node is capable to handle a bigger range of packets that arrive out of order. On the other hand,when sequence number = n and the window size is very little (E.g. w = 1), the node is capable to remember only the last sequence number. The following packet MUST have a value sequence number > n -1 , otherwise the packet is dropped.

The biggest challenge concerning IPsec when implementing cluster of IKEv2/IPsec SGs is:

Stale Sequence Number value: when a passive SG takes responsibility and becomes the newly active SG, it may happen that the sequence numbers are out of date. Figure 4.1b illustrates this situation. This occurs when the newly active SG starts sending IPsec protected packets with staled sequence numbers, implying that the EU rejects all the duplicated packets due to anti-replay protection of IPsec. Instead, note that IPsec allows to increase these sequence numbers without preventing the EUs, and the communication would not be interrupted.

There are three ways to avoid sequence number values. First, in the case that the newly active SG keeps an IPsec session from another SG, it may send an IKEv2 message to the EU in order to update both the Message ID and the sequence number value. However, this solution requires to create a new notify payload and thus to modify the IKEv2 protocol itself.

Indeed, [START_REF] Singh | Protocol Support for High Availability of IKEv2/IPsec[END_REF] proposes this method of resynchronization.

The second approach is a client unaware method. It consists in creating a cluster of IPsec SGs which maintain synchronized Message ID values as well as sequence number values. These latter can be synchronized by implementing ClusterIP (see section 4.5.2).

The third approach concerns the sequence number values only. When a newly active SG takes responsibility of a tunnel, it may skip a big number of sequence number values and the IPsec session will still not be interrupted. Note that the IPsec protocol allows both endpoints

Clustering Methods for IPsec

to skip some sequence number values without prior agreement.

Clustering Methods for IPsec

This section positions Load-Balancing facing High Availability, details how takeover may impact the client and finally describes ClusterIP configuration and operation with IPsec.

Load-Balancing Versus High-Availability Clusters

A Load-balancing cluster is a set of nodes where more than one of the members may be active at the same time. Load-balanced clusters are implemented by sharing the workload between cluster nodes and offering better performance. HA-clusters operate by having redundant nodes intended to provide a service when other node fails. For Linux, the latter has been implemented using a free software package developed by the Linux-HA project, having the heartbeat software as the main product. Heartbeat automatically monitors resources so that they can be restarted or moved to another node on failure.

ClusterIP Implementation

When using a ClusterIP approach, no special hardware is required to benefit from Load-Balancing. Indeed, ClusterIP is intended to provide load-balancing features without having a load-balancer. The configured members of the cluster does share a multicast MAC address and thus receive the same packets. Then, a lower-layer mechanism (netfilter code) on each node, filters packets by calculating responsibility through an algorithm (E.g hashing the IP source of each packet). When applied, ClusterIP acts as a parameter for the iptables command.

The nodes in a cluster usually have two Network Interface Cards (NIC). One of the NIC's MAC address is replaced by the shared cluster MAC address and then a common virtual IP address is mapped onto it. The other NIC, being completely independent, can be used for any other purpose, as for example inter-nodes communications (e.g. heartbeat mechanism). Given the case where a machine counts with only one NIC, it is also possible to install a second virtual IP address on the same interface. Concerning the anti-replay counters, every ESP/AH protected packet carries a sequence number that cannot be reused since the anti-replay feature would consider it as an attack, leading to drop all the packets and issuing attack warnings. Synchronizing anti-replay IPsec counters is not reasonable neither, due to the high load introduced (for each packet emitted).

As a result, the designed solution synchronizes the counters every n-th packets (10.000 packets).

This choice is justified since skipping sequence numbers is allowed in IPsec, and highly reliable delivery service (as in IKEv2) is not provided.

StrongSwan's ClusterIP-based HA Plugin

StrongSwan is a complete OpenSource IPsec-based VPN Solution for Linux operating systems.

IKE Daemon Implementation

Daemon Hooks: a hook is a function that is in charge of collecting information (in this case Synchronization data) for later use in preparing messages that are going to be sent to other members in the cluster in order to notify SA state changes or pushing information towards the plugin. Hooks are created and registered by the plugin at the daemon bus. The results are represented in graphs with box-and-whiskers style [START_REF] Wikipedia | Boxplot -Wikipedia The Free Encyclopedia[END_REF] (refer to section 3.

First Test -ClusterIP overhead Measurements Test

The purpose of this test is to evaluate how much CPU resources and time the modified ClusterIP adds to the whole VPN service. Note that when the HA plugin of strongSwan is activated (i.e. B.2a), for each incoming packet the modified ClusterIP hashes the IP header to check whether or not the SG is the responsible node to handle that packet. This test is performed using both topologies described in figures B.2a and B.2b, thus comparing the impact of ClusterIP. The test consists of downloading a file of 1GB from an HTTP server (placed behind the SG) towards the peer by using the command wget on the peer's side. During the tests based on figure B.2a, the HA plugin is enabled whereas during tests as in figure B.2b the HA plugin is deactivated. We measured the CPU impact and the time spent by the system to complete an HTTP download (using the wget command). The IKEv2 exchanges are always protected with AES128-SHA1, whereas two different algorithms for ESP encryption were also analyzed throughout the test: AES128-SHA1 and NULL-SHA1 (where NULL means no encryption, note that strongSwan does not support no integrity check and it is always SHA1). We also varied from one (1) to four (4), the number of CPUs available on each SG; this allows analyzing the evolution of the CPU consumption of both types of encryption.

As mentioned in 4.7.1, the CPU consumption and the download time (user and system time) are obtained through the top and time command respectively. on the download time and the impact of the encryption method used during these downloads.

When no HA-plugin is used, AES-128 encryption introduces more System Time than when NULL encryption method is used. The System Time and the Elapsed Time (total time to complete the download) increase by 11% using AES128. However, no variation is observed in the User Time, which means that the operating system always performs the same user mode tasks. Note that the modified ClusterIP requires the kernel to be patched in order to allow IPsec packet filtering. No variation of the User Time was observed when using the HA-plugin.

It always stayed around 1s in all scenarios of the first test. Finally, when comparing the impact of the encryption methods showed that a cluster with AES128 takes around 30% more time to download than a download that uses NULL encryption.

Second Test -QoS on an HTTP connection

The On the other hand, differences are observed when the HA-plugin is activated. The fact to decide either to treat or not a packet (by filtering at the IP layer), increases the System Time by 35%. Also the Elapsed Time increases by 25%, which introduce some overhead. Throughout this test, the fact of using 1,2,3 or 4CPUs did not impact noticeably the download time. For example, figures 4.5a and 4.5b show that the behavior of the download time is very similar for each CPU scenario. Finally, as we can see, upper-layers might be impacted when this HA feature is activated. Administrators wanting to implement a cluster of VPN SGs should justify the need for this solution. A typical example is an environment where thousands of tunnels should be established, so letting the cluster to spread responsibility over different nodes, and thus spreading the load on each SG. Even if the load for a single connection would be slightly higher by using the HA-plugin, a real positive impact would be noticeable only when a large number of VPN connections are spread among the cluster members.

Third Test -Interruption Time of an HTTP communication

When a failure event occurs, the ClusterIP module used by strongSwan allows the cluster to switch transparently from the active node to the passive SG node. We concentrate on evaluating the handover network time (see figure 4 Note that the handover time (at the right-bottom and right-upper side) are illustrated with three vertical lines that represent the lower quartile, the median and the upper quartile. The handover time with no traffic control varies from 1.63s to 1.66s (right-bottom figure). This time is considered as network-friendly time to perform a fail-over. However, the difference between the download time on both scenarios (with and without fail-over) stays over 3s, 1.7s, 3.2s, and 3.1s for 1,2,3 and 4CPUs respectively. This overhead or difference is due to updating the IPsec databases. An update action is blocking the database and thus blocking the communication.

This delay is expected to increase as the number of tunnel increases. Upper-layers treatment add more delay to the communication as well the system also takes some time in order to accomplish all tasks. The results are compliant to the expected 1s to 3s performances as required in strongSwan's specifications. We also tested an additional Handover Time where the bandwidth limit is imposed to 2M Bps, emulating the use case of a RAN (Radio Access Network). Once again, the network fail-over time remains between 1.9s and 2.3s. The reason is that with reduced rates, the platform is not overloaded. The impact of the number of CPUs cannot be measured because, the time between heartbeat exchanges are dominant. Nevertheless, the No Failover case (colored in red), shows that the ClusterIP module has better performance when 1CPU or 4CPUs are being used. In terms of QoS, it should be considered only to use 1CPU or 4CPUs , instead of 2CPUs or 3CPUs.

Conclusions

Throughout this chapter, we measured the impact and performance of using a modified ClusterIP module in order to clusterize SGs over IPsec. The availability of the IPsec service is improved thanks to the hot-standby clustering ensured by ClusterIP. Also, strongSwan guarantees the continuity of an IPsec session thanks to its HA plug-in allowing to spread all the IPsec tunnels among its cluster members. Results showed that an active SG spends 5% to 8% of CPU more than a passive SG when clustering IPsec tunnels. We also observed that there is an additional load when using the HA-plugin of strongSwan among the cluster members. Downloading a 500M B file takes 20% more time when using ClusterIP and the HA plug-in.

As such, an administrator willing to implement this solution should take into account the performance costs of adding HA features to its VPN service. Furthermore, one main drawback of ClusterIP is its limitation to be deployed within a same network segment. Chapter 5 will concentrate on using our own VPN tunnel management tool Chapter 5

Mono-LAN Context Transfer: Context Management

This chapter addresses the IKEv2/IPsec context transfer between different SGs within a Mono-LAN environment. Instead of using the HA plugin of strongSwan based on ClusterIP, we consider using our own developments. We manage the VPN connections dynamically through GET and PUT functions (introduced in section 3.4). As such, we explain how to perform GET and PUT between two different machines in a Mono-LAN environment.

We evaluated the impact on upper-layers when moving an IKEv2/IPsec context from one SG to another with the same IP address during an active IKEv2/IPsec session. First, we introduce our own HA module under Mono-LAN environments. Then, we concentrate on our developments allowing to dynamically move a VPN tunnel between different SGs (referred to as Context Management introduced in 1.2.2).

Notice that, as we address a Mono-LAN environment again, the IP address remains the same while transferring an IKEv2/IPsec context. Thus, the transfer is also transparent to End-Users.

As such, the transfer is perceived as an interruption of the communication and no signaling is needed between the End-User and the SG.

Motivations and Mono-LAN Context Management

The management of large VPN clusters requires the conjunction of different mechanisms aiming to provide a fluid VPN service. First, the load balancing features are present when the VPN sessions are spread among different cluster members based on a predefined algorithm or some trigger event (i.e. overloaded SG). However, the cluster members must be able to communicate and synchronize the information and parameters of those VPNs sessions needing to switch to another equipment. Second, the High Availability features are present when some SG within the 70 5.2. Scenarios: HA and Context Management cluster fails and some other SG (or several SGs) assume responsibility of the affected connections concerned by the failure. This might result in a re-organization of VPN sessions among the other cluster members. Nevertheless, this is also subject to an algorithm that decides whether a VPN connection might be handled by a specific SG or not (i.e. closest SG, better QoS, lower pricing rate, etc.).

In chapter 4, we observed that the strongSwan's plugin (based on ClusterIP) provides HA and load-balancing features but no context management facilities. On the other hand, as ClusterIP spoofs ARP requests, it is limited for deployment within a same network segment. This limits the deployment of VPN clusters where the members are separate geographically.

We intend to show why it might be advantageous to be able to migrate a VPN session of node from one SG to another. For example, considering that the node might be attached to a SG that is getting overloaded, it could be an advantage (in terms of QoS, pricing, latency, etc.)

to attach a new SG that can deliver the same service without the risk to loose connectivity. This defines actually the idea of building a cluster of SGs that are strategically configured to improve the performance of the VPN service.

Scenarios: HA and Context Management

Following sub-sections 5.2.1 and 5.2.2 describe the scenarios addressed throughout this chapter.

First, sub-section 5.2.1 presents the High Availability scenario, where two concepts are introduced: the heartbeat and the Sync daemons. We illustrate the cases where a VPN cluster is composed of n number of nodes and where n = 2. Second, we present the scenario of context management, where a VPN client can be attached to a new SG without any IKEv2 signalization. -Sync is a daemon that provides synchronization of all the IKEv2/IPsec information. When an EU establishes a VPN tunnel towards the cluster, this information must be replicated to all the other members. The replication of the VPN session can be maintained locally within each SG or centralized within an independent device. Thus, the transfer of the IKEv2/IPsec sessions is needed to maintain the database up to date.

High Availability for n gateways

When both the heartbeat and the sync daemons are activated, the cluster is also capable to overcome failures. This is actually defined as fault tolerance. As such, if some failure occurs to the SG taking responsibility of some VPN session, then some other SG within the cluster must keep the VPN tunnel alive. This event is transparent for the EU and is interpreted as an interruption of the communication. No signaling is expected to happen, unless a refresh of the cryptographic material is desired.

High Availability for two nodes (n=2)

When the cluster is composed of two nodes (which is actually our testbed configuration in section 5.4.1), we consider that only one SG is active at a time (a.k.a. active SG), whereas the The active cluster member synchronizes every VPN session with its neighbor. This ensures perfect timing and synchronization of all the active VPN tunnels in the cluster.

As in section 5.2.1, we activate the heartbeat and a sync daemons which both ensure a keep alive mechanism together with IKEv2/IPsec state synchronization (including IKEv2/IPsec counters). (VPN Gateway 1) is considered as the initially active SG and is responsible for all incoming requests. Suddenly, some failure occurs in SG1 and then the SG2 becomes the active SG, taking responsibility of all the VPN connections. In this scenario, all the IKEv2/IPsec contexts that are stored in SG1 are also replicated on SG2 through the sync daemon (introduced in section 5.2.1).

As such, when switching from SG1 to SG2, the VPN cluster offers fault tolerance and ensures the high availability of the VPN service.

Context Management

The second scenario considered is called context management (see figure B.4). The context management scenario includes an End-User that demands some service placed behind the cluster of SGs. The EU establishes a VPN tunnel in order to access a service securely (i.e. streaming video, mail server, web server, etc.). However, in some cases, the SG where a client is attached can get overloaded. The risk to loose connectivity with the SG2 is high. Some other SG (i.e. , the IKEv2/IPsec context is transferred from SG2 to SG3 and all layers above benefit from this. Thus, no signaling is needed and this transfer is transparent for upper layers. This is only interpreted as some interruption or network delays. This avoids re-authentication towards the new SG, which in our example is SG3.

Position of our Work

Considering a Mono-LAN architecture, we positioned our work with some other protocols and documents that address similar topics. First we introduce an IETF document (RFC3374), which describes some reasons to perform a context transfer (regardless of the type of context transfer: IPsec, TLS, IP, etc.). Then, another IETF document (RFC6311) presents some recent investigations addressing the re-synchronization of IPsec counters for High Availability purposes.

Finally, we present VRRP, a protocol offering similar solutions to ClusterIP (discussed in section 4.5), but it also defines a framework to set master/slave routers to provide fault tolerance features.

-RFC3374 -Problem Description: Reasons for Performing Context Transfers Between Nodes in an IP Access Network [START_REF] Kempf | Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network[END_REF]: This Informational IETF document expresses the needs for transferring a service-candidate context and illustrates the overview of the reasons to perform a transfer of context between nodes in an IP Access Networks.

It is often the case that a peer connected to a router, establishes a context of a service

Position of our Work

that is provided by the access network. Usually, this service provides access to a subnet just like it is the case of IKEv2/IPsec protocol. The set of parameters to establish the connection between a peer and the router are the security associations. This information can be transferred from one router to another in order to boost the re-establishment of the connection when the IKEv2/IPsec Security Association is transferred between routers.

However, there are advantages and drawbacks. The main advantage is the possibility of a fast service re-establishment (i.e. AAA, QoS, IKE Authentication, etc). However, one of the drawbacks is the compatibility between different routers. On the other hand, they might be situations where the access networks (or even the routers) would prefer to initialize a new session from scratch. In our case, for an IPsec environment, the established security associations between the node and the SG are supposed to be static. Nevertheless, new challenges like mobility, context transfer, multihoming, among others, concern IPsec. This causes some issues due to its static design. Properties like load sharing, load balancing, context management and high availability, are some of the reasons to justify the transfer of an IKEv2/IPsec context between SGs.

-RFC6311-Protocol Support for High Availability of IKEv2/IPsec [START_REF] Singh | Protocol Support for High Availability of IKEv2/IPsec[END_REF]: as discussed in section 4. we have taken into account the solution proposed by this standard: move the sequence numbers forward, for example, by adding 10.000 to the sequence number value, avoiding anti-replay protection delays. Actually, the IPsec standard does not forbid the fact to raise at some point the value of the sequence numbers. For example, when transferring a VPN session from one SG to another, it is almost sure that some packets treated by the new SG will be stale. These packets will be considered by the End-User as a replay attack and will be dropped. If these packets had higher sequence number, then they would have been decrypted/authenticated by the End-User normally. As such, each time we perform an IKEv2/IPsec context transfer, we rise the sequence numbers by a value of 10.000, avoiding stale counters.

-RFC3768 -The Virtual Router Redundancy Protocol (VRRP) [START_REF] Hinden | Virtual Router Redundancy Protocol (VRRP)[END_REF]: intends to add fault tolerance of a single point of attachment in a network. VRRP creates a group of SG under a same virtual IP. Thus, the whole set of machines are acting as a single SG. Every interface that is configured with VRRP owns a virtual IP address that is common to all routers being part of the redundant topology. In the case where two or more SGs are configured with VRRP, the responsibility is determined by parameter among the group. The goal is to simulate a default SG with a unique IP address so that any End-User acceSSING through one of the SG does not know that there are many SGs composing the cluster. The responsible SG acting as default SG is called master virtual router, whereas all the other SGs are called backup virtual routers, which are ready to get the role of master virtual router and to forward packets if the master virtual router ever fails. Note that VRRP does not aim to perform load-balancing as it does not distribute the load of VPNs among different routers, but it adds fault tolerance (redundancy) to the network. In contrast, ClusterIP is able to spread the load among different SGs based on the hash of some input information (i.e. source IP address, destination IP address, port number, etc.). This permits VPN distribution among different SGs within a cluster, even though synchronization of the IKEv2/IPsec context must take place independently in order to ensure continuity of the VPN service. If we ever had to decide to use either VRRP or ClusterIP, we would most likely prioritize ClusterIP because it allows some sort of load sharing. However, the main drawback of ClusterIP is its limitation to be configured within the same network segment, disturbing the deployment of geographically distant SGs.

Performance Tests

Testbed description and scenarios

All our measurements are performed over an active VPN session during an audio streaming transmission with a duration of 8 seconds. Figure 5.4 illustrates the original audio file that is transmitted during tests. The signal contains a sentence pronounced by a woman and man. It is sampled at 48 kHz and contains up to 14 kHz signals.

We wish to measure the impact that HA and context management scenarios have on a VPN session. We consider different bit rate transmissions when streaming at 8Kpbs, 48Kbps and 96Kbps, evaluating the impact on the QoS (described in section 5.4.2.3). Additionally, we measure the impact of using two different encryption methods: CBC and CTR (described in 2). We also consider different transmission protocols: HTTP and RTSP, based on TCP and UDP respectively (see section 5.4.2.1 for details). Finally, we vary the frequency of HA and context management events. A switching frequency of f= 1 /8s means that only one event takes place during the 8sec streaming, f= 2 /8s means two events,f= 3 /8s means three, and so on.

Table 5.1 summarizes the set of architectures and parameters for all our tests. The scenario we are considering is: initially, an EU establishes a VPN towards the cluster (composed of two nodes). This allows the EU to reach the streaming server in a secure manner. Then, the EU receives an audio streaming with a duration of 8sec. Depending on the scenario, our performance tests are conducted either with HA features enabled (heartbeat and sync daemons activated as in section 5.2.1) or with context management features enabled (as in section 5.2.2). Once the streaming has finished, the original source file is compared with the received audio file recorded during streaming in order to measure the QoS by using the software POLQA (see 5.4.2.4).

-First testbed and scenario -HA: our first testbed, shown in figure 5.5, represents the logic topology of the HA cluster. This testbed includes an audio streaming server, an IPsec peer (EU) and two VPN SGs (SG1 and SG2). The sync daemon synchronizes every IKEv2/IPsec context established on both SGs and the heartbeat daemon is responsible for checking liveness of each SG every second. We focus on how to ensure fault tolerance and high availability features to EUs. Thus, during the audio streaming transmission, we simulate failures and vary the frequency of interruption 1 /8s, 2 /8s, 3 /8s and 4 /8s) events on the cluster. This automatically activates the mechanisms to ensure continuity of service of the VPN service and makes the standby SG becomes the active SG and vice-versa. For experimental purposes, we have synchronized one VPN session.

-Second testbed and scenario -context management: the second testbed is shown in figure 5.6. It represents the logic topology of the testbed and also includes an audio streaming server, an IPsec peer (EU) and two VPN SGs (SG1 and SG2). We perform manual switching of a VPN session by transferring the IKEv2/IPsec context from one SG1 to SG2 (and vice-versa) using different frequencies ( 1 /8s, 2 /8s, 3 /8s and 4 /8s). The objective is to successfully manage an IKEv2/IPsec context between SGs at anytime during an

Protocols, parameters and audio streaming tools

This section describes in detail the different methods, protocols and bit rates used during our performance tests. We compare the difference and introduce the impact that they may have This section is intended to explain how the audio streaming data flow is built, based on RTSP or HTTP, and protected with an IPsec environment. Figure 5.8 shows the packet format when securing a RTSP audio streaming (over UDP) with IPsec (ESP) in tunnel mode (refer to section 2.3.2 for details). On the other hand, figure 5.7 illustrates the packet format when performing HTTP audio streaming (over TCP) secured with IPsec (ESP) in tunnel mode. The RTSP and HTTP payload length varies depending on the audio source data itself. For example, during silences in the audio streaming, the size of the packets may be shorter than during voice transmission. However, this also depends on how the data flow is treated by the transport layer. This is discussed in more details in section 5.5.

Regarding the IPsec layer, the ESP header has a 4-byte length Security Parameter Index (to identify the corresponding security association) and a 4-byte length sequence number, which is part of the anti-replay protection of IPsec, avoiding duplicated packets with the same sequence number during ESP authentication. Although some encryption algorithms do not need padding to cipher a plaintext (e.g. CounTeR), ESP does require padding to 32-bit word-align the 1. CBC: the mode of operation CBC is illustrated in figure 5.9. For encryption, the whole clear message is separated in blocks of 16 octets. Whenever the last block length is smaller than 16 octets, some padding is added in order to complete the block. Then, the first block of plaintext is XORed (represented with a circular plus symbol) with a Initialization Vector (IV). Notice that an IV is a block of bits used with the purpose of randomizing the encryption of some data (i.e. even if the same text is encrypted several times, the result is different each time). Then, the result of the XOR function is encrypted using AES algorithm and a key of 128bits. Finally, this ciphertext is used as IV for the next block of data and the process is repeated. Hence, this mode of operation does not allow parallelized encryption. Nevertheless, the decryption process allows parallelization. The blocks of ciphertexts are directly decrypted by the AES decryption algorithm together with its corresponding key. Only the first block of cipher text is subject to XOR processing with an IV. The rest of data blocks are XORed with the precedent ciphertext block (allowing parallelization of the decryption process).

2. CTR: the mode of operation CTR is shown in figure 5.10. This mode of operation allows using the same cipher block for encryption and decryption, it means that the decryption key scheduling do not need to be implemented, making it simpler than other mode of operations. For encryption, the key and a counter block of data are used as input of the block cipher. This generates a random keystream which is XORed with the clear text in order to obtain the ciphertext. The encryption process can be parallelized as there are no chaining operations, allowing independent cipher block inputs. For decryption, the same counter and keys are inputs of the block cipher and the ciphertext is XORed with this keystream, which results in the plaintext again. However, during decryption, if the That is why, AES-CTR does not require padding completion to a multiple of the block size (see [START_REF] Housley | Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)[END_REF] and [START_REF] Helger Lipmaa | Comments to NIST concerning AES Modes of Operations: CTR-Mode Encryption[END_REF] for details).

Audio tools supporting several bit rates: 8kbps, 48Kbps or 96Kbps

We used two implementations in order to transmit and record the audio streaming from the server towards the EU during our tests: VLC and Arecord.

1. VLC stands for VideoLAN Client and server. It is an open source multimedia and streaming player. We have used this software in order to perform audio streaming in a client-server fashion. It supports various streaming protocols (refer to [START_REF] Vlc | VLC streaming protocols[END_REF] for details).

Depending on the test, parameters on the command line are modified in order to change the bit rate as well as the transmission protocol. We have tested three different bit rates: 8Kbps, 48Kbps and 96Kbps, as well as two different protocols: HTTP and RTSP (as explained in section 5.4.2.1). VLC allows to output any stream to a network or a file.

Additionally, it allows processing the original streamed file in order to apply transcoding, filters, among other signal treatments. Appendix ?? shows a list of commands to perform audio streaming using different scenarios (i.e. protocols and bit rates). Finally, VLC also includes different modules that have different capabilities. The modules used for our tests are listed below: (b) Transcode: is used to decode and re-encode the streamed file using different bit rates (e.g. 8Kbps, 48Kbps and 96Kbps).

2. Arecord is a native Linux command for audio recording (see [START_REF] Arecord | Arecord native ALSA command[END_REF]). It supports a large set of soundcards and devices. The following command line captures the audio that is received during the streaming:

arecord -f cd -d $vlc timeout duration /tmp/sound card record.wav

The parameters of the command are explained below:

-f, -format=FORMAT : format of the sample recorded. There exists a set of formats, however, we used a format shortcut "-f cd ", which represents a 16 bit little endian, 44.1KHz and stereo capture. This is the equivalent of a CD-quality wave file.

-d , -duration=N : interrupt recording after N seconds. Setting it to zero, means infinity. We set this value to a variable called $vlc timeout duration.

File path : where the audio files is saved. In our case, /tmp/ directory. Then, at the end of the test, the captured audio file is transmitted to a server with the rest of test logs. In terms of quality of service measurements (QoS), we use Perceptual Objective Listening Quality Assessment, POLQA (see [START_REF] Polqa | Perceptual Objective Listening Quality Assessment -POLQA[END_REF]). It is a relatively recent standard (2006-2011) for voice quality testing technology which is available under license. Orange, as a leading mobile operator in France, gets some licenses for using this software. Testing and measuring the impact of our developments over the QoS for some audio streaming, is a manner to evaluate the performance of our results.

Performance results

The results are represented in graphs with box-and-whiskers style (a.k.a. quartiles), as in section 4.7.1 (refer to section 3.4.3 for more details). Section 5.5.1 includes the results concerning the HA testbed considering different parameters (bit rates, frequency of interruption, etc.) whereas section 5.5.2 shows the results concerning the context management testbed. For each testbed, we analyze the network performances of our solution and then we concentrate on the QoS performances. We represented graphically all the results considering the parameters showed in table 5.1, and for each combination of parameters 25 measures were done in order to polt statistical results as quartiles.

Results for High Availability

This section exposes the results obtained during the performance tests concerning our High Availability solution. Section 5.5.1.1 shows the network performace and section 5.5.1.2 shows the impacts on QoS for each considered parameter.

Network performances:

Our first result shows how a VPN session is impacted while the HA scenario takes place. This proves that HTTP is considerably impacted under an HA scenario. For HTTP-CTR, whose quartile are also spaced, the medians starts from 2.5sec (for 48Kbps) until 4.2sec (for 8kbps), being HTTP-CTR-8Kbps the worst median performance and less stable result of all cases for a switching frequency f= 1 /8s. On the other hand, in most scenarios, CBC had a better performance than CTR (unless for HTTP-48kbps only). Considering RTSP, the switching time is notably stable around 1.5sec, and the quartiles are narrower, evidencing stability of the measure. This means that regardless of the encryption algorithm and application/transport protocol used, this scenarios are fairly stable. Notice that we do not pretend to compare HTTP against RTSP as application protocols. The objective is to explain the difference of using whether HTTP or RTSP and to measure how our developments of HA impacts them in different circumstances. Actually, we decided to use HTTP and RTSP, because HTTP relies on TCP whereas RTSP relies on UDP protocol, allowing to study the impact over connection oriented and non-connection oriented protocols. However, figure 5.11 illustrates that is better to implement RTSP than HTTP while streaming under a HA environment. interruptions are randomly generated on time so that failover events never take place at the same time. Figure 5.12a illustrates the total switching time when using HTTP whereas figure 5.12b represents RTSP.

Both figures 5.12a and 5.12b show an unstable response facing the different switching frequencies. Even though the quartiles are spaced, the total switching time increases linearly when streaming over HTTP. In the case of RTSP, the total switching time remains stable during frequency 1 /8s, but quartiles become more spread when the frequency of interruption increases. We noticed through network captures that the HTTP audio streaming packet sizes are considerably bigger than those packets of an RTSP audio streaming. This explains why HTTP audio streaming gets more impacted in terms of network performance, usually taking more time to overcome a failure event. As HTTP is based on TCP, this connection-oriented protocol ensures reliability, ordering, and error-checking of delivered stream of octets. This situations leads to a considerable overhead and higher impact during interruptions, as more information must to be retransmitted. Thus, loosing some information when using HTTP streaming might represent more troubles than streaming with RTSP. Due to the connection-less oriented behavior of RTSP (based on UDP), those packets that are lost are not sent again, which represents lower overhead. which are represented as 1 /8s, 2 /8s, 3 /8s and 4 /8s. We also added quartiles for frequency zero ( 0 /8s), which represents the reference QoS for each case. This allows comparing the QoS deterioration as long as we increase the switching frequency. We observe that as soon as the switching frequency increments, both 48Kbps and 96Kbps (HTTP and RTSP) downgrade the QoS. However, when using 8Kbps bit rate, the QoS smoothly improves as the switching frequencies increase.

A bit rate of 8Kbps is considered as a very bad quality by POLQA, and the note always remain below of 1.25 /5. During interruptions, POLQA gives a slightly better QoS than the reference QoS, meaning that the interruptions are actually similar to an audio with compression of 8Kbps. On the other hand, 48Kbps and 96Kbps decrease in terms of QoS regardless of the encryption algorithm while the switching frequency increases.

Finally, figure 5.14a illustrates the loss of QoS when the switching frequency is 1 /8s. This figure is also partially represented in figure 5.13, but this time we show the results according to the bit rate (instead of switching frequencies). Also, we added an additional quartile called Reference QoS. In fact, the Reference QoS consist of measuring the quality of an audio streaming while no interruption takes place. This is how we can actually measure the impact of the interruption By comparing the switching frequency f= 1 /8s with the reference QoS, we obtained the following main results: the QoS for HTTP-48Kbps is degraded by around 50%, HTTP-96Kbps-CBC by 35% and HTTP-96Kbps-CTR by 58%. The 8Kbps results are particularly different. The POLQA's algorithm gives a very bad note to any transmission made with 8Kbps. Audio streaming at this rate does not accomplish a good level of quality, thus obtaining an average note of 1.23 /5. Even for interruption where switching frequency is 1 /8s, POLQA gives a better note as the reference QoS. This means that interruptions are better noted than the audio transmission itself due to its bad quality. For further details in how POLQA algorithms objectively evaluates audio quality, refer to [START_REF] Richard Reynolds | Application Guide for Recommendation ITU T P.863[END_REF]. Table B.2 summarizes the results of QoS as long as the switching frequencies increase for all the cases.

Results for context management

This sections exposes the results obtained during the performance tests for our context management scenario. Section 5.5.2.1 shows the network performance and section 5. Notice that measurements take place during a streaming transmission of an audio source file with a duration of 8sec.

Figure 5.15 illustrates the total switching time for different switching frequency cases. As for the HA testbed, the total switching time is calculated as the accumulated time when switching from SG1 to SG2 and vice-versa: Figure 5.17 shows the QoS for several switching frequencies ( 1 /8s, 2 /8s, 3 /8s and 4 /8s). As for the HA testbed (refer to 5.5.1.2), we also added quartiles for frequency zero ( 0 /8s). This represents the reference QoS for each considered scenario. This allows comparing the QoS deterioration as long as we increase the switching frequency.

Figure 5.17a represents the variation of the QoS while streaming under HTTP. 8Kbps obtains poor marks as in HA testbed ( 1.25 /5). In terms of QoS, 8Kbps is strongly discouraged to use.

Actually, by performing audio streaming at 8Kbps we might gain in terms of bandwidth but loose in terms of quality. On the other hand, HTTP-48Kbps and HTTP-96Kbps both maintain acceptable good notes as long as the switching frequency increases. Even though the QoS is logically downgraded while increasing the amount of interruptions, HTTP maintains a fair QoS.

Note that HTTP uses TCP as transport protocol, which ensures lost packets to be resent, maintaining a good behavior in terms of QoS. However this may represent high bandwidth consumption as well as longer delays when listening to the audio streaming. For example, in terms of network performance, HTTP shows higher interruption levels when increasing the switching frequencies than RTSP (see fig 5.15). Figure 5.17b represents the QoS for several switching frequencies with RTSP, showing that it is clearly more impacted in terms of QoS than HTTP. Although RTSP showed good results in terms of network performance by switching from SG1 to SG2 in 1.3sec, this is not the case in terms of QoS. In fact, as RTSP is based on UDP, connectionless-oriented protocols do not resend lost packets, introducing higher impacts on the QoS of the streaming. When using RTSP, the impact over the QoS for 1 /8s, 2 /8s, 3 /8s and 4 /8s switching frequencies are (in average): 36,5%, 50%, 55,75% and 57,5% correspondingly.

Finally, figure 5.18 shows the QoS evaluation for different bit rates with a switching frequency f= 1 /8s. We observe that RTSP is more impacted than HTTP. HTTP's QoS decreases by 18% and 28% (CBC-48Kbps and CBC 96Kbps) while RTSP's QoS decreases by 31% and 53%

(CBC-48Kbps and CBC 96Kbps). However, in some cases RTSP has less impact on the QoS than HTTP in percentage (i.e. -41% using HTTP-48Kbps-CTR and -35% using RTSP-48Kbps-CTR), but in fact, the reference QoS is also staled since the beginning (i.e. 4.5 /5 for HTTP-48Kbps-CTR against 3.25 /5 for RTSP-48Kbps-CTR). This means that, in some cases, the HTTP streaming might be a little bit more impacted than RTSP streaming, but the QoS remains the best when using HTTP.

Conclusions

Throughout this chapter we described the IKEv2/IPsec context transfer under a Mono-LAN environment, where a cluster offering a VPN service is configured with a common IP address.

Contrary to chapter 4, this time our scenarios included the IKEv2/IPsec context transfer between physically different SGs. We defined two new components: the heartbeat and the sync.

These components allows to synchronize every tunnel that is negotiated with any of the cluster members, and the heartbeat regularly checks liveness of the nodes.

By introducing the High Availability architecture, we added the capability to successfully overcome a failover event thanks to the constant replication of the IPsec and IKEv2 data. We found out that an ISPs may be interested in deploying this architecture to ensure reliability of the VPN service. On the other hand, by increasing the availability of the system, the End-User experience and the QoS is improved when avoiding re-authentication when moving from one SG to another. Also, the IKEv2/IPsec context management under a Mono-LAN environment represents advantages for the VPN service. Indeed, an ISP wanting to balance the load among different cluster members might use this feature to dynamically move an IPsec session from one SG to other. This improves the performance of the VPN service and avoids overloaded gateways within the cluster.

We tested two different scenarios: High Availability and Context Management. We also consider several parameters throughout the tests: encryption methods, bit rate transmissions as well as connection and non-connection oriented transport protocols. We found out that the context management scenario performed better than HA. Actually, even if both scenarios contemplate the transfer of an IKEv2/IPsec context, they perform differently and might be implemented in different circumstances. The heartbeat component of the HA scenario adds automatism during failover occurrences, however the transfer of the IKEv2/IPsec context only happens once the heartbeat gives the order to do so. Instead, under a Context Management scenario, an ISP is able to move an IPsec session whenever needed, and thus improving the performance and End-User experience. This is the main reason why the context management scenario performed better than HA.

Our results are presented in terms of network behavior and QoS. During the HA tests, we noticed that the network behavior of non-connection oriented protocols (i.e. UDP) are less impacted by a failover event than a connection oriented protocol (i.e. TCP). In fact, due to the nature of TCP which mandates to acknowledge transmitted data, this generates additional delays to recover from failover events. However, from a QoS point of view, TCP obtained better results than UDP. Indeed, with UDP, those packets that are lost during failover events are not recovered, thus degrading the QoS. Considering the context management, we noticed that connection oriented protocols are less impacted compared to the scenario where HA features 96 5.6. Conclusions are enabled. This is mainly due to the time that the heartbeat takes to perform its task.

Actually, during a context management, there is no heartbeat involved during the transfer of the IKEv2/IPsec context, and thus, the SG taking responsibility of a connection does not need to wait the liveness check to install the new IPsec session. When comparing HTTP (TCP) with RTSP (UDP), we noticed that RTSP has a better network behavior than HTTP. However, in terms of QoS, HTTP obtains (once again) better results than RTSP.

We also measure the Mean Opinion Score (MOS), a measure of voice quality, with POLQA.

From the three different bit rates used, 92kbps consumes more capacity, but delivers an average MOS of 4.75; 48kbps delivers a MOS slightly better than 4.3 and 8kbps delivers a MOS of 1.25.

Thus, an enterprise must decide whether MOS values deliver acceptable quality or whether they would prefer to trade some bandwidth for higher quality.

Future work includes interaction of IPsec facing a context transfer between SGs with different IP addresses. Even though we improved the VPN service by creating the cluster of nodes with a single IP address, an ISP may also be interested in moving an IPsec session between distant SGs with different IP addresses. We believe that this may be advantageous to ensure the continuity of a VPN service for a mobile user that is probably changing its attachment point. This is explained in details in chapter 6. The chapter is organized as follows: section 6.1 describes the motivation of performing Multi-LAN context transfers, then, section 6.2 positions our work compared to related topics concerning the transfer of an IPsec context. Following section 6.2.3 focuses in explaining MOBIKE extension and how it can be implemented to perform IKEv2/IPsec context transfers (subsection 6.4). Finally we present our conclusions in section 6.5.

Part

Motivations

An IKEv2/IPsec context transfer should be performed smoothly with respect to End-Users.

Our goal is to avoid the number of exchanges between the access network devices (SGs) and the End-User during a context transfer. However, when the IP address associated to an IPsec VPN tunnel changes, it is mandatory to update the corresponding IPsec and IKEv2 databases on both extremities. This introduces some delays that might impact the EU experience during an active IKEv2/IPsec session. We propose a solution by performing a GET action from the SG sending 100

Position of our Work

the context, and then performing a PUT action at the SG receiving the IKEv2/IPsec context.

However, in contrast to precedent chapters, an additional INFORMATIONAL IKEv2 message must be exchanged between the EU and the SG in order to inform that the IP address changed.

This impacts the EU experience as it is involved during the transfer between SGs. Nevertheless, MOBIKE is an ideal extension of IKEv2 allowing to perform our Multi-LAN context transfer, as it avoids re-authentication from scratch, reducing delays in the establishment of a new tunnel towards a new IP address.

Even though the mobility feature of MOBIKE was initially designed as to be applied from the client side (which is supposed to be a mobile node), our solution can use this exchange at the SG's side, and update the IP address where a peer is attached to. However, this would introduce some changes to the source code of the implementation of the protocol itself, as we will be using a mobility protocol to actually perform an IKEv2/IPsec context transfer. Section 6.2.3 explains the details of our proposed solution.

Position of our Work

This section includes the description of some related work, considering our Multi-LAN scenario.

First we address a generic mechanism that manages to exchange some defined contexts (in our case IPsec). Then, we position our work considering a mechanism called REDIRECT, allowing to perform redirection of peers toward different SGs, and finally we finish by describing MOBIKE.

Context Transfer Protocol (CXTP)

The IETF's experimental protocol, CXTP [START_REF] Loughney | Context Transfer Protocol (CXTP)[END_REF] which is a barrier to make us believe this is the right protocol to be implemented for our Multi-LAN scenario in the near future.

MOBIKE -IKEv2 Mobility and Multihoming Protocol

As described in section 2.6, MOBIKE is an extension of IKEv2 allowing to perform mobility and multihoming features during and active VPN session. Initially, IKEv2 is the protocol used to perform mutual authentication during establishment of the tunnel as well as to perform maintenance of the IPsec SAs involved. The IKE SAs and IPsec SAs are created between the IP addresses that are used during the IKEv2 initial exchanges. These IP addresses are used as the outer IP header of the IKEv2 further exchanges and the protected traffic as well. However, there are some use cases where these IP addresses might change. For example, a peer that changes its point of attachment to the network might change its IP address too, loosing communication with the SG and the initial tunnel that was already established. Another example would be a device that has multiple interfaces with multiple IP addresses wishing to switch its traffic from one interface to another.

What happens when one of the IP addresses of the tunnel change?

There are two possible solutions when these IP addresses change. First, one of the extremities of the tunnel can re-initiate a new negotiation of IKE SAs and IPsec SAs from scratch. However, this is not the most beneficial situation for an ongoing session. Creating a new VPN tunnel involves expensive calculation and further round-trips that will downgrade the EU experience.

For example, authentication exchanges often ask a password to End-Users (e.g. a pin code), introducing additional delays that may negatively impact the VPN session and the service above the IP layer. Second, if we manage to use the already established IKEv2/IPsec in order to inform the IP address of the SG. Even though this case is similar to the original multihoming feature of MOBIKE showed in figure 6.1b, the main difference is that the new IP address of the SG, is owned by a physically different SG. Instead of forwarding packets to an ADDITIONAL IP ADDRESS within the same SG, the traffic is now forwarded to an IP address belonging to a new SG.

Nevertheless, the new SG must also receive the IKEv2/IPsec parameters of the tunnel in order to ensure the continuity of the VPN service, otherwise it would not be possible to decrypt traffic coming from the EU. This allows applications not to be interrupted at the IP layer. Nevertheless, when transport mode is used, the new header of the IPsec-protected traffic generates an interruption at the IP layer, and the applications might consider to manage IP mobility.

Implementation considerations

During the transfer of the IKEv2/IPsec between SGs with different IP addresses, there are some factors that might be evaluated and considered:

1. SPI collision: during the transfer of the IKEv2/IPsec session, it could be possible that a collision of SPI (Security Parameter Index) occurs. To solve this, the implementation may consider an additional IKEv2 exchange in order to negotiate a new SPI. The probability that a collision occurs is very low, but if this ever happens, the IKE SA and corresponding CHILD SAs would tear down.

2. Trigger: there should be a trigger to carry out the transfer of an IKEv2/IPsec context.

For example, one reason could be a mobile node changing its attachment point due to low signal, and thus it may be beneficial to transfer the tunnel IKEv2/IPsec from one SG to another. Some other reasons could be: a SG reaching its maximum capacity and needing

Conclusions

Throughout this chapter, we present how to proceed when performing a context transfer of the IKEv2/IPsec session based on a mobility extension, MOBIKE. This solution may have positive impacts concerning the EU experience whenever a VPN session is transferred between different devices. Actually, as we have discussed in previous chapters, an IPsec session is initially intended to be maintained within the same device that established the connection. However, from a ISP point of view, there are advantages to transfer an IPsec session between different devices.

We defined the Multi-LAN scenario as in figure B.6. We also described the exchanges during the IKEv2/IPsec context transfer in figure B.5. We expect to reduce the amount of calculation and time that the ISP spend during session establishments. Indeed, the energy consumption of the ISP would be reduced as long as the IKE SAs and IPsec SAs are kept during the transfer of an IKEv2/IPsec context. This improves the actual behavior of the network in terms of energy and traffic management.

We detected the difference between transport mode and tunnel mode of IPsec. In tunnel mode, the context transfer is virtually transparent to EUs. Indeed, the IPsec traffic (i.e. ESP traffic), is actually tunneled within a payload containing a new outer IP header (the inner IP header remains the same). However, when IPsec is used in transport mode, the upper layers implementations must deal with IP mobility as well, as the IP header of the IPsec traffic changes 6.5. Conclusions too. We have already done some investigation in terms of mobility for IPsec transport mode (see [START_REF] Migault | MOBIKE eXtension (MOBIKE-X) for Transport Mobility and Multihomed IKE SA[END_REF][START_REF] Migault | IPsec mobility and multihoming requirements : Problem statement[END_REF][START_REF] Migault | Multiple Interfaces IPsec Security Requirements[END_REF]), where we designed a protocol called MOBIKE-X.

Future work includes the implementation of the solution as described in section 6.4. A new research contract extension has been approved mutually between Orange (France Telecom) and the University of Paris 6 in order to continue this research topic.

Chapter 7

Conclusions and Future Work

This thesis is focused on enhancing and ensuring the continuity of service of IKEv2/IPsec based communications, mainly implemented as VPN services.

The first part of our investigation focused on how to protect IP networks with IPsec. We also introduced the concept of using IKEv2 as the perfect complement to IPsec in order to perform authentication of parties and subsequent management of IPsec connections. This allows operators to offer a reliable and secure environment over untrusted network. Also, by providing an introduction of some IKEv2 extensions like MOBIKE or REDIRECT, we pretend to present a framework for seamless context transfer in order to dynamically manage an IKEv2/IPsec session.

Following investigations lead us to develop two new features concerning IKEv2/IPsec VPNs:

GET and PUT functions. Our main motivation was to achieve dynamic management of a VPN session whenever desired. We found out that extracting all the information concerning an IKEv2/IPsec session would take around 15ms, and re-installing it would take 22ms approximately. Our implementations were done in StrongSwan.

The second part of the thesis is dedicated to the Mono-LAN environment. We studied the implementation of ClusterIP, a mechanism allowing to create a cluster of SGs under a single virtual IP address. Results in chapter 4 showed that an active SG spends 5% to 8% of CPU more than a passive SG when clustering IPsec tunnels with ClusterIP. We also observed that there is an additional load when using the HA-plugin of strongSwan among the cluster members.

Further investigations, includes merging ClusterIP features with our own functions (GET and PUT). We created a framework of seamless IKEv2/IPsec context transfer. This drove us to the definition of two new architectures offering High Availability and Context Management capabilities based in our GET and PUT implementations. We presented our results in terms of network behavior and quality of service. During HA tests, we realized that the network behavior of non-connection oriented protocols (i.e. UDP) are less impacted by a failover than a connection-oriented protocol (i.e. TCP). Concerning context management results, we noticed that connection oriented protocols are less impacted compared to the scenario where HA features are activated. Throughout the second part of the thesis, we notice that these implementations allow providing load balancing as well as load sharing properties among different cluster members without having a dedicated device. However, we also found out that these solutions are more specific for locally established clusters, where SGs are placed physically close while remaining within a same network segment.

Finally, the third part of the thesis is dedicated to Multi-LAN environments. We defined an architecture for transferring IKEv2/IPsec contexts between SGs owning different IP addresses.

Although both tunnel and transport modes involve some IKEv2 signalization when changing its attachment point (i.e. INFORMATIONAL exchange), they are impacted differently. In tunnel mode, when the IP address associated to the end-point of the tunnel changes, this interruption is transparent for upper layers applications. Even though the outer IP address of a tunnel changes, the inner IP address of the tunnel remains the same. On the other hand, for transport mode communications, there is no inner IP address. Applications would have to deal with IP mobility whenever its IP address associatied to an IKE SA and IPsec SA changes. Our efforts concentrate on allowing an operator to move an EU from one SG to another by using minimal signalization, less consumption and less calculation associated to the construction of cryptographic material.

Global Evolution and Future Work

Since most of the terminals are now equipped with alternative access network interfaces (e.g.

WiFi), we believe that operators have to focus on how they can be used to get access to services.

On the other hand, one of the potential evolutions to accommodate traffic from mobile access networks is to offload the Radio Access Network (RAN) traffic towards complementary access networks such as WiFi, WIMAX, femtocells, etc. These networks are called to maintain the same level of security and perform as well as in RANs. Additionally, non mobile access networks, like WiFi, are widespread as wireless extensions of broadband access networks, mainly in indoor spaces where cellular technologies do not perform well.

ISPs are interested in offering new capabilities to its VPN services. Even if today's multimedia contents are mainly offered by Web services (HTTP streaming, VoIP, etc.), the access to the network itself is still managed by ISPs. Operators shall be able to easily adapt to new business opportunities. For example, architecture choices can make it easier for Orange to offer NaaS (Network as Service) services in the future, and this requires implementing VPNs. Hence, enhancing the reliability, availability and quality of such services is a matter of interest.

As discussed throughout this investigation, mobile data traffic is expected to grow annually by 60% to 70%. Even though the traffic is increasing more and more, there have also been generalization of flat rate billing plans, higher availability of attractive contents and increasing Chapter 7. Conclusions and Future Work 111 availability of high consumption devices (e.g. laptops, smartphones, tablets, etc.). All this context creates great pressure over operators for them to provide the best possible performance over their networks.

Our own developments in this area lead us to manage a VPN tunnel. Allowing an operator to dynamically handle the EUs that use its VPN services, definitively have a beneficial impact for the EU experience. However, more work remains in order to make it fully work within operational networks.

First, even if our testbeds concerning Mono-LAN environments considered the transfer of the IKEv2/IPsec context between two different SGs, we believe that it is important to design a framework in order to decide responsibility of incoming request when the cluster is composed of n nodes. For HA scenarios, we addressed active/passive scenarios, but for load sharing or load balancing scenarios, it would be important to define an algorithm that decides how to spread the load among the different cluster members.

Concerning Multi-LAN environments, we presented a solution based on MOBIKE allowing to perform context transfer. This solution addresses the context of an IKEv2/IPsec context between nodes with different IP address. As the period of the thesis came to its end, this implementation is indeed part of the future work of our investigation. However, a very motivating project emerged in order to continue our research in this area. Once the developments of Multi-LAN are done, we pretend to give the community a mechanism that ameliorates the behavior of the network.

Actually, future networks tend to be more heterogeneous, and this would be a mechanism that allows to switch a VPN session between different SGs. Also, we pretend to reduce the delays of reestablishing a new VPN tunnel towards a new SG, instead of transferring this data between the access routers themselves.

It might be important to concentrate efforts in defining some sort of local intelligence in order to manage IKEv2/IPsec sessions. A sort of application capable to externalize the decision of managing sessions. For example, a use case would be a Connection Manager deciding whether to perform handover, mobility or multihoming features, and to dynamically manage security aspects. As IKEv2 is the protocol allowing to negotiate modifications to IPsec, the connection manager would be able to issue orders in order to customize an active IKEv2/IPsec session.

Nowadays networks are composed of several access technologies, where each one defines its own security standards, introducing heterogeneity to the network. This situation has the drawback that it is complex to maintain the same security level among different access

xii List of Figures 4 . 5

 45 Second Test -QoS on an HTTP Connection . . . . . . . . . . . . . . . . . . . . . 65 4.6 Third Test: Handover Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.1 High Availability scenario for n gateways . . . . . . . . . . . . . . . . . . . . . . 71 5.2 High Availability scenario for n=2 nodes . . . . . . . . . . . . . . . . . . . . . . . 72 5.3 Context Management scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.4 Original audio file transmitted on streaming during tests . . . . . . . . . . . . . . 75 5.5 Testbed 1 -High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.6 Testbed 2 -Context Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.7 HTTP audio streaming protected with IPsec . . . . . . . . . . . . . . . . . . . . 79 5.8 RTSP audio streaming protected with IPsec . . . . . . . . . . . . . . . . . . . . . 79 5.9 AES128-CBC encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.10 AES128-CTR encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.11 Total switching time for one interruption ( 1 /8s

1. 1

 1 Solutions for each scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Third Test -Interruption Times, Traffic Rate and File Sizes . . . . . . . . . . . . 4.1 Hooks used by the strongSwan's HA plugin . . . . . . . . . . . . . . . . . . . . . 4.2 Synchronization messages of the HA plugin . . . . . . . . . . . . . . . . . . . . . 4.3 Control messages for segment changes notification . . . . . . . . . . . . . . . . . 5.1 Architectures and parameters addressed during tests . . . . . . . . . . . . . . . . 5.2 Impact of the frequency of high availability events over QoS (considering the medians) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Impact of the frequency of context management events over QoS (considering the medians) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.1 Solutions for each scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2 Impacte de la fréquence des évènements de HA sur la QoS . . . . . . . . . . . . . B.3 Impacte de la frequence des évènements de Context Management sur le QoS . . . Chapter 1

Figure 1 . 1 :

 11 Figure 1.1: Clustering IPsec security gateways

Figures 1 .

 1 Figures 1.2 and 1.3 show two cases of interest representing some EUs being offloaded from RAN to WLAN. The first use case illustrates an EU attaching a cluster within a same administrative domain, whereas the second use case illustrates an EU moving between two VPN clusters placed in different administrative domains. IKEv2/IPsec Context Transfer within the Same Administrative Domain Figure 1.2 represents the first use case. An EU is offloaded from its RAN to a WLAN (WiFi).

Figure 1 . 2 : 6 1. 1 .Figure 1 . 3 : 7 1. 2 VPN

 12611372 Figure 1.2: Offload Architecture: Context transfer within a same administrative domain

1. 2 .

 2 Figure 1.4: IKEv2/IPsec context transfer scenarios

1. 4 . 3

 43 Detailed position towards High Availability vs. Mobility scenarios In an architectural point of view, our work differs from previous work in the use cases we address. The scenarios that motivated our work are not mobility but High Availability and Cluster management. In a Mobile IP (MIP) environment, a Mobile Router (MR) is transferred from one Home Agent to another Home Agent, and the IKEv2/IPsec context is transferred between Home Agents with the purpose to optimize the handover and reduce latency. On the other hand, our work considers two different scenarios, and both involve clusters of Security Gateways.

  Authentication Header in Transport Mode

Figure 2 . 3 :

 23 Figure 2.3: IPsec Encapsulation Protocol: Athentication Header

  Encapsulation Security Payload in Transport Mode

Figure 2 . 4 :

 24 Figure 2.4: IPsec Encapsulation Protocol: Encapsulation Security Payload Header

Figure 2 .Figure 2 . 5 :

 225 Figure 2.5: IKEv2 message exchanges, IKE INIT and IKE AUTH

  Version Number : set to version 2 (e.g. IKEv2). SAi1 : cryptographic algorithms proposed. KEi1 : Diffie-Hellman values. Ni : INITIATOR's nonce.

Figure 2 . 6 :

 26 Figure 2.6: IKE SA INIT exchange details.

Figure 2 .

 2 [START_REF] Loughney | Context Transfer Protocol (CXTP)[END_REF] illustrates the IKE AUTH exchange.

2. 4 .Figure 2 . 7 :

 427 Figure 2.7: Detailed IKE AUTH exchange.

  MOBIKE stands for IKEv2 Mobility and Multihoming (MOBIKE) Protocol. It is an extension to IKEv2 protocol. MOBIKE allows to change the IP address associated to an IKEv2/IPsec tunnel.

Figure 2 . 8 :

 28 Figure 2.8: MOBIKE Protocol Exchanges

Figure 2 . 9 :

 29 Figure 2.9: REDIRECT support during IKE SA INIT

Figure 2 .Figure 2 .

 22 Figure 2.10: REDIRECT exchanges

34 3. 2 .

 342 Motivationto another. We also propose an additional mechanism for solving the mis-synchronization of IPsec anti-replay counters and IKEv2 Messages ID counters. Finally some performance measurements are provided in terms of delays, and packet loss, and prove feasibility of the approach. Section 3.3 describes details of an IKEv2/IPsec context. Section 3.4 introduces a proposed mechanism to perform IPsec Context Transfers (referred to as IPsec-CXT), a description of GET and PUT functions and a step-by-step description of an IPsec-CXT. Finally, sections 3.4.2 and 3.5 describe our implementation as well as the testbed results.

IKEv2/

  IPsec context is to avoid re-authentication against SG2. In fact, re-authentication would increase signaling and would interrupt the communication which could be critical for real-time based applications. Note that if SG1 and SG2 do not have the same IP address, then the EU MUST also update its IKE SAs and IPsec SAs. Transferring the IKEv2/IPsec context introduces the following constraints: (1) identification of the IKEv2/IPsec parameters so it can be extracted and reinstalled into another SG. Notice that some parameters of the context requires perfect timing, which is much more difficult to get than the IKEv2/IPsec context itself, (2) two gateways with different IP addresses bring complexity as the hosts should consider the management of their tunnel and their SAs (mobility aspect), as well as the distance between SGs introduces Chapter 3. IKEv2/IPsec Context Definition 35 network delays.

  k.a. IKE SA) between two end-points in order to negotiate and continuously update all the IPsec related information (a.k.a. CHILD SA or IPsec SA) between them. First, during IKEv2 initial exchanges (known as Phase 1), one of the end-points (INITIATOR) triggers the communication by sending an IKE INIT request. The other end-point (RESPONDER) replies back with an IKE INIT response. At this point, both nodes have a shared secret to perform encryption and integrity protection for further IKEv2 exchanges, and have agreed on the following parameters of their IKE SA:

3. 3 .

 3 IKEv2/IPsec Context Detailed Description -Nonces: the INITIATOR nonce and RESPONDER nonce (Ni and Nr) are randomly generated values which reinforce the security by refreshing the key material.

3. 4

 4 GET and PUT functions: Description 3.4.1 Motivation: manage and transfer of and IKEv2/IPsec context We propose a framework (fig. 3.1) to dynamically manage an IKEv2/IPsec context. New features are introduced in section 3.4.2 (GET and PUT). This framework proposes to extract and re-install an IKEv2/IPsec context from one SG to another, which we refer as IPsec-CXT (IPsec context transfer).

3. 4 .

 4 GET and PUT functions: Description

Figure 3 . 1 :

 31 Figure 3.1: Schema of an IKEv2/IPsec Context Transfer Mechanism in a Gateway

  (i) smallest observation (ii) lower quartile (iii) upper quartile (iv) largest observation (v) the median

Figure 3 . 2 :

 32 Figure 3.2: Box-and-Whisker plot representation (quartiles)

  Time to set a VPN (s) Number of Virtual Private Networks

Figure 3 . 3 :

 33 Figure 3.3: VPN Establishment Time

  Our second test consists in measuring the time to GET and to PUT an active IKEv2/IPsec context. First, we established different scenarios (different amount of active tunnels): 10, 20, 30, 40, 50, 60, 70 , 100, 200, 300, 400, 500, 600, 700 and 1k active VPN tunnels. Then, we proceed to GET ten (10) randomly chosen VPNs over each scenario[START_REF] Allard | An application of the context transfer protocol : IPsec in a IPv6 mobility environment[END_REF]100,200...). The resulting time to GET 10 randomly chosen VPNs is divided by 10 in order to obtain the average time to perform a GET over a single VPN connection. Detailed results are shown in figure3.4a. We can observe that the values are quite similar for all the scenarios (we consider the case of 10 and 30 VPNs isolated variations, which is normal). The command ipsec get performs its task in a range of 5ms up to 15ms. By the way, by observing figure 3.4a we can realize that a loaded SG (600-700

Figure 3 . 4 :Figure 3 . 5 :

 3435 Figure 3.4: Experimental IKEv2/IPsec Context Management

Figure 3 .

 3 5 represents the download time concerning all file sizes and rates. Each

3. 7 .

 7 Conclusioncases where different SGs own different IP addresses, other extensions of IKEv2 (i.e. REDIRECT or mobility operations) are referred. Additionally to GET and PUT operation delays, we will consider the added network delays when performing an IPsec-CXT.Regarding a classic network behavior, we consider the results of GET and PUT functions as optimistic. Based on the results in section 3.5.2, the worst case to perform a GET and a PUT are 15ms and 22ms respectively. This means that we can reestablish a tunnel within 37ms (15ms to GET + 22ms to PUT). However, in chapters 4 and 6, we will consider the time while transferring the IKEv2/IPsec context from one SG to other. Finally, for those scenarios where the SGs have different IP addresses, we need to consider the time to update the Security Associations at the EU's side too. Context Transfer: ClusterIP This chapter introduces the IKEv2/IPsec context transfer between different SGs with a shared common IP address. This is what we call a Mono-LAN configuration. We concentrate on studying and configuring a VPN platform (using strongSwan) based on a mechanism called ClusterIP, which offers High Availability together with load-balance features. The packets going towards the cluster are spread among the cluster's members according to a hash of the End-User's IP address. We demonstrate that ClusterIP improves the availability of upper-layers services, even though it is limited to the implementation within a same network segment, as it is required to maintain a shared common IP address based on Multicast MAC addresses.

Section 4 . 4 . 1 .

 441 1 presents the motivations and introduce the Mono-LAN scenario. Section 4.7.1 define our testbed. Section 4.3 presents the related work. Then, section 4.4 describes the challenge to overcome VPN counters synchronization during an IPsec context transfer. The following section 4.5, explains how to set up the platform with ClusterIP. Section 4.6 explains how 50 Motivations and Mono-LAN High-Availability Scenario strongSwan implements ClusterIP in order to create IPsec SG clusters. Section 4.7 shows the experiments performed as well as the results obtained. And section 4.8 gives our conclusions.4.1 Motivations and Mono-LAN High-Availability ScenarioNowadays, mobile operators are facing the exponential growth of mobile data. Among different solutions, a short term alternative consists in switching mobile data from Radio Access Networks (RAN) to WLAN network. For example, the iWLAN[START_REF]3gpp system to wireless local area network (wlan) interworking[END_REF] architecture proposes to carry the IP data between the End-User (EU) and the operator's core network through a WiFi access. Once the EU is transferred to the WiFi access, it establishes an IPsec connection with a dedicated Security Gateway (SG) that gives access to some services or simply to the Internet. Furthermore, this IPsec session should maintain the QoS prior to offload and the SG must remain available and reliable to EUs.The industry is increasingly interested in providing services with High Availability (HA) capacities. The HA clusters aim to increase the availability of a service. In terms of IPsec, an HA IPsec cluster increases the IPsec service's availability. For example, when an IPsec tunnel is established towards a given SG within a cluster, the IPsec parameters might be spread among its cluster members. In the event of a failure during an IPsec session, some other SGs must ensure the VPN service. Actually, the availability and the continuity of service are guaranteed by different mechanisms.

Chapter 4 .

 4 Mono-LAN Context Transfer: ClusterIP 51

  active SG if a failure occurs to the active SG. Both SGs synchronize all their IPsec tunnels so that they keep track of every single tunnel established with any EU. Our experiments are mainly focused in causing a failure to the active SG during a VPN session and evaluating the High Availability performances of the platform. At this point, the passive SG (not affected by the failure) detects no activity through the Synch Channel between them and consequently applies a new ClusterIP policy and becomes the newly active SG for a given IPsec tunnel. This ensures availability of the VPN services and avoids renegotiation from scratch of each tunnel of concerned EUs.

4. 4 .

 4 IKEv2/IPsec and High Availability ConstraintsClusterIP-based mechanism does not need additional IKEv2 payloads, so it is transparent to EUs.-RFC6027: IPsec Cluster Problem Statement[START_REF] Nir | IPsec Cluster Problem Statement[END_REF] unifies the terminology in terms of IPsec clustering. It also adresses the problem statement and the requirements to implement IKEv2/IPsec clusters. Multi-vendor solutions considering to implement IKEv2/IPsec clusters should use this terminology. This document identifies the main issues while implementing IPsec Clusters. These are the IKE Message ID and IPsec counters, a lot of long-lived state, the simultaneous use of IKE and IPsec SA among different members and the SPI allocation.These issues are explained in detail along this article. Finally, here are some definitions extracted from the document that helps to position our work: -RFC6311: Protocol Support for High Availability of IKEv2/IPsec [15]. This RFC proposes an extension to the IKEv2 protocol. It aims to solve the refreshing of both IKEv2 (IKE SA) and IPsec (CHILD SA or IPsec SA) counters due to a mismatch caused by a failure take-over process. The scenario addressed in the document is oriented to solve hot-standby IPsec-Clusters failures. A hot-standby IPsec-Cluster consists in a group of IPsec SGs in which there is only one member active at a time. All the IKEv2/IPsec contexts are distributed among all the members of the cluster. When a failure occurs on the active SG during an IKEv2/IPsec communication, the End-User (EU) continues sending IKEv2/IPsec traffic towards the cluster, leading to unsynchronized counters and packets loss. In order to reestablish the synchronization of counters, the new SG sends an IKEv2 message request of type INFORMATIONAL in order to negotiate counters. Concerning our work, this protocol solves the main troubles of synchronization of both IKEv2 messages (IKE SAs) and IPsec counters (CHILD SAs). Although it involves changes to the IKEv2 protocol, this extension handles the renegotiation of the IKEv2/IPsec counters in an efficient manner and should be considered if any IKEv2/IPsec counters mis-synchronization occurs.

Chapter 4 .

 4 Mono-LAN Context Transfer: ClusterIP 53 is the goal of ClusterIP. Clustering a VPN service at the network layer level (e.g. IPsec) seems to have positive impact when dealing with reliability of IPsec-based communications. Because IPsec imposes a strict check of its counters, the main issue is to synchronize both SG's IPsec parameters and counters. When an EU establishes an IPsec protected communication with a server, it first needs to configure how to protect the communication with the SG. The protocol used to negotiate the security parameters of the communication is IKEv2. Further exchanges allow to agree on a secure channel that serves to negotiate the IPsec parameters (to actually protect the IP traffic). IKEv2 and IPsec are different protocols with their own counters. The message ID counters provide anti-replay protection and keep track of every IKEv2 exchange, whereas the sequence numbers provide anti-replay protection and strict control of IPsec traffic.

Figure 4 .

 4 1a shows an example of the mis-synchronization during IKEv2 exchanges between two endpoints with a window size w = 1.Challenges concerning IKEv2 when implementing cluster of IKEv2/IPsec SGs are:Stale Value of Message ID: when takeover takes place, it is possible that the newly active SG is not aware of the last IKEv2 response made by the previously active SG. If this happens when taking responsibility, then the message ID used by the new responsible SG will be stalled.

Figure 4 .

 4 1a illustrates this case.

4. 4 .

 4 IKEv2/IPsec and High Availability Constraints(a) Stale Messages ID values (b) Stale Sequence Number value

Figure 4 . 1 :

 41 Figure 4.1: IKE/IPsec counters desynchronization

4 . 3 for

 43 more details). As stated before, this kind of representation is used to plot statistical data.The box-and-whisker plot indicates: (i) the smallest observation, (ii) the lower quartile, (iii) the upper quartile, (iv) the largest observation and (v) the median. The space between the lower and upper quartile represents 50% of the samples.During the tests, we used two different implementations (time and top) in order to measure the IPsec performance under different circumstances. The command time, launches the specified program command with given arguments. When the command has finished to run, time writes a message to the standard output giving timing statistics about this program run. The outputs of time are (i) the elapsed real time between invocation and termination of the command, (ii) the user CPU time or cpu-us spent executing instructions of the calling process and (iii) the system CPU time or cpu-sys spent in the system while executing tasks on behalf of the calling process.The command top, provides the real-time CPU activity. It shows a list of the ongoing system tasks . We identified the IPsec related task ID within this list and we collected all the information concerning the CPU consumption during the tests. All tests were done using different number of CPUs in order to compare the impact of having several CPUs sharing the workload (1,2,3 or 4 CPUs).

Figure 4

 4 Figure 4.2: Scenarios

  second test evaluates the quality of service (QoS) ensured by the HA plugin in terms of upper-layers (e.g. HTTP-based downloads) reactivity. The test consists of downloading a file of size 50MB from the HTTP server towards the VPN peer. On the client side, we measure the Elapsed Time (obtained via the command time), which represents the time to complete the download. We do the same for both topologies (with & without HA-plugin, figures B.2a and B.2b correspondingly), thus comparing the impact of the HA-plugin and added overhead during the download. Both scenarios consider the encryption and integrity protection with AES128 and SHA1 algorithms respectively. With the ClusterIP-based plugin activated, both figures illustrate the time to download a file of size 50M B. Figures 4.5a

, 4 .

 4 5b show the download time through Ethernet connections. The User Time stays invariable.

  Enc:NULL + HA-plugin

Figure 4 . 4 :

 44 Figure 4.4: First Test: Download Performance Test (time)

Figure 4 . 5 :

 45 Figure 4.5: Second Test -QoS on an HTTP Connection

  figure B.2a. The test consists of downloading a file of size 500M B from the HTTP server towards the VPN peer. After 5 seconds of download, we interrupt the outgoing network interface of the active VPN SG, causing a failure event. The passive SG of the cluster stops receiving responses through the Synch Channel, and thus takes responsibility of the VPN tunnel. We captured the traffic between the VPN peer and the cluster during the test.Figure 4.1 represents some

Figure 4 .

 4 1 represents some protected ESP traffic at the IP layer. The period of time between the last ESP packet emitted by the active SG (SG1) and the first ESP packet emitted by the passive SG (SG2) is considered as the Handover Time. This time corresponds to the network delay of takeover from the active node to the passive SG.

Figure 4 .

 4 Figure 4.6 represents the results obtained when measuring the Handover Time. The quartiles

Our first scenario is shown in figure B. 3 .Figure 5 . 1 :

 351 Figure 5.1: High Availability scenario for n gateways

5. 2 .Figure 5 . 2 :

 252 Figure 5.2: High Availability scenario for n=2 nodes

Figure 5 .

 5 Figure 5.2 represents a cluster of n=2, where only one SG is active at a time. The SG1

Figure 5 . 3 :

 53 Figure 5.3: Context Management scenario

4 ,

 4 one main obstacle to perform HA or context management under IPsec environments are the counters associated with every security association established. This standard defines an extension of IKEv2 in order to allow resynchronization of those counters. There are actually two types of them: message ID and sequence numbers (see section 4.4 for details). When transferring the IKEv2/IPsec context between different SGs,

Chapter 5 .Figure 5 . 4 :

 554 Figure 5.4: Original audio file transmitted on streaming during tests

Figure 5 . 5 :

 55 Figure 5.5: Testbed 1 -High Availability

Figure 5 . 6 :

 56 Figure 5.6: Testbed 2 -Context Management

Chapter 5 .Figure 5 . 7 :Figure 5 . 8 :

 55758 Figure 5.7: HTTP audio streaming protected with IPsec

Chapter 5 .Figure 5 . 9 :

 559 Figure 5.9: AES128-CBC encryption

Figure 5 . 10 :

 510 Figure 5.10: AES128-CTR encryption

Chapter 5 .

 5 Mono-LAN Context Transfer: Context Management 83 5.4.2.4 Software for measuring audio QoS: POLQA

Figure 5 .

 5 Figure 5.11 and 5.12 illustrate the switching time for all different scenarios and parameters presented in section 5.4.2 during an audio streaming of 8sec. The term switching time is considered as the network time that a VPN session is interrupted while being transferred from SG1 to SG2 (or vice-versa). During a HA event (e.g. from SG1 to SG2), we calculate the switching time by subtracting the time when the first packet arrives from SG2 by the time when the last packet comes from SG1. This is done through the analysis of network captures during tests.

Figure 5 .Figure 5 . 11 :

 5511 Figure 5.11 represents the case where the switching frequency (a.k.a. frequency of interruption) is f= 1 /8s. It illustrates the time to switch from SG1 to SG2 according to the bit rate used: 8Kbps, 48Kbps or 96Kbps. The left side of the graph represents HTTP and

Figure 5 .

 5 Figure 5.12 illustrates the switching time caused by different switching frequencies from

Figure 5 . 12 :

 512 Figure 5.12: Switching time for several interruption frequencies ( 1 /8s, 2 /8s, /8s and 4 /8s). High Availability -Audio source file 8sec

5. 5 . 1 . 2 Figures 5 .

 5125 Figures 5.13 and 5.14 show all the results in terms of QoS. POLQA's scores from zero (low quality audio) to five (high quality audio).

Figures 5 .

 5 Figures 5.13a and 5.13b represent the results of the QoS for different switching frequencies,

Figures 5 .

 5 Figures 5.15 and 5.16 represent the results of an IKEv2/IPsec context transfer under the context management testbed, considering all the parameters and scenarios described in section 5.4.2.

Figure 5 . 16 :

 516 Figure 5.16: Switching time for one interruption ( 1 /8s) -Context management -Audio source file: 8 seconds

  Figures 5.17 and 5.18 illustrate results in terms of QoS. We consider the same scenarios and parameters as for the network performance results, so we can compare them.

  IKEv2/IPsec Context Transfer This chapter introduces the IKEv2/IPsec context transfer considering SGs with different IP addresses. This is what we call a Multi-LAN context transfer. Actually when a SG transfers an IKEv2/IPsec context to another SG, all the security parameters and cryptographic material are also transfered as fast as possible in order to avoid incoherent or unsynchronized states (especially IPsec counters). Throughout this chapter, we introduce a mechanism based on MOBIKE extension of IKEv2 (discussed in section 2.6) allowing to change the attachment point of a peer during an active IPsec session. This includes the theoretical process to achieve such mechanism as well as we provide some developments recommendations. The practical tests and developments for this scenario are left as future work.

Figure B. 5

 5 Figure B.5 illustrates a schema allowing to use MOBIKE with the transfer of the IKEv2/IPsec context. At step 1, before mobility occurs, the old SG transmits the IKEv2/IPsec context to the new SG. Once the context is received, during step 2, the new SG initiates a MOBIKE exchange in order to inform the other peer that the VPN tunnel has changed its IP address to @SG IP2. At step 3, the IKEv2/IPsec databases are up to date concerning the new IP address of the SG side. Now, the continuity of the VPN service is ensured. What are the impacts of using Transport Mode and Tunnel Mode? As discussed in section 2.3, transport mode and tunnel mode represent two different uses cases of IPsec. Considering the transfer of an IKEv2/IPsec context, both scenario might have different impact in terms of IP mobility. When tunnel mode is used, the outer IP header of the IPsec-protected traffic is changed, whereas the inner IP address of the tunnel stay unchanged.

B. 2 . 1 :

 21 network technologies, which may include different devices (constructors) as well. However, RANs have now migrated to IP based communications. This allows us to propose IPsec as a security mechanism all over the network. Our interest is to continue our investigations in order to introduce more sophisticated mechanisms that allow maintaining the same security 118 Objetif de la thèse l'équilibrage de charge pour les connexions IPsec. Ces mécanismes ont pour finalité d'augmenter la continuité de service de sessions IPsec.Certains nouveaux mécanismes ont été récemment mis en oeuvre pour assurer la haute disponibilité sur IPsec. Le projet open source VPN, StrongSwan, a mis en place un mécanisme appelé ClusterIP afin de créer un cluster de passerelles IPsec. Nous avons fusionné cette solution basée sur ClusterIP avec nos propres développements afin de définir deux architectures : une architecture permettant la Haute Disponibilité et une deuxième architecture présentant la gestion dynamique d'un contexte IPsec. Nous avons défini deux environnements : le Mono-LAN où un cluster de noeuds est configuré sous une même adresse IP unique, et le Multi-LAN où chaque passerelle de sécurité dispose d'une adresse IP différente.Les mesures de performance tout au long de la thèse montrent que le transfert d'une session VPN entre différentes passerelles évite les délais supplémentaires liés à la ré-authentification et réduit la consommation CPU, ainsi que les calculs par le matériel cryptographique. D'un point de vue FAI, le transfert de contexte IPsec/IKEv2 pourrait être utilisé pour éviter la surcharge des passerelles, et permettre la redistribution de la charge, de meilleures performances du réseau ainsi que l'amélioration de la qualité de service. L'idée est de permettre à un utilisateur de profiter de la continuité d'un service tout en conservant le même niveau de sécurité que celui initialement proposé.B.2 Objetif de la thèseL'objectif de cette thèse est de permettre aux infrastructures VPN IPsec de fournir une haute qualité de service aux clients ainsi que d'assurer la continuité du service VPN. Plus précisément, nous voulons que les connexions VPN puissent résister aux échecs et défaillances. L'une des architectures abordées tout au long de cette thèse est l'haute disponibilité (High Availability, HA). Nous voulons aussi que les FAI puissent facilement gérer la charge due au trafic VPN de leurs clients (c'est ce que nous appelons gestion du trafic ou de gestion d'un contexte IPsec). Ainsi, lorsque une plate-forme VPN multi-noeuds est utilisé par le fournisseur d'accès Internet, celle-ci devrait être capable de transférer une connexion VPN d'un noeud à un autre, en introduisant le concept de transfert de contexte. Ainsi, quand une session VPN est transférée, cela signifie que tous les paramètres relatifs à cette session sont transférées également. En effet, il y a des scénarios où la possibilité de transférer une session VPN d'une SG à une autre aurait des effets positifs. Certains cas d'utilisation impliquent: l'équilibrage de la charge dû au trafic VPN entre les différents noeuds du cluster, le transfert entre différents réseaux d'accès ou l'amélioration de basculement entre clusters offrant la haute disponibilité (HA). Solutions for each scenario avoir plusieurs passerelles avec des adresses IP différentes et répartir géographiquement celles-ci afin qu'ils offrent une meilleure qualité de service aux utilisateurs. Nous devons donc définir de nouvelles solutions qui permettent la gestion du trafic ainsi que la haute disponibilité pour IPsec/IKEv2. Nous voulons aussi avoir le moins d'impact possible sur les utilisateurs. C'est pourquoi nous devons définir un mécanisme permettant d'effectuer la gestion du trafic entre SGs avec des adresses IP différentes (Multi-LAN). Le tableau B.1 résume la solution proposé pour chaque scénario. Par exemple, lorsque nous effectuons la gestion du trafic dans une architecture mono-LAN, nous aurons besoin d'effectuer le transfert du contexte afin de maintenir la session VPN active. B.5 Organisation du Résumé Le manuscrit est composé de six sections principales dont nous montrons les principales conclusions et perspectives de chaque solution. La section B.6, lequel introduit les notions et les connaissances nécessaires afin de comprendre ce document. Cette description inclue les protocoles IKEv2 et IPsec. Il introduit aussi les notions des différentes mécanismes appelés: REDIRECT, MOBIKE et ClusterIP. La section ?? identifie les éléments à prendre en compte dans un contexte IKEv2/IPsec. Nous présentons nous premières résultats de nos développements du GET et PUT. Nous illustrons le temps que cela prendre pour récupérer un contexte entier ainsi que le temps de sa réinstallation sur une même passerelle de sécurité. Les séctions B.8 et B.9 sont dédiées à l'architecture Mono-LAN. D'abord, nous analysons ClusterIP, et nous décrivons comment celui-ci améliore la disponibilité d'un service VPN. En suite nous montrons les résultats de nos tests. D'ailleurs, nous observons les pros et contres de cette solution. Nous allons définir en suite deux architectures pour IKEv2/IPsec: Haute Disponibilité et Gestion du Trafic.Nous présentons nos implantations à travers de nos fonctions GET et PUT , lesquels sont le coeur du transfert de contexte IKEv2/IPsec. Dans la section 6, nous nous adressons à des plates-formes VPN dans des environnements multi-LAN. Nous présentons une solution permettant d'effectuer le transfert de contexte entre les différentes passerelles qui possèdent des adresses IP différentes. Nous montrons comment le B.8. Section 3: Mono-LAN En ce qui concerne un comportement du réseau classique, on considère les résultats des fonctions GET et PUT comme optimistes. Selon les résultats, le pire des cas à effectuer un GET et un PUT sont de 15ms et 22ms respectivement. Cela signifie que nous pouvons rétablir un tunnel dans 37MS (15ms pour obtenir le contexte avec GET + 22ms à effectuer un PUT). Cependant, dans les sections à suivre, nous allons tenir en compte le temps pour transférer le contexte IKEv2/IPsec d'une SG à l'autre. Enfin, pour les scénarios où les SG ont des adresses IP, nous devons prendre en considération le temps de mettre à jour les associations de sécurité du côté du client aussi. B.8 Section 3: Mono-LAN Tout au long de cette section, nous avons mesuré l'impact et la performance à l'aide d'un module de ClusterIP modifié afin de clusteriser différentes SGs avec IPsec. La disponibilité du service IPSec est améliorée grâce à la mise en place d'un system hot-standby assurée par ClusterIP. Aussi, strongSwan garantit la continuité d'une session IPsec grâce à son module HA permettant de diffuser tous les tunnels IPsec entre ses membres du cluster. Les résultats ont montré qu'une SG active dépense de 5% à 8 % de CPU de plus qu'une SG passive lors de l'établissement des tunnels IPsec. Nous avons également constaté qu'il y a une charge supplémentaire lors de l'utilisation du plugin de strongSwan parmi les membres du cluster. Le téléchargement d'un fichier de 500 Mo prenais 20% de plus du temps lors de l'utilisation ClusterIP et le plug-in. C'est pourquoi un administrateur souhaitant mettre en place cette solution doit prendre en compte les coûts de la performance en ajoutant ses fonctionnalités de haute disponibilité à son service VPN. Par ailleurs, un inconvénient principal de ClusterIP est sa limitation à être déployé au sein d'un même segment de réseau. Les sections suivantes se concentreront sur l'utilisation de notre propre outil de gestion de tunnel VPN qui permet le transfert IPsec entre SG dans des environnements mono-LAN. Finalement, on finalisera par le transférer d'un contexte IKEv2/IPsec entre deux SG possédant des adresses IP différentes. B.9 Section 4: Mono-LAN: L'haute disponibilité et la gestion du trafic VPN Tout au long de cette section, nous avons décrit le transfert de contexte IKEv2/IPsec dans un environnement mono-LAN, où un cluster offre un service VPN en étant configuré avec une adresse IP commune. Contrairement à la cette section précédente, cette fois nos scénarios comprenaient le transfert de contexte IKEv2/IPsec entre passerelles physiquement différentes. Nous avons défini deux nouvelles composantes: le Heart-Beat et le SYNCH. Ces composants permettent de synchroniser chaque tunnel qui est négocié avec l'un des membres High Availability Reference QoS ( 0 /8s)

  Nos résultats sont présentés en termes de comportement du réseau et du QoS. Pendant les essais de HA, nous avons remarqué que le comportement du réseau des protocoles orientés non-transmission (par exemple UDP) sont moins impactés par un événement de basculement qu'un protocole orienté à connexion (tel que TCP). En fait, en raison de la nature de TCP qui impose de accuser les paquets transmis, ceci génère des retards supplémentaires pour récupérer les basculement. Cependant, d'un point de vue QoS, TCP a obtenu de meilleurs résultats que UDP. En effet, avec UDP, les paquets qui sont perdus lors des événements de basculement ne sont pas récupérés, dégradant ainsi la qualité de service. Concernant les résultats de la gestion du trafic, nous avons remarqué que les protocoles orientés connexion sont moins impactés par rapport aux scénarios où les fonctionnalités HA sont actives. Ceci est principalement dû au temps que prend le Heart-Beat d'accomplir sa tâche. En fait, au cours d'une gestion de contexte, il n'y a plus de Heart-Beat impliqué lors du transfert du contexte IKEv2/IPsec, et donc, le SG qui prends la responsabilité d'une connexion n'a pas besoin d'attendre de vérifier la vivacité de la passerelle et donc d'installer la nouvelle session IPsec. Les futurs travaux comprennent l'interaction de IPsec sur un transfert de contexte entre SG avec des adresses IP différentes. Même si nous avons amélioré le service VPN par la création du cluster de noeuds avec une adresse IP unique, un FAI peut également être intéressé par le déplacement d'une session IPsec entre SG distants avec des adresses IP différentes. Nous pensons que cela peut être avantageux d'assurer la continuité d'un service VPN pour un utilisateur mobile qui est probablement en train de changer son point d'attachement. Ceci est expliqué en détail dans section suivante.

  QoS for several interruption frequencies ( 1 /8s, 2 /8s,3 /8s and 4 /8s) -Context management -Audio source file: 8 seconds . . . . . . . . . . . . . . . . . . . . . . 93 5.18 QoS measurements for one interruption frequency ( 1 /8s). Context Management -Audio source file: 8 seconds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.1 Mobility and Multihoming performed with MOBIKE extension . . . . . . . . . . 102 6.2 Scenario of a Multi-LAN IKEv2/IPsec context transfer . . . . . . . . . . . . . . . 104 Scenarios de transfert du context IKEv2/IPsec . . . . . . . . . . . . . . . . . . . B.2 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.3 High Availability scenario for n gateways . . . . . . . . . . . . . . . . . . . . . . B.4 Context Management scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.5 Multi-LAN IKEv2/IPsec context transfer . . . . . . . . . . . . . . . . . . . . . . B.6 Scenario of a Multi-LAN IKEv2/IPsec context transfer . . . . . . . . . . . . . . .

	List of Figures	xiii
	B.1

). High Availability -Audio source file duration: 8 seconds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.12 Switching time for several interruption frequencies ( 1 /8s, 2 /8s, 3 /8s and 4 /8s). High Availability -Audio source file 8sec . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.13 QoS for several interruption frequencies ( 1 /8s, 2 /8s, 3 /8s and 4 /8s). High Availability -Audio source file duration: 8 seconds . . . . . . . . . . . . . . . . . . . . . . . . 87 5.14 QoS measurements for one interruption frequency ( 1 /8s). High Availability -Audio source file: 8 seconds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.15 Total switching time for several interruption frequencies ( 1 /8s, 2 /8s, 3 /8s and 4 /8s). Context management -Audio source file: 8 seconds . . . . . . . . . . . . . . . . . 90 5.16 Switching time for one interruption ( 1 /8s) -Context management -Audio source file: 8 seconds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.17 6.3 Multi-LAN IKEv2/IPsec context transfer . . . . . . . . . . . . . . . . . . . . . . 107 A.1 Commands for VLC server and client . . . . . . . . . . . . . . . . . . . . . . . . . 116 xiv List of Figures

  /IPsec context transfer saves almost 10 times the overhead produced by IKEv2/IPsec tunnel establishment. It presents the theoretical case where a Mobile Router switches its IPsec SAs from one Home Agent

to another Home Agent, and presented IKEv2/IPsec context transfer as one way to optimize this inter Home Agent migration. The context transfer can be either triggered by the Mobile Router or by the Home Agent. Finally, a MOBIKE exchange is performed in order to update

  1.4. Related work and position of our work corresponding security association of a tunnel. However, a collision of SPIs could happen when transferring IKEv2/IPsec contexts between different devices. Allard et al. psopose MOBIKE in

  We based our implementation on XFRM, which actually allows updating sequence number values of IPsec Security Associations. We managed to separate each parameter of the security association within the implementation in order to update these counters (for IKE and IPsec), whereas such achievement ins not possible with PF KEY.Allard et al. tested their implementation using an UDP traffic generator. This traffic generator has been configured to reproduce UDP packets every 50ms within a single VPN established session. We consider this experimentation is a proof of concept, however, as mentioned by Allard et al., under heavy traffic situations, more work is needed to handle IKEv2/IPsec counter synchronization. In our case, we tested our implementation under heavy load situations, which give us a clear response of the impact against upper layers. Additionally,

use an implementation called PF KEY to manipulate the IPsec related kernel information. PF KEY originates from BSD, and is implemented in Linux as well. However, it is now deprecated and was replaced by an implementation called XFRM, Chapter 1. Introduction 13 which is newer and more robust. we tested how IKEv2/IPsec context transfer impacts real time services through network measurements as well as Quality of Services (using POLQA

  1.5. Contributions updated for every IKEv2 or IPsec packet, since any inbound or outbound packet updates IPsec or IKE counters. With heavy load this is hardly possible, as a result we define different strategies according to the load the Security Gateways have to deal with.2. We define a synchronization timer for IKEv2 and IPsec databases. This timer can be dynamically assigned according to the load,the more loaded the active node is, the longer the timer should be. Once the duration of the timer has been defined, the IPsec and IKEv2 databases are synchronized periodically based on the timer policy. During a failover event, the IPsec standard allows to increase the IPsec database counters in order to resynchronize stale values once a context transfer is performed. In contrast, if the timer cannot be increased (e.g. heavily loaded SGs scenarios), then the active node must perform

additional IKE exchanges in order to resynchronize IKE SA's counters (see chapter 4). The reason why IKE SAs synchronization gets higher priority compared to IPsec SAs, is that an IPsec SA can be re-synchronized using different mechanisms like REKEY, creation of a new IKE SA or eventually resynchronization using the IKEv2 channel. However, if desynchronization occurs with the IKEv2 counters, then synchronization through IKE exchanges is the only mechanism that makes possible IKEv2 counter resynchronization.

Roadmap of IPsec and IKEv2 protocols 21 Internet IPsec Transport Mode

	Chapter 2. IPsec protected path Host A	Host B
	Figure 2.1: IPsec transport mode scenarios.
	IPsec offers interoperable, high quality and
	cryptographically-based security for both Internet Protocol versions: IPv4 and IPv6. The most
	common usage of IPsec consists in creating tunnels, often called Virtual Private Networks
	(VPNs). Actually, IPsec is used to create trusted environments through unprotected networks.
	When an entire network is being protected with IPsec, then tunnel mode is used. Otherwise,
	when the communication exclusively takes place between two hosts, then transport mode is more
	suitable. Figure 2.2 illustrates the scenarios where tunnel mode can be used, while figure 2.1
	illustrates the transport mode scenario.
	A Security Association (SA) is a data structure that contains security parameters to allow
	instantiation of an IPsec communication. The set of SAs is stored in the Security Association
	Database (SAD). Its goal is to offer security services for incoming/outgoing traffic it carries. As
	a SA is unidirectional, two SAs are needed in order to protect both ways of a bidirectional
	IPsec-based communication. In addition, some data are also stored in the Security Policy
	Database (SPD). The SPD is consulted to define appropriate behavior facing incoming and
	outgoing IP packets by specifying which traffic should be protected with IPsec or should bypass
	IPsec. It is consulted for all inbound and outbound traffic. The SA relies on Authentication

Internet

IPsec Tunnel Mode

	Host A	IPsec protected path	Host B
	(a)

Endpoint to Endpoint Tunnel Internet IPsec Tunnel Mode

		Extremity of the tunnel	Extremity of the tunnel
		Host A
	Protected Subnet IPsec Security
		Gateway		Host B
			IPsec protected path
		(b) Endpoint to Gateway Tunnel
	Extremity of the tunnel	Extremity of the tunnel
	Host A		Host B
	Internet
	IPsec Tunnel Mode
	Protected Subnet IPsec Security Gateway	IPsec Security Gateway	Protected Subnet
	IPsec protected path
	(c) Gateway to Gateway Tunnel
	Figure 2.2: IPsec tunnel mode scenarios.
	Header (AH; see section 2.3.1) and Encapsulating Security Payload (ESP; see section 2.3.2)
	protocols to offer its security services. Finally, all the parameters concerning SAD and SPD could
	be configured manually by an administrator or could also be configured dynamically thanks to
	the Internet Key Exchange Protocol (IKE). When IKE is used (which is mostly the case), an
	additional database known as Peer Authorization Database (PAD) links each authorized identity
	to its corresponding security parameters, thus, providing a link between IKE and each policy
	stored in the SPD. Further details concerning IKE are explained in 2.4.
	IPsec can be deployed under different scenarios. Depending on the concerned topology, IPsec
	can be configured in two modes: transport mode or tunnel mode. Even if both modes use the
	same techniques and algorithms to encrypt/decrypt, the difference relies on the encapsulation
	and how a packet is built. Each mode has its own uses and thus it is important to care about
	the selected one in order to run IPsec properly.

Table 3 .

 3

	Interruption	Rate	File
	Time TS		Size
		10 kB/s	1MB
		100 kB/s	5MB
	10s, 30s	500 kB/s	20MB
	and 60s	1 MB/s	20MB
		2 MB/s	20MB
		3 MB/s	100MB
		5 MB/s	100MB
		10 MB/s 100MB
	figure ( 3.5b, 3.

1: Third Test -Interruption Times, Traffic Rate and File Sizes

  ClusterIP-based HA Plugin of two nodes maximum. This section explains how the HA plug-in achieves active/active High Availability and Load Sharing capabilities.

	The IKE daemon of strongSwan synchronizes the IKE SA database and the basic IPsec SA
	database without Sequence Numbers. The remaining tasks are carried out by a modified
	ClusterIP plug-in called High Availability (HA). The HA plug-in requires two patches against
	the kernel in order to allow ClusterIP to work with IPsec. These patches modify the ClusterIP
	netfilter module, more specifically, the PREROUTING hook that marks received packets for
	forwarding before the decryption/encryption process. A third patch is required to modify the
	Linux firewall (iptables) in order to work over the patched kernel.

Its High-Availability plugin implements a ClusterIP-based mechanism that is able to maintain IKE SAs and IPsec SAs in case of failover. The current release strongSwan 5.x supports clusters 4.6. StrongSwan's

Table 4 .

 4

	Control messages : table 4.3 shows the different control messages implemented by the HA
	plugin. These messages are sent along with the synchronization messages with the purpose
	of notifying segment responsibility changes.

[START_REF]Cisco visual networking index: Global mobile data traffic forecast update[END_REF]

shows the hooks used by the HA plugin.

Synchronization messages: table

4

.2 shows the different synchronization messages types that can be exchanged between nodes in a cluster according to the implemented HA plugin of strongSwan. Messages are sent with no encryption by the hook functions using UDP datagrams on port 4150. However, an IPsec tunnel could be established in order to transmit this information. State synchronization: state changes are executed by Synchronization messages exclusively. They carry all the information required to create a duplicate of the active node IKE SAs and IPsec SAs. Duplicated IKE SAs do not handle traffic and are installed in a PASSIVE state while duplicated IPsec SAs are installed in the Kernel and subjected to ClusterIP algorithms.

Failover: the state of a segment in a cluster is set by the HA plugin to either ESTABLISHED or PASSIVE. This is decided on each node using the same ClusterIP hashing function based on the source IP address. By using the same hashing function it guarantees that the cluster responsibility will not be assigned to both nodes at the same time. The activation/deactivation of a segment is performed over all the IKE SAs that

Table 4 .

 4 1: Hooks used by the strongSwan's HA plugin

	Hook	Description
	ike keys( )	Receives IKE key material (DH, nonce, proposals)
	ike updown( )	Monitors state changes of IKE SAs
	message( )	Used to update IKE Message IDs
	child keys( )	Receives CHILD key material
	child state change( )	Monitors state changes of IPsec SAs
	Table 4.2: Synchronization messages of the HA plugin
	Synch Message	Description
	IKE ADD	Message used when a new IKE SA is established. It contains
		all information to derive keys
	IKE UPDATE	Message used to update information of a concerned IKE SA,
		for example, when authentication is done
	IKE MID I	Updates the Message ID of the initiator
	IKE MID R	Updates the Message ID of the responder
	IKE DELETE	It is used to delete a corresponding IKE SA
	CHILD ADD	Message used when adding a new IPsec SA
	CHILD DELETE	Message used to delete an IPsec SA

are found on that actual segment. There is no impact on their IPsec SAs, they are always active.

Node reintegration: reintegration is meant to take the failed node after its recovery and reinserting it into the cluster as a backup node again. The recently reincorporated node needs to fully synchronize the state information; this is achieved by pushing all the active IKE SAs messages, cached in the active node, onto the newly arrived node. Synchronizing IPsec SAs is not possible using the cache, as the messages do not contain Sequence Number information managed in the kernel. To reintegrate a node, the active node initiates rekeying on all IPsec SAs. with an HTTP server, an IPsec peer and two VPN SGs; strongSwan is configured to provide High-Availability cluster between the SGs and its members keep in synch through the Heart Beat link (Synch Channel). In the second topology, illustrated in figure B.2b, the whole traffic goes through a single active SG, meaning that strongSwan is used as a VPN solution but with no fail-over node, thus the HA plugin is not loaded.

Table 5 .

 5

	1: Architectures and parameters addressed during tests
	section 5.4.2.

  /8s to 4 /8s (refer to 5.4.1 for details). In order to recreate a more realistic environment, the

	Chapter 5. Mono-LAN Context Transfer:
	Context Management											85
										HTTP
	Total switching time (s)	0 0.5 1 5.5 6 6.5 7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 12 12.5 13 13.5 14 14.5 15 15.5 16 16.5 17 17.5 18 18.5 19 22 22.5 23 21.5 21 20.5 20 19.5 5 4.5 4 3.5 3 2.5 2 1.5	CBC	8Kbps CTR CBC CTR CBC CTR	CBC	CTR	CBC	48Kbps CTR CBC CTR CBC CTR CBC	CTR	CBC	96Kbps CTR CBC CTR CBC CTR CBC	CTR
			1 / 8 s	2 / 8 s	3 / 8 s	4 / 8 s	1 / 8 s	2 / 8 s	3 / 8 s	4 / 8 s	1 / 8 s	2 / 8 s	3 / 8 s	/ 8 s
								Switching frequency

1

Table 5 .

 5 5.2.2 presentsthe impacts on QoS for each considered parameter. 2: Impact of the frequency of high availability events over QoS (considering the medians)

	Chapter 5. Mono-LAN Context Transfer:
	Context Management

  1 /8s, 2 /8s, 3 /8s and 4 /8s.Concerning the cryptographic algorithms, CBC and CTR obtained very similar results. We observe that regardless of the bit rate used, this has no impact over the type of encryption.

	Chapter 5. Mono-LAN Context Transfer:
	Context Management									91
									HTTP
	Total interruption time (s)	1.75 2 2.25 2.5 2.75 3 3.5 Total switching time (s) 3.25	0 0.5 1 9 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6 6.5 7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 12 12.5 13 15.5 16 17 16.5 15 14.5 14 13.5	1 / 8 s CBC CTR 8Kbps 2 / 8 s 3 / 8 s CBC CTR CBC CTR HTTP 4 / 8 s Switching frequency 1 / 8 s 2 / 8 s 3 / 8 s 4 / 8 s CBC CTR CBC CTR CBC CTR CBC CTR CBC CTR (a) Protocol: HTTP RTSP 48Kbps	1 / 8 s CBC CTR 96Kbps 2 / 8 s / 8 s 4 / 8 s CBC CTR CBC CTR CBC CTR RTSP
	Figure 5.15a and 5.15b show a linear tendency upwards. Quartiles for the HTTP scenario are more spaced than those of RTSP, showing that RTSP is more stable in terms of network performance than HTTP during interruptions. Regardless of which encryption algorithm is implemented, CBC and CTR algorithms show similar performances. Only HTTP-48Kbps indicates a little advantage of CBC compared to CTR, but in general terms, both algorithm perform similarly. As our testbed 1.5 includes a 2-core CPU's, this is the main reason why it does not make a huge influence in 2 2.5 3 3.5 4 4.5 5 5.5 6 6.5 7 8 8.5 8Kbps 48Kbps 1.5 CBC CTR CBC CTR CBC CTR 96Kbps 7.5 1 1.25 8 K b p s 4 8 K b p s 9 6 K b p s 8 K b p s 4 8 K b p s 9 6 K b p s Bit Rate (Kbps) Total switching time (s) CBC CTR CBC CTR CBC CTR
	1 terms of total switching time. For RTSP protocol (fig 5.15b), CTR showed a 3% to 5% better 0.5 CBC CTR CBC CTR CBC CTR CBC CTR CBC CTR CBC CTR CBC CTR CBC CTR CBC CTR CBC CTR CBC CTR CBC CTR
	performance than CBC. 0
				1 / 8 s	2 / 8 s	3 / 8 s	4 / 8 s	1 / 8 s	2 / 8 s	3 / 8 s	4 / 8 s	1 / 8 s	2 / 8 s	/ 8 s	4 / 8 s
	Figure 5.16 shows the switching time in function of different bit rates, considering a switching
	frequency of 1 /8s. For both protocols, the median remains very stable. We notice that RTSP Switching frequency
	performs better than HTTP. In fact, HTTP takes in average 25% more time to switch from SG1 (b) Protocol: RTSP
	to SG2 than RTSP. Although the quartiles are narrow, sometimes HTTP takes 3sec to 3.5sec Figure 5.15: Total switching time for several interruption frequencies ( /8s, 2 /8s, 3 /8s and 4 /8s).
	to perform a context management event (i.e. HTTP-CBC-8Kbps and HTTP-CTR-96Kbps). Context management -Audio source file: 8 seconds

  Table B.3 summarizes the evaluation of the QoS as long as the switching frequencies increase on a context management scenario.

	Chapter 5. Mono-LAN Context Transfer: Chapter 5. Mono-LAN Context Transfer:
	Context Management Context Management											5.5. Performance results	93 95
	POLQA -QoS	0 0.25 0.5 0.75 2.25 2.5 2.75 3 3.25 3.5 3.75 5 4.75 4.5 4.25 4 2 1.75 1.5 1.25 1	POLQA -QoS Reference CBC	0 0.25 0.5 0.75 1 1.25 1.5 1.75 2 2.25 2.5 2.75 3 3.25 3.5 3.75 4 4.25 4.5 4.75 5 Reference CTR CBC	CTR	0 / 8 s 1 / 8 s 2 / 8 s 3 / 8 s 4 / 8 s 8Kbps Reference CBC Reference CTR CBC CTR CBC CTR CBC CTR CBC CTR HTTP Reference CBC Reference CTR Reference CBC CBC CTR CBC	Reference CTR	0 / 8 s 1 / 8 s 2 / 8 s 3 / 8 s 4 / 8 s HTTP 48Kbps Reference CBC Reference CTR CBC CTR CBC CTR CBC CTR CBC CTR Reference CBC Reference CTR CTR CBC CTR	0 / 8 s 1 / 8 s 2 / 8 s 3 / 8 s 4 / s 96Kbps Reference CBC Reference CTR CBC CTR CBC CTR CBC CTR CBC CTR RTSP Reference CBC Reference CTR Reference CBC Reference CTR CBC CTR CBC	CTR
				8 K b p s			4 8 K b p s			Switching frequency 9 6 K 8 K b (a) Protocol: HTTP b p s p s	4 8 K b p s	9 6 K b p s
														Bit Rate (Kbps)
	RTSP Figure 5.18: QoS measurements for one interruption frequency ( 1 /8s). Context Management -
	5 Audio source file: 8 seconds	8Kbps				48Kbps	96Kbps
				4.75
				4.5
				4.25
		1.5 1.75 2 2.25 2.5 2.75 3 3.25 3.5 3.75 4 Context Management Reference QoS ( 0 /8s) 1 /8s HTTP-8Kbps-CBC 100% 0% HTTP-8Kbps-CTR 100% 0% HTTP-48Kbps-CBC 100% -18% -20% 2 /8s +1% 0% POLQA -QoS HTTP-48Kbps-CTR 100% -41% -31%	3 /8s 0% +5% -40% -39%	4 /8s +1% +1% -28% -33%
		0.25 0.5 0.75 1 1.25 HTTP-96Kbps-CBC Reference CBC Reference CTR CBC HTTP-96Kbps-CTR RTSP-8Kbps-CBC 0 RTSP-8Kbps-CTR	CTR	CBC	CTR	CBC	CTR	CBC	CTR 100% 100% 100% 100%	Reference CBC	Reference CTR	CBC	CTR	CBC	CTR	CBC -28% -16% CTR CBC CTR Reference CBC -33% -20% Reference CTR 0% +16% +21% +28% CBC CTR CBC CTR CBC CTR CBC CTR -40% -48% -53% -50% +3% +15% +23% +28%
		0 / 8 s 1 / 8 s 2 / 8 s 3 / 8 s 4 / 8 s RTSP-48Kbps-CBC 100%	0 / 8 s 1 / 8 s 2 / 8 s 3 / 8 s 4 / 8 s -31% -41% 0 / 8 s 1 / 8 s 2 / 8 s 3 / 8 s 4 / s -50% -52%
		RTSP-48Kbps-CTR RTSP-96Kbps-CBC							100% Switching frequency -35% -57% 100% -53% -61%	-58% -66%	-61% -68%
		RTSP-96Kbps-CTR							(b) Protocol: RTSP 100% -27% -43%	-49%	-49%
	Figure 5.17: QoS for several interruption frequencies ( 1 /8s, 2 /8s, 3 /8s and /8s) -Context Table 5.3: Impact of the frequency of context management events over QoS (considering the
	management -Audio source file: 8 seconds medians)

  , enables transferring contexts for various services (e.g. QoS, Security, Authentication, etc.) between different SGs. A Context Transfer (CT) can be either Mobile Controlled (initiated by End-Users) or Network Controlled (initiated by the newly active SG nSG or the previously active SG pSG). Once the CT is activated, it may happen that one of the end-points already knows towards which destination the context will be transferred. This case is known as predictive mode, and it is the most favorable scenario in terms of packet loss and performance, mostly because the context transfer takes place before an EU against the newly active SG, actually the EU needs to renegotiate the cryptographic information from scratch. Our proposal would be to combine this REDIRECT mechanism with the transfer of the IKEv2/IPsec context, therefore the EU would not need to re-authenticate its session again. However, this includes changes to the standard. New payloads must be added in order to carry out smooth context transfer during an active session. Therefore, if for some reason an active SG is being shut down (e.g. failure, maintenance, overload, etc.), it would be possible to REDIRECT a peer to another SG. The REDIRECT action could be performed during IKE INIT, IKE AUTH (once authentication have been verified) or during an active IKEv2/IPsec session by using an INFORMATIONAL exchange using a new notify payload. On the other hand, there is no software implementation of this standard at the moment,

	Chapter 6. Multi-LAN IKEv2/IPsec Context Transfer	101
	6.2.2 RFC5685 -Redirect Mechanism
	The RFC5685 describes a method (see 6.2 and [4]) that allows to redirect an IKEv2/IPsec
	session from a previously active SG towards a newly active SG. This mechanism does not
	pre-authenticate

the handover is done. On the other hand, if the context transfer occurs abruptly, it is known as reactive mode. Obviously this mode is less beneficial for an IKEv2/IPsec connection in terms of packet loss and performance. We should consider using this protocol in order to transmit the IKEv2/IPsec related information.

Table B .

 B 2: Impacte de la fréquence des évènements de HA sur la QoS Au lieu de cela, dans un scénario de gestion du trafic, un FAI est capable de déplacer une session IPsec en cas de besoin. Cela améliore la performance et l'expérience de l'utilisateur final. C'est la principale raison pour laquelle le scénario de gestion de trafic a des résultats plus satisfaisants.

			1 /8s	2 /8s	3 /8s	4 /8s
	HTTP-8Kbps-CBC	100%	+3%	+6% +17% +17%
	HTTP-8Kbps-CTR	100%	0%	+19% +19% +19%
	HTTP-48Kbps-CBC	100%	-50.5% -68%	-70%	-69%
	HTTP-48Kbps-CTR	100%	-52%	-62%	-69%	-69%
	HTTP-96Kbps-CBC	100%	-27%	-67%	-71%	-69%
	HTTP-96Kbps-CTR	100%	-60%	-63%	-71%	-72%
	RTSP-8Kbps-CBC	100%	+14% +31% +38% +34%
	RTSP-8Kbps-CTR	100%	+9%	+39% +39% +30%
	RTSP-48Kbps-CBC	100%	-40%	-52%	-49%	-51%
	RTSP-48Kbps-CTR	100%	-60%	-63%	-62%	-61%
	RTSP-96Kbps-CBC	100%	-57%	-60%	-59%	-60%
	RTSP-96Kbps-CTR	100%	-56%	-58%	-57%	-58%

2.8. Conclusion

4.8. Conclusions

considérais le transfert du contexte IKEv2/IPsec entre deux SG différentes, nous croyons qu'il est important de définir un algorithme qui décide la responsabilité des paquets entrants vers un cluster composé par n noeuds. Pour les scénarios de haute disponibilité, nous avons abordé les scénarios actifs/passifs, mais pour le partage de charge ou des scénarios d'équilibrage de charge, il serait important de définir cet algorithme qui déciderait comment répartir la charge entre les différents membres du cluster. En ce qui concerne les environnements multi-LAN, nous avons présenté une solution basée sur MOBIKE permettant d'effectuer le transfert de contexte. Cette solution résout le cadre d'un contexte IKEv2/IPsec entre les noeuds avec une adresse IP différente. Comme la période de la thèse touchais à sa fin, cette mise en place fait partie des travaux futurs de ma thèse. Cependant, un projet très motivant émerge afin de poursuivre nos recherches dans ce domaine. Une fois les développements de Multi-LAN sont faites, nous prétendons donner à la communauté un mécanisme qui améliore le comportement du réseau. En fait, les futurs réseaux ont tendance à être plus hétérogène, et ce mécanisme permettrait de transférer une session VPN entre différents dispositifs. En outre, on prétend réduire les retards de rétablir un nouveau tunnel VPN vers un nouveau dispositif, au lieu de transférer ces données entre les dispositifs entre eux-même. Il peut être important de concentrer les efforts à définir une sorte d'intelligence locale afin de gérer les sessions IKEv2/IPsec. Une sorte d'application capable d'externaliser la décision de la gestion des sessions. Par exemple, un cas d'utilisation serait un gestionnaire de connexions afin de décider d'effectuer un transfert de contexte, des fonctions de mobilité ou multihoming, ou de gérer dynamiquement les aspects de sécurité. Comme IKEv2 est le protocole permettant de négocier des modifications à IPsec, le gestionnaire de connexions serait en mesure de donner des ordres afin de personnaliser une session IKEv2/IPsec active. Aujourd'hui, les réseaux sont composés de plusieurs technologies d'accès, où chacun définit

level regardless of the access technology. We pretend to propose an IETF draft in order to push the standardization towards the IPsec context transfer.

Acronyms and Definitions

EU End User HA High Availability IKEv2 Internet Key Exchange, version 2 IKE SA IKE Security Association IPsec Internet Protocol security IPsec SA IPsec Security Association IPsec-CXT IPsec context transfer MN Mobile Node MIP Mobile IP SA Security Association SG Security Gateway VPN Virtual Private Network WLAN Wireless Local Area Network

the other peer that the IP address has changed, then it allows re-using the already established VPN session in order to update the IP address on both extremities of the tunnel. This avoids round-trips as well as additional calculation while creating a new IKEv2/IPsec context. Figure 6.1 represents the two main scenarios where MOBIKE is used for. The first scenario, shown in figure 6.1a, represents a peer that changes its IP address during an active IPsec session from @OLD IP ADDRESS to @NEW IP ADDRESS. At Step 1, for some reason @OLD IP ADDRESS is not reachable anymore. At step 2, the peer acquires a new address @NEW IP ADDRESS and launches an INFORMATIONAL IKEv2 exchange informing the other peer that its IP address has changed. Then, at step 3 the IKEv2/IPsec databases are updated and the tunnel is maintained without creating a new one from scratch. The second scenario (figure 6.1b) contemplates a SG with multiple interfaces and different IP addresses. This is called the multihoming feature. At step 1, the initial @SG IP1 is not reachable anymore.

At step 2, the SG uses one of its additional IP addresses in order to inform the other peer that it has changed its IP address (from @SG IP1 to @SG IP2). At step 3, the IKEv2/IPsec session is maintained by updating the IP address on both extremities of the tunnel. The communication goes on and the multihoming feature ensures continuity of the IKEv2/IPsec session.

Multi-LAN Scenario

The scenario we address with the Multi-LAN context transfer is shown in figure B.6. It illustrates a set of n SGs offering a VPN service to an EU. Indeed, the EU reaches a server (e.g. some service proposed by the provider) by establishing a secure connection with one of SGs, authenticating and encrypting the communication between them. At some point of the VPN session, it is preferable for the operator to change the attachment point of the EU towards some other SG.

The operator has then two choices: either it deletes its actual session and let the EU establish a new VPN tunnel towards a new SG, or it activates a modified MOBIKE exchange in order to accomplish the migration of SG. Of course, it is not suitable for an operator to break off the VPN session, as the EU is negatively impacted. Section 6.4 introduces the usage of MOBIKE as a solution to perform IKEv2/IPsec context transfers in order to improve the EU experience while maintaining its VPN session alive.

Proposed solution based on MOBIKE extension

Accomplished Work Publications

The results of this thesis, are reflected in some publications and contributions. We are also - [START_REF] Migault | MOBIKE eXtension (MOBIKE-X) for Transport Mobility and Multihomed IKE SA[END_REF][START_REF] Migault | IPsec mobility and multihoming requirements : Problem statement[END_REF][START_REF] Migault | Multiple Interfaces IPsec Security Requirements[END_REF] are contribution for MOBIKE-X at the IETF.

Pieces of Software

Source code includes:

-GET and PUT functions. This implementation is based on strongSwan 4.5.0.

-IPsec-CTX form guide lines for Mono-LAN environments on a Wiki.

-A set of scripts used to perform context transfer tests for all the testbeds presented throughout this thesis.

-A webpage with some tools and explanation of our work (this web site is currently under construction).