Telesphore Tiendrebeogo

Daouda Ahmat

Damien Magoni
email: magoni@labri.fr

Reliable and Scalable Distributed Hash Tables Harnessing Hyperbolic Coordinates

Keywords: Distributed hash table, greedy routing, hyperbolic plane

Distributed hash tables (DHT) need to route requests in a scalable way. Although several solutions do exist, they often require nodes to connect to each others in a given way. Greedy routing schemes based on virtual coordinates taken from the hyperbolic plane have attracted some interest in recent years. Such schemes can be used for building distributed hash tables while letting the nodes connect to the others as they wish. In this paper, we define a new scalable and reliable DHT system based on the use of hyperbolic geometry. We provide a scalability analysis and we assess its efficiency by performing simulations. Results show that our DHT system brings more flexibility to the nodes while still being scalable and reliable in presence of churn.

I. INTRODUCTION

Distributed Hash Tables (DHTs) such as Chord [START_REF] Stoica | Chord: A scalable peer-to-peer lookup service for internet applications[END_REF], CAN [START_REF] Ratnasamy | A scalable content-addressable network[END_REF], Pastry [START_REF] Rowstron | Pastry: Scalable, decentralized object location and routing for large-scale peer-to-peer systems[END_REF], Tapestry [START_REF] Zhao | Tapestry: A resilient global-scale overlay for service deployment[END_REF] and Kademlia [START_REF] Maymounkov | Kademlia: A peer-to-peer information system based on the xor metric[END_REF] have been extensively studied for their potential to provide scalable data storage and retrieval to various wide scale P2P applications. Existing solutions all have their pros and cons as shown in [START_REF] Lua | A survey and comparison of peer-to-peer overlay network schemes[END_REF] but they usually have to set up constrained topologies.

We propose a system called Cloak able to build an overlay network without imposing a particular topology on the nodes (such as a ring, a tree or a hypercube). Each overlay node manages its portion of the addressing space and nodes can connect arbitrarily to each other. They can join and leave the P2P network efficiently without the cost of maintaining any global knowledge. Our approach is based on the work of Kleinberg [START_REF] Kleinberg | Geographic routing hyperbolic space[END_REF] that we have enhanced in order to manage a dynamic topology able to grow and shrink over time. We also propose a specific mapping function to store (key;value) pairs on the overlay nodes such as to make retrieval efficient and to avoid overloading a particular area of the overlay. We have carried out analysis and simulations to demonstrate the potential of our proposal in terms of scalability and reliability to build a DHT using hyperbolic coordinates. This work is a follow up of our previous work [START_REF] Cassagnes | Overlay addressing and routing system based on hyperbolic geometry[END_REF] describing the use and limitations of the hyperbolic plane as a virtual addressing space.

In this paper, our contributions are as follows:

• We describe the distributed addressing and greedy routing algorithms used by the DHT overlay (Section II). • We define the mapping algorithm used by our DHT system (Section III).

• We compare the complexity costs of our solution to various existing DHTs (Section IV). • We provide the results of our performance evaluation obtained by simulations (Section V).

II. HYPERBOLIC GREEDY EMBEDDING AND ROUTING

The model that we use in our system to represent the hyperbolic plane is called the Poincaré disk model. In the Poincaré disk model, the hyperbolic plane is represented by the open unit disk of radius 1 centered at the origin. In this specific model:

• Points are represented by points within this open unit disk. • Lines are represented by arcs of circles intersecting the disk and meeting its boundaries at right angles. In this model, we refer to points by using complex coordinates. An important property of the hyperbolic plane is that we can tile it with polygons of any sizes, called p-gons. Each tessellation is represented by a notation of the form {p, q} where each polygon has p sides with q of them meeting at each vertex. There exists a hyperbolic tessellation {p, q} for every couple {p, q} obeying (p -2) * (q -2) > 4. Our purpose is to partition the plane and address each vertex uniquely. We set p to infinity, thus transforming the polygons into a regular tree of degree q. This particular tiling splits the hyperbolic plane in distinct spaces and constructs an embedded tree that we use to assign unique addresses to the vertices (that we call nodes hereafter). We call addressing tree this embedded spanning tree that covers all the nodes.

In the Poincaré disk model, the distances between any two points z and w are given by curves minimizing the distance between these two points and are called geodesics of the hyperbolic plane. To compute the length of a geodesic between two points z and w and thus obtain their hyperbolic distance d H , we use the Poincaré metric which is an isometric invariant given by the formulae:

d H (z, w) = argcosh(1 + 2 × |z -w| 2 (1 -|z| 2 )(1 -|w| 2 ) ) (1)
This formulae is demonstrated in [START_REF] Anderson | Hyperbolic Geometry[END_REF] and used by the greedy routing algorithm 2.

Through the paper, we call peers or nodes, the members of the overlay. The first step in the creation of an overlay is to start the first peer and to choose the degree of the addressing Algorithm 1 Calculating the coordinates of peer's children.

1: procedure CALCCHILDRENCOORDS(peer, q) 2:

step ← argcosh(1/sin(π/q)) 3:

angle ← 2π/q 4: childCoords ← peer.Coords 5:

for 1 → q do 6:

ChildCoords.rotationLef t(angle)

7:
ChildCoords.translation(step)

8:
ChildCoords.rotationRight(π) end for 13: end procedure tree. The hyperbolic coordinates (represented by a complex number) of a node of the addressing tree are used as the address of the corresponding peer in the overlay. Any node of the tree can attribute the addresses corresponding to its children in the tree. The management of the addressing space is thus distributed because a node can compute the coordinates of its children only by using its own coordinates and applying the algorithm 1. The degree of the tree thus determines how many addresses each peer will be able to give. The degree of the tree is defined at the beginning for all the lifetime of the overlay. The overlay is then built incrementally, with each new peer linking to one or more existing peers and obtaining an address from one of its neighbors. In our overlay, a new peer can connect to any other peer at any time in order to obtain an address. If a peer has no free address left, it replies with the list of its neighbors to enable the new peer to extend the search for obtaining an address. Over time, the peers will leave the overlay until there is no peer left which is the end of the overlay. The algorithm 1 shows how to calculate the addresses that can be given to the children of a peer. The first peer takes the hyperbolic address (0;0) and is the root of the tree. The root can assign q addresses while all other nodes can assign q -1 addresses.

When a new peer has connected to peers already inside the overlay and has obtained an address from one of those peers, it can start sending DHT request packets (PUT and GET) as explained in section III. The routing process is done inside each peer on the path (starting from the sender) by using the greedy algorithm 2 based on the hyperbolic distances between the peers. When a packet is received by a peer, the peer calculates the distance from each of its neighbors to the destination and forwards the packet to its neighbor which is the closest to the destination. If no neighbor is closer than the peer itself, and the peer is not the destination, the packet has reached a local minima and is dropped. This can happen when the addressing tree is broken by a failed peer or link and when no shortcut link exists to bypass this failed peer or link. Of course, this failure is expected to be temporary as the failed peer may restart or a new peer may take its place in Algorithm 2 Routing a packet in the overlay.

d min = argcosh 1 + 2 |m-w| 2 (1-|m| 2 )(1-|w| 2 )

5:

p min = peer return p min 15: end function the meantime. In a real network environment, link and peer failures are expected to happen often. If the addressing tree is broken and can not be restored as described above in a reasonable amount of time, a partial readdressing can occur. To perform the readdressing, the peers located beyond the failed peer or link (i.e., having addresses derived from the failed or unreachable peer's address) will flush their addresses and attempt to obtain new addresses from peers still inside the tree. Some peers may have first to reconnect to other peers in order to restore connectivity.

III. HYPERBOLIC DHT

In this section we explain how our overlay system stores and retrieves the (key, value) pairs that are used by the applications. Our solution is a structured DHT system that uses the distributed addressing and the greedy routing algorithms presented in section II.

A (key, value) pair is called a binding. Figure 1 shows how and where a given binding is stored in the overlay. A binder is any peer that stores these pairs. The depth of a peer in the addressing tree is defined as the number of parent peers to go through for reaching the root of the tree (including the root itself). When the overlay is created, a maximum depth for the potential binders is chosen. This value is defined as the binding tree depth. All the peers that have a depth less or equal to the binding tree depth in the addressing tree may hold bindings and thus be binders.

When a peer wants to store an entry in the DHT, it first creates a key by hashing the key string with the SHA-1 algorithm. It then divides the resulting 160-bit key into r equally sized 160/r-bit subkeys (for redundancy storage). This r factor is chosen arbitrarily and can be set to whatever value depending on the amount of redundancy required. In absence of redundancy, the peer selects the whole key. Then the (sub)key is mapped to an angle by a linear transformation. The angle is given by:

α = 2π × 160/r-bit subkey 111...11 r (2)
The peer then computes a virtual point v on the unit circle by using this angle:

v(x, y) with x = cos(α) y = sin(α) (3)
Next the peer determines the coordinates of the closest binder, given its Euclidean distance, to the computed virtual point above by using the given binding tree depth. In the figure we set the binding tree depth to three to avoid cluttering the figure. It's important to note that this closest binder may not exist in reality if no peer is currently owning this address. The peer then sends a PUT request to this closest peer. This request is routed inside the overlay by using the greedy algorithm of the section II. If the query fails because the binder does not exist or because of node/link failures, it is redirected to the next closest binder which is the father of the computed binder. This process continues until the query reaches an existing binder peer which can be any peer on the path from the computed closest binder to the center peer. Upon reaching an existing binder, the pair is stored in that binder. The query can thus go up the addressing tree to the center peer having the address (0;0) which is the farthest binder. The path from the computed closest binder to the farthest binder is defined as the binding radius.

This process ensures that the pairs are always stored first in the binders closer to the unit circle and last in the binders closer to the disk center. If the addressing tree is imbalanced, many pairs may be stored in peers close to the center thus overloading them. In order to solve this issue any binder peer will be able to set a maximum number of stored pairs and any new pair to store will be rejected and the query redirected as above. Furthermore, to provide redundancy, the peer can repeat the storing process described above for each of the other r -1 subkeys. Thus r different binding radiuses can be used and this will improve the evenly distribution of the pairs. In addition, and still for redundancy purposes, a pair may be stored in more than one peer of the binding radius. A binder could store a pair and still redirect its query for storing it in its other ancestor binders. The number of stored copies of a pair along the binding radius may be an arbitrary value set at the overlay creation. These mechanisms enable our DHT system to cope with an non-uniform growth of the overlay and they ensure that a pair will be stored in a redundant way that will maximize the success rate of its retrieval. The number r of subkeys and the number of copies in a given radius are parameters that can be set at the creation of the overlay. Increasing them leads to a tradeoff between improved reliability and storage space cost in binders.

Our solution has the property of consistent hashing: if one peer fails, only its pairs are lost but the other binders are not impacted and the whole system remains coherent. However, this property does not hold true when a partial readdressing takes place as explained in Section II. In this case, all the pairs stored in the peers having addresses derived from the failed or unreachable peer's address are lost. Hopefully this is not a big issue because, as in many existing systems, pairs will be stored by following a hybrid soft and hard state strategy. Thus a pair will have to be stored by its creator every δt period of time otherwise it will be flushed by the binders that store it. These periodic store messages will ensure that pairs lost by a partial readdressing will be restored after at most δt period of time. A delete message may be sent by the creator to remove the pair before the end of the period. We analyze the influence of the degree of the addressing tree on the query success rate and the query path length in Section V.

IV. SCALABILITY ANALYSIS

We provide in this section a brief complexity analysis of our proposal and compare the results with other existing DHT systems. We first define the four metrics that we use in our analysis. These metrics were defined and used in [START_REF] Lua | A survey and comparison of peer-to-peer overlay network schemes[END_REF] and [START_REF] Malkhi | Viceroy: a scalable and dynamic emulation of the butterfly[END_REF].

1) Hops: this metric counts the average number of peers to go through to reach the destination. 2) Paths: this metric counts the average number of paths that are crossing any given peer. 3) States: this metric counts the number of states that must be stored in a peer for the routing to work, it is typically equal to the number of entries found in the routing table of the peer. 4) Churn messages: this metric counts the average number of messages that are exchanged when a peer joins or leaves the overlay. In our system, the peers in the overlay connect to each others as they wish, thus no strict topology is enforced. Any peer can have as many links as it can with other peers and one link is of course a minimum to connect to the overlay. The only requirement is that the embedded addressing tree which is a spanning tree of the overlay shall remain valid for the greedy routing to work.

Because any overlay will be at (when no redundant links exist) composed of its addressing tree, the distances between any two nodes are expected to be of the order of O(log(n)) hops. If the peers have a large number of redundant links (i.e., links not belonging to the addressing tree), the distances will be much shorter. If the overlay topology takes the form of a scale free network, the distances will be the order of O(log(log(n))) as shown in [START_REF] Cohen | Scale-free networks are ultrasmall[END_REF]. Whatever the topology, the number of paths crossing any one peer (its congestion level) will have an expected probability of at most O(log(n)/n).

When a peer joins the overlay, only its neighbors (i.e., those having setup a link with the new peer) need to update their state information which bears a message cost complexity independent of n. Similarly, when a peer leaves the overlay, only its neighbors need to update their state information also giving a message complexity cost being of the order of O(1). However, if the addressing tree is broken and can not be restored in a reasonable amount of time as explained in section II, a partial readdressing can occur for peers having addresses derived from the failed or unreachable peer's address. In this latter case, which is expected to be very uncommon, the message cost complexity is expected to be of the order of O(n).

Readdressing is needed to provide to the peers the ability of connecting to whatever peers they want. If we force some peers to connect to some specific peers for restoring the addressing tree (as done by Chord, where a peer's IP address determines to which peers it must connect) then the message cost complexity is expected to be of the order of O( 1) for a leaving peer. Thus readdressing must be seen as a costly feature that can be opted out if performance is desired over flexibility.

Because we use a greedy routing, we do not construct and maintain routing tables and the number of states to maintain in any one peer is only equal to the number of its neighbor peers which does not grow with n thus giving a constant complexity cost being of the order of O [START_REF] Stoica | Chord: A scalable peer-to-peer lookup service for internet applications[END_REF].

Table I compares the complexity costs of the four above defined metrics of various DHT systems including our solution. For CAN, d is an integer equal to or greater than 2 and thus 0 < 1/d < 1. The results presented in this table have been gathered by using the data published in [START_REF] Lua | A survey and comparison of peer-to-peer overlay network schemes[END_REF] and [START_REF] Malkhi | Viceroy: a scalable and dynamic emulation of the butterfly[END_REF] as well as from our previous analysis. Because of the rules pertaining to the O notation, log functions with different constant bases are considered equivalent.

(n (1/d) ) O(n (1/d) /n) O(1) O(1) Chord O(log(n)) O(log(n)/n) O(log(n)) O(log 2 (n)) Cloak O(log(n)) O(log(n)/n) O(1) O(1) / O(n) Kademlia O(log(n)) O(log(n)/n) O(log(n)) O(log(n)) Pastry O(log(n)) O(log(n)/n) O(log(n)) O(log(n)) Tapestry O(log(n)) O(log(n)/n) O(log(n)) O(log(n)) Viceroy O(log(n)) O(log(n)/n) O(log(n)) O(log(n))
V. SIMULATIONS

In this section, we present the results of the simulations that we have carried out to assess the practicability of our addressing, routing and binding system based on hyperbolic coordinates. We have used our packet driven discrete event network simulator called nem for obtaining the results concerning the evaluation of the dynamic behavior of Cloak. In order to evaluate our overlay system on a realistic topology, we have used a 4k-node IP Internet map created from real data measurements.In all simulations, the first peer creating the overlay is always a randomly picked node of the map. We have considered that only some part of the nodes of a map at any given time are acting as overlay peers. The simulator's engine manages a simulation time and each overlay peer starts at a given time for a given duration on a random node of the map. The peer that creates the overlay remains active for all the duration of a simulation. The packets are delivered between the nodes by taking the transmission time of the links into account. Peers bootstrap by contacting the node that holds the peer that created the overlay, search for other peers to which they can connect, obtain an address from one of the peers they are connected to and send data or requests messages. This process models the birth, life and death of the overlay.

The number of new peers is set to 30 per minute with random inter-arrival times set with a probability following an exponential distribution. Each peer has a random lifetime set with a probability following an exponential distribution with λ = 10e -5 which gives a median value of 300 seconds and a 90th percentile value of 1000 seconds. As each dynamic simulation lasts for 1 hour, this distribution of the peers' session lengths produces a lot of churn. The peers create overlay links with other peers by selecting those which are closer in terms of network hops. Finally, we collect measurements every 600 seconds. Each point shown on the following graphs is the average value of 20 runs, and the associated standard deviation values are plotted as error bars.

The frequency of the PUT requests generated by each peer is 1 every 30 seconds. The frequency of the GET requests generated by each peer is 1 every 5 seconds. We do not consider any redundancy parameters for now. Thus a pair is stored on one peer only. As explained in section III, we fix here the binding tree depth to 8.

We observe the influence of the addressing tree degree on the performances of the PUT and the GET requests. More precisely we measure the rate of success as well as the average overlay path length of both PUT and GET requests.

Figure 2 shows the percentage of successful PUT requests over the simulation duration. We assume here that only one copy of a binding is stored in the system. We do not yet study the replication strategies explained in section III of this paper. We can see that given the parameters of the simulation, the rate of success is very high despite the churn.

Figure 3 shows the average path length of the PUT requests in the overlay network over the simulation duration. The number of peers to go through including the destination before storing a binding varies from 6 to 9 depending on the addressing tree degree. This number is decreasing when the degree is increasing with a diminishing return effect that can be seen starting at degree 16. Figure 4 shows the percentage of successful GET requests over the simulation duration. As for the PUT request, we can see that given the parameters of the simulation, the rate of success is very high despite the churn. Figure 5 shows the average path length of the GET requests in the overlay network over the simulation duration. The number of peers to go through to reach the holder of the binding and including the return trip to the sender of the request varies roughly from 9 to 16 depending on the addressing tree degree. A degree of 4 yields a typical path length of 16, a degree of 8 reduces the path length to 12 and degree values above 8 all yield path lengths between 9 and 10. Thus the overlay hop number is decreasing when the degree is increasing with a diminishing return effect that can be seen starting at degree 16, similarly to the PUTrequests overlay path lengths shown in figure 3. We can conclude that, for the shown simulation results, our binding system has good performances as a structured DHT system. The rate of success of both the PUT and GET requests, for an overlay running for one hour with a total of 1800 peers, is encouraging. The average path lengths of the requests are also acceptable and show typical values for these kind of systems.

To validate the analysis shown in Section IV, we have also carried out simulations with the PeerSim simulator to compare our solution with Chord, Kademlia and Pastry regarding the average number of hops per request. We have used a degree of 24 for Cloak. We have tested various networks sizes ranging from 100 to 12800 by powers of 2 (hence the log scaled xaxis). We have carried out 50 runs per simulation although this seems not enough when looking at the Chord and Kademlia plots. Figure 6 shows that although the Cloak results are a bit above the other systems, they confirm the same expected O(log(n)) hops per request complexity cost.

VI. RELATED WORK

Many existing DHTs been extensively described and we refer the reader to the work of Lua et al. [START_REF] Lua | A survey and comparison of peer-to-peer overlay network schemes[END_REF] for a detailed state of the art of these solutions. Our proposal borrows some elements from these well known DHTs. Our mapping mechanism for placing keys on the unit circle is similar to the one defined by Chord [START_REF] Stoica | Chord: A scalable peer-to-peer lookup service for internet applications[END_REF]. However, unlike Chord we do not place the peers themselves on this circle but inside the unit disk by using complex coordinates. Similarly to CAN [START_REF] Ratnasamy | A scalable content-addressable network[END_REF], we use a multi-dimensional coordinate space, but instead of using a d-dimensional cartesian multi-torus, we use the 2-dimensional hyperbolic plane H 2 . Our greedy routing scheme is based on a properly defined distance metric as done in Kademlia [START_REF] Maymounkov | Kademlia: A peer-to-peer information system based on the xor metric[END_REF]. But unlike Kademlia which is based on the XOR metric, we use the hyperbolic distance defined for the Poincaré disk model of the hyperbolic plane. Another advantage of our greedy routing algorithm as opposed to prefix routing algorithms such as those developed in Pastry [START_REF] Rowstron | Pastry: Scalable, decentralized object location and routing for large-scale peer-to-peer systems[END_REF] and Tapestry [START_REF] Zhao | Tapestry: A resilient global-scale overlay for service deployment[END_REF], is that it does not rely on routing tables. Only the coordinates of the neighbors of a peer are needed to forward a message. This is highly scalable as the peers do not need to build and maintain routing tables. The idea of using the hyperbolic plane as a virtual address space comes from the work of Kleinberg in [START_REF] Kleinberg | Geographic routing hyperbolic space[END_REF]. We have extended his work by allowing the network to be dynamic and extensible. Indeed, as we setup an overlay network, we are able to fix the degree of the addressing tree to an arbitrary value and as such to avoid the discovery of the highest degree node. This property enables our algorithms to rely only on local information for distributing addresses and routing messages as shown in section II. Also we have defined a mapping function which is novel, whereas Kleinberg suggested using CAN for implementing a DHT based on hyperbolic coordinates. Our binding radius approach presented in section III can cope with the growth and shrink of the overlay automatically thus optimizing the storage of the keys in a dynamically evolving network. More details concerning the scalability and efficiency of our overlay solution based on hyperbolic addressing and routing can be found in our previous work [START_REF] Cassagnes | Overlay addressing and routing system based on hyperbolic geometry[END_REF].

VII. CONCLUSION

Providing storage and lookup services to networked applications by using a DHT system is always a challenging task. Because of its tessellation properties, the hyperbolic plane through the use of the Poincaré disk model is well suited for attributing virtual coordinates to the participating nodes of an overlay network. We have shown that given an appropriate mapping function, it is easy to setup and maintain a consistent DHT structure upon such an overlay. We have thus proposed a DHT system called Cloak that provides to all its members a scalable and reliable binding infrastructure. Our analysis has shown that our proposal is scalable with performances similar to other existing DHTs. Our simulation results have demonstrated that the success rate of the PUT and GET requests always remains above 95% in presence of churn. They have also shown that the number of hops per request is very similar to other existing DHTs. Given the fact that overlay nodes can connect to each other with a high degree of freedom, we are confident that our DHT can be an interesting alternative to current existing DHTs. Our future work will consist in implementing our hyperbolic DHT system in a library and comparing its performances to other existing implementations such as Kademlia and Pastry.

1 :

 1 function GETNEXTHOP(peer, packet)

6 :

 6 for all neighbor ∈ peer.N eighbors do

1 .

 1 Hyperbolic DHT system.

Fig. 2 .

 2 Fig. 2. Percentage of successful PUT requests.

Fig. 3 .

 3 Fig. 3. Average path length of the PUT requests in the overlay network.

Fig. 4 .

 4 Fig. 4. Percentage of successful GET requests.

Fig. 5 .

 5 Fig. 5. Average path length of the GET requests in the overlay network.

Fig. 6 .

 6 Fig. 6. Average number of hops for various DHT systems.


Daouda Ahmat

Damien Magoni
email: magoni@labri.fr

MUSeS: Mobile User Secured Session

Mobility and security are very important services for both current and future network infrastructures. However, the integration of mobility in traditional virtual private networks is difficult due to the costs of reestablishing broken secure tunnels and restarting broken application connections. In order to address this issue, we propose a new communication system called Mobile User Secured Session. Based upon a peer-to-peer overlay network, it provides security services to the application layer connections of mobile users. The secure and resilient sessions allow user connections to survive network failures as opposed to regular transport layer secured connections. We have implemented a prototype and have assessed its proper functioning by running experimentations upon a simple virtual dynamic network.

I. INTRODUCTION

Mobile equipments and wireless networks have progressively provided a high connectivity for user connections. However, such connectivity often comes at the expense of vulnerabilities to attacks such as eavesdropping. Malicious users can infiltrate untrusted dynamic networks and attack communication between legitimate users. Virtual Private Networks (VPNs) are a technology which offers a high security to the traffic [START_REF] Berger | Analysis of current VPN technologies[END_REF]. Traditionally, these systems allow the user to securely and remotely communicate with its Intranet through insecure networks such as the Internet. Security services provided by these infrastructures are very robust against malicious users' attacks. However, traditional VPNs fail to support the mobility of users. Indeed, network failures automatically break-up secure tunnels and involve a subsequent negotiation that is then necessary to reestablish broken tunnels. This negotiation requires expensive computational operations in order to restore tunnels as well as transport and application layers' connections. This phase of negotiation causes not only significant latency but also presents risks of Man-In-The-Middle attacks. Traditional VPNs can not therefore effectively operate in dynamic environments.

In this paper, we propose a new mobile VPN system called Mobile User Secured Session (MUSeS). This system is designed to support both the mobility and the traffic security of the user. MUSeS allows user connections to survive disruptions caused by network failures or location changes.In addition, our infrastructure has the ability to hide these disruptions from the user. In this paper, our main contributions are structured as follows:

• We first describe the design principles and architecture of our system (Section II).

• We then experiment our secure session resilience mechanism in a virtualized dynamic environment (Section III). • We finally provide a background summary of prior and related work (Section IV).

II. SYSTEM DESIGN

A. Overview

As shown in Figure 1, MUSeS is a communication system directly used by the applications. MUSeS is using another communication system called CLOAK which enables the creation and management of a P2P overlay network above any IP network [START_REF] Tiendrebeogo | Virtual Internet Connections Over Dynamic Peer-to-Peer Overlay Networks[END_REF]. MUSeS is designed to provide traffic security and session continuity. Applications produce data and send it to the MUSeS middleware. Data is then sliced in packets that are encrypted and authenticated. Unlike IPsec or TLS which rely on IP addresses to define the identity of the communication entities, MUSeS relies on permanent device identifiers called names provided and managed by CLOAK. The MUSeS system has the ability to support several simultaneous applications. In addition, any application setting up a MUSeS session is able to survive to network interruptions of any duration. It can keep a user session active after a connection disruption and can resume an interrupted session when the failed connection is reestablished. Session resumption is performed without any session key renegotiation.

B. CLOAK Overlay

CLOAK is an architecture for building P2P overlay networks which are autonomous and dynamic. A network node can join any peer already inside the overlay usually by setting up a transport layer connection such as TCP with this peer.

The new peer is then offered an address which is unique and dependent on its location in the overlay. These addresses are used by a greedy routing algorithm for forwarding the data inside the overlay. In order to cope with network dynamics, CLOAK provides a distributed algorithm for maintaining the consistency of the assignment of the addresses to preserve the greedy routing property. Because an address depend on a peer's location, it changes when the peer disconnects from its neighbors and reconnects to new neighbors. To ease communication between peers, CLOAK assigns to each peer a name which remains permanent during the lifetime of the overlay. In order to be autonomous, CLOAK provides a DHT for mapping the names of the peers to their addresses. These names are used by MUSeS to setup a secure connection between two peers.

CLOAK was originally presented in our paper [START_REF] Cassagnes | An overlay architecture for achieving total flexibility in internet communications[END_REF] which contained an extensive amount of background and related work as well as some preliminary simulation results upon static networks concerning path length. Improving upon this foundation, our paper [START_REF] Tiendrebeogo | Virtual Internet Connections Over Dynamic Peer-to-Peer Overlay Networks[END_REF] presented the protocols and modules of the architecture with greater details and reported simulation results upon dynamic networks concerning routing success ratio, path length and stretch, as well as DHT performances. The addressing and routing system based on hyperbolic geometry which is used by CLOAK was presented in our paper [START_REF] Cassagnes | Overlay Addressing and Routing System Based on Hyperbolic Geometry[END_REF]. Both the distributed addressing algorithm and the greedy routing algorithm are detailed in this previous paper and we have not included them here for the sake of brevity. The DHT scheme defined by CLOAK over this hyperbolic system is fully explained in our paper [START_REF] Tiendrebeogo | Reliable and Scalable Distributed Hash Tables Harnessing Hyperbolic Coordinates[END_REF].

The Figure 2 shows how a packet is forwarded between the source and the destination. When a secure MUSeS node A generates a packet to send to a distant node B, it locally forwards the packet to the associated underlying CLOAK node A' via a loopback TCP connection. Next, the underlying node A' routes the packet to the destination through the P2P overlay network consisting in chained TCP connections. The CLOAK node B', associated to the final destination MUSeS node B, intercepts the packet and locally forwards it to B. The P2P overlay network ensures therefore the proper routing of MUSeS secured packets over the network. C. Architecture

CLOAK P2P overlay

The MUSeS system is based on three main components:

• The Session Security Module (SSM) manages security services such as confidentiality, integrity and protection against replay attacks. • The Session Reliability Module (SRM) is designed to provide fault-tolerant user sessions. In other words, SRM offers user session continuity service that survives despite connection disruptions caused by lower layers. • The Local Connection Manager (LCM) handles multiple local TCP connections in order to support several simultaneous user applications. 1) Session Security Module (SSM): The MUSeS security module consists mainly in encrypting and decrypting traffic payload as well as checking the integrity of the persistent fields (sequence number, source and destination identifiers, source and destination ports, ...) of each packet. All send/receive operations between two users are performed through a secure end-to-end tunnel. The SSM component protects the user's traffic against eavesdropping, modification attacks and replay attacks. The goal of these protections is to prevent malicious users from attacking legitimate users' traffic.

Precisely, when Alice and Bob communicate, the data exchanged by the two correspondents is encrypted and authenticated. In other words, when Alice wants to send data to Bob, for each packet that she generates, Alice encrypts the payload and authenticates the encrypted payload and persistent fields (SrcID, DstID, SessID, SeqNBR, ConTYPE, ...) of the packet header. The authentication consists in computing a digest on both the invariant fields and the encrypted payload. The Integrity Check Value (ICV) thus obtained is added to this packet.Before decrypting a received packet, Bob computes an ICV and compares it with the ICV fixed on this packet by Alice in order to check both authenticity and integrity. If the check is successful, then Bob decrypts the payload of the packet. Otherwise, the packet is assumed to be corrupted and it is automatically destroyed. If the decryption process fails, the packet is also destroyed.

The Routing Header (RH) used by the CLOAK overlay is neither authenticated nor encrypted by MUSeS. Thus, each intermediary overlay peer can update these values so as to route packets towards the destination user. In order to avoid replay attacks, SSM separately identifies each packet by a sequence number (SeqNBR) and a session identifier (SessID). The combination SeqNBR • SessID is unique to a MUSeS connection. These values are authenticated because they belong to the persistent fields. SeqNBR and SessID are therefore free of modification attacks.

2) Session Reliability Module (SRM): The Session Reliability Module or SRM is a MUSeS module which manages the session continuity mechanism. SRM is able to detect network failures and to suspend a communication for a long time. It can keep interrupted sessions active and can reestablish them subsequently. In addition, SRM permits also to hide disruptions caused by lower layers to the application layer.

Therefore, SRM has the ability to make the failures occurred at lower layers transparent to the users. a) Interruption Detection: When a connection fails, SRM has the ability to detect it. The destination unreachability detection is made possible by an acknowledgment mechanism that is based on the exchange of request-reply messages. When there is a packet loss, detected by a lack of acknowledgment or a waiting timeout, the communication will be temporarily suspended.

Each peer concerned by an interrupted session attempts to reestablish the connection with the corresponding peer. Its sends Re-Hello packets at regular intervals of time to attempt to restart the disrupted session as shown in Figure 3. In order to check remote peer connectivity, Re-Hello messages contain, among other fields, the sequence number of the last packet correctly received or sent. The first peer that receives Re-Hello request can reply to this message. When a peer replies to a Re-Hello message, disrupted session is therefore resumed. c) Acknowledgment Scheme: Based on a cumulative acknowledgment scheme such as in the TCP protocol, the MUSeS system sends one reply message when n packets have been sent in order to optimize network bandwidth. When the sender node sends n successive packets but it does not receive an acknowledgment message from the receiver node before the expiration of timeout, the corresponding node assumes that the underlying CLOAK connection has failed and pauses the traffic sending for the time necessary. The established MUSeS session is kept active by the two correspondents until the disrupted CLOAK path is restored. The acknowledgement scheme is presented in Algorithm 1.

Algorithm 1 Acknowledgement Scheme. Require: M ax_i ≥ 0 ∧ M ax_j ≥ 0 repeat i ⇐ i + 1 j ⇐ 1 pkt = packet.next_packet() send_packet(pkt) if i = M ax_i or pkt.flag_last = true then r ⇐ recv_ack_packet() while r ∈ {timeout, ¬ok} do if j = M ax_j then session_close() exit() else pause() r ⇐ recv_ack_packet() j ⇐ j + 1 end if end while i ⇐ 0 end if until pkt.flag_last = true d)
Secure Mobility: In our model, the concept of secure mobility is a way to allow mobile users to keep an established secure session active when the underlying system connection fails until a subsequent new connection is started. In other words, when a user changes its location as shown in Figure 4 or when its connections are disrupted by network failures, the user session survives as long as necessary to resume the communication. This ability prevents MUSeS connections from breaking when the underlying topology changes.Therefore, the session reestablishment is free from renegotiating security parameters. To reestablish an interrupted communication, the corresponding peers just need to exchange some session resumption messages shown in Figure 3 the interrupted session at the point where the session was 3) Local Connection Manager (LCM): The MUSeS system is able to simultaneously support several user applications. The MUSeS system and the user applications communicate through local TCP sockets. Local TCP connections are managed by the Local Connection Manager (LCM) as shown in Figure 5. Each user application is separately identified by its source port. When data is received, the LCM module locally forwards the data to the expected user application. The LCM builds a hash table that associates each socket descriptor (value) with a socket source port number (key). Socket source port numbers are generated in a unique way by the OS. Source port numbers contained in the hash table allow the LCM to identify the local TCP socket descriptors corresponding to the proper destination applications. When the SRM detects a connection disruption or fails to reach the remote peer, it automatically notifies the LCM. Then, the LCM suspends data reception from user applications until the connection reestablishment. The local socket is never closed by MUSeS (and it normally never fails) unless the user wants to close it explicitly.

D. Security Analysis

Based on the use of standard cryptographic algorithms, our system protects user communications from common traffic attacks. The authentication of user applications is done through public key cryptography where the CLOAK DHT is used as a PKI. Finally, communications between the MUSeS middleware and the local applications on a given machine are not secured. These unprotected local communications may create security issues. For instance, a local communication channel may be intercepted by a malicious user in order to spy a connection between two MUSeS users. We assume for the moment that the risks of attacks against local connections are avoided by the proper security of the machine itself.

E. Implementation

MUSeS is implemented as a middleware inserted between user applications and our CLOAK P2P overlay middleware. Currently, applications must use the MUSeS API to setup secure and mobile sessions and thus must be recompiled. Devices running these applications must run the CLOAK middleware and belong to a CLOAK overlay. MUSeS is implemented in the C language and consists in roughly 3000 lines of code. The code can be viewed at [START_REF] Ahmat | [END_REF]. It is only a preliminary prototype implementation. The OpenSSL library is used by our implementation in order to provide security services such as protection against eavesdropping and protection against modification attacks. Traffic integrity is ensured by the HMAC-SHA1 cryptographic function which seals each traffic packet which implies that the two correspondents share a secret key. Traffic confidentiality is ensured by the AES algorithm which is used to encrypt the traffic payload. We currently assume that the needed secret keys have been previously exchanged securely by using public/private key signatures and encryption. For testing and evaluating MUSeS, we have written a very basic client-server application that is able to send a data file over MUSeS. Furthermore, because CLOAK has only be implemented inside simulators so far, there is no usable CLOAK prototype and thus a static form of routing has been implemented as a helper in the MUSeS prototype in order to emulate the CLOAK layer.

III. EXPERIMENTATION

An experimentation has been carried out with the above implementation in a dynamic environment composed of one mobile node. The emulation of the dynamic environment is done with our emulator nemu [START_REF] Autefage | Network emulator: a network virtualization testbed for overlay experimentations[END_REF], a dynamic network emulator using QEMU. A mobile node inside this environment has the ability to leave one network (one virtual router) in order to join another one (another virtual router). This event causes a network failure during the move until a possible subsequent reconnection. This disruption is transparent for the application and it does not prevent the MUSeS system from continuing to run despite the fact that the mobile node is disconnected for a moment. Technically, in our experimentation shown in Figure 6, the node's mobility consists in causing an artificial failure on a virtual network interface. We disconnect a virtual wire from a virtual switch and reconnect it on another virtual switch. The MUSeS system hides this network change not only to the user's application but also to the remote corresponding node. The Figure 6 Figure 7 shows the evolution of the throughput between the two corresponding applications over time. The network interruption happens at 59 seconds after the start of the experiment and the throughput instantly drops to zero. The connectivity is reestablished at the network and CLOAK level at 73 seconds and 82 hundredth. Because the CLOAK layer is currently just an emulation, this time interval may be greater when using the real implementation. After that, control messages are exchanged at the MUSeS level in order to resume the data transfer which finally happens at 76 seconds and 81 hundredth. Thus it takes 3 seconds to resume the transfer at the MUSeS level.

IV. RELATED WORK

Mobile VPN systems based on both IPsec [START_REF] Kent | Security Architecture for the Internet Protocol[END_REF] and Mobile IP [START_REF] Perkins | IP Mobility Support for IPv4[END_REF] have been proposed in [START_REF] Ruppelt | Building ALL-IP Based Virtual Private Networks in Mobile Environment[END_REF], in order to attempt to overcome traditional VPN inherent mobility drawbacks. Nevertheless, this combination causes inconsistency problems [START_REF] Adrangi | Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways[END_REF] between IPsec and Mobile IP. In order to overcome these problems, another model has been proposed which is based on the use of two HAs (internal HA and external HA) and two FAs (internal FA and external FA) [START_REF] Vaarala | Mobile IPv4 Traversal across IPsec-Based VPN Gateways[END_REF]. However, this model imposes the use of three imbricated tunnels({x-MIP{GW{i-MIP{original packet}}}}). In addition, an IPsec-based mobile VPN requires n tunnels (n security layers) when there are n IPsec hops between the source and destination entities. Therefore, VPN systems based on this model suffer network overhead.

Based on a topology organized in communities, P2P mobile VPN systems have also been proposed such as ELA [START_REF] Aoyagi | ELA: A Fully Distributed VPN System over Peer-to-Peer Network[END_REF] or N2N [START_REF] Deri | N2N: A Layer Two Peer-to-Peer VPN[END_REF]. In opposition to most dynamic VPN systems, these systems have the advantage to be scalable and to have ability to communicate across NAT. Decentralized P2P VPN infrastructures are a flexible and self-organized way that allow users to create through untrusted network their own secure network. N2N and ELA topologies are very similar despite the fact that N2N is based on layer two whereas ELA is based on layer three.

SIP-based mobile VPN systems have also been proposed in the literature in [START_REF] Huang | SIP-based mobile VPN for real-time applications[END_REF] and [START_REF] Chen | Secure Network Mobility for Real-Time Applications[END_REF]. However, the centralized model (client/server architecture) of the session continuity protocol (SIP) implies scalability issues. In addition, proposed SIPbased mobile VPN are only adapted to real-time applications.

FAST VPN [START_REF] Zúquete | Fast VPN Mobility Across Wi-Fi Hotspots[END_REF] is a mobile VPN infrastructure designed for domestic networks. This VPN system creates a virtual Internet Service Provider (vISP) inside a private network. This system allows to establish a secure VPN between users and a vISP. This technical concept capitalizes not only on the high security and privacy given by the VPN but also on the mobility provided by the flexibility of wireless networks. However, FAST VPN is not scalable and provides a restricted service to a private network: it permits only to secure Internet access through an untrusted private network.

The TLS protocol provides a way to resume a TLS session without requiring session-specific state at the TLS server [START_REF] Salowey | Transport Layer Security (TLS) Session Resumption without Server-Side State[END_REF]. In contrast to this technique that stops a session and restarts it later, our system has the ability to always maintain an established session active despite connection failures or network disruptions. MUSeS also makes connection disruptions transparent to the application as opposed to the TLS protocol.

Mobile VPN architectures based on SSH and TLS protocols are been proposed in [START_REF] Schönwälder | Session Resumption for the Secure Shell Protocol[END_REF] and [START_REF] Koponen | Resilient Connections for SSH and TLS[END_REF]. These extensions of SSH and TLS protocol allow session to survive network failures. Designed to support resilient connections, mobile VPN presented in [START_REF] Koponen | Resilient Connections for SSH and TLS[END_REF] can span several sequential TCP connections in order to resist connection failure and IP address change. Mobile VPN presented in [START_REF] Schönwälder | Session Resumption for the Secure Shell Protocol[END_REF] introduces a session resumption concept in order so as to resume sessions without having to renegotiate new session keys.

In opposition to aforesaid schemes, another interesting mobile VPN architecture has been designed [START_REF] Minglei | Mobile VPN Scheme Based on SOCKS V5[END_REF]. Based on SOCKSv5 proxy, this mobile VPN model allows to authenticate clients and to build a secure SSL tunnel between users and a SSL gateway that protects their Intranet. However, this system is not scalable and when the SSL gateway is compromised then the entire network will be affected.

There are many other solutions that provide mobility services such as session-based mobility [START_REF] Snoeren | A Session-Based Approach to Internet Mobility[END_REF], the persistent connection model [START_REF] Zhang | A "Persistent Connection" Model for Mobile and Distributed Systems[END_REF] and session layer mobility (SLM) [START_REF] Landfeldt | SLM, a framework for session layer mobility management[END_REF]. Although these systems do not offer security services, they allow session continuity despite connection failures.

V. CONCLUSION AND FUTURE WORK

In this paper, we have presented a new security and mobility system called MUSeS based on a P2P overlay system called CLOAK. MUSeS provides secure and resilient sessions to the applications run by mobile users. In other words, user sessions can be paused for any period of time and can be restarted without the cost of renegotiating security parameters. In addition, the MUSeS system makes lower layers disruptions transparent to user applications and to remote corresponding peers. MUSeS has also the ability to handle multiple local TCP connections in order to support simultaneously several user applications. We have designed and implemented a prototype of our system and we have assessed it in an emulated dynamic network environment.

Our future work will consist in completing and improving the current implementation as well as integrating a public key management scheme suitable for dynamic networks to provide the users with a means to exchange secret keys in-band. We plan to use certificate-less public key management techniques to solve traditional key management issues.

Fig. 1 .

 1 Fig. 1. Design overview.

Fig. 2 .

 2 Fig. 2. Routing through the P2P overlay network.

Fig. 3 .

 3 Fig. 3. Messages exchanged in the handshake and resumption phases.

  b) Session Identifier: When a mobile MUSeS entity wishes to communicate with a remote corresponding node, these two peers compute together, in the handshake phase, a unique value in order to singly identify each session following the same principle as with a socket connection. When Alice contacts Bob to communicate (handshake phase), Alice generates a partial session ID (pSessID-a) and sends it to Bob as shown in Figure3. After receiving pSessIDa, Bob generates also a partial session ID (pSessID-b) and sends it to Alice. Each corresponding determines the final session ID (SessID) by concatenating the partial session IDs: SessID = pSessID-a • pSessID-b. To close this phase, Alice sends a Finished message to Bob, and he sends the same message to Alice. The communication, identified by a SessID, can be therefore started between the two actors. Precisely, a partial session ID (pSessID) is essentially computed by a combination between a source port number (psN) and a peer ID (pID): pSessID = psN • pID.

Fig. 4 .

 4 Fig. 4. User mobility with ongoing secure session.

Fig. 5 .

 5 Fig. 5. Interaction between user applications and MUSeS.

Fig. 6 .

 6 Fig. 6. Location changing scenario

Fig. 7 .

 7 Fig. 7. Reconnection throughput vs time.