Versatile Routing and Self-Certifying Features Support for Secure Mobility in eXpressive Internet Architecture

Hongwei Meng, Zhong Chen , Jianbin Hu , Chuck Song , Cong Tang

1 School of Electronics Engineering and Computer Science, Peking University, Beijing 100871, China

2 Key Laboratory of High Confidence Software Technologies, Ministry of Education, Beijing 100871,China

3 China Academy of Electronics and Information Technology, Beijing 100041, China

4 Department of Computer Science, Carnegie Mellon University, Pittsburgh 15213, USA

* The corresponding author, Email: menghw@pku.edu.cn

I. INTRODUCTION

Internet is experiencing a significant shift from PC-based computing to cloud and mobile computing, while mobility has become one of the essential requirements [1]. On the one hand, Internet services are increasingly provided by cloud computing systems. Service hosting in virtual machines (intra-datacenter or across multiple datacenters) might migrate dynamically for the reason of load balancing,fault-tolerance, power constraints, and disaster recovery [2, 3]. Reasons such as moving computation more closely to data sources, or more closely to customers for reducing the response time, motivate the service migrating as well. On the other hand, at the other end of the service chain, in contrast to service hosting in cloud datacenter, the rapidly growing volume of mobile devices is another trend. Mobile and wearable devices already outnumber the fixed hosts [31], and the traffic from wireless devices will exceed that from wired hosts [4, 30].

For either migrating services or mobile devices, maintaining the on-going sessions between mobile node (MN) and its correspondent nodes (CNs) can help improve user experience. It has been a long standing challenge of mobility support in current Internet architecture. IP network couples the host identity and network locator in one IP address, which obviously is the shortcoming that may not support mobility well [5]. Furthermore, the solutions to security problems plaguing today’s Internet,such as patch-on or afterthoughts, might make the situation even worse.

This paper focuses on secure mobility support in XIA architecture context. The authors proposed a secure procedure for mobility support,including access authentication, BU to RA authentication and route optimization authentication, to overcome the potential threats.

Integrating the mobility and security becomes a key feature of future Internet, which demands a rework on the Internet that is designed about 40 years ago with no vast mobility and security support in architectural consideration. Our work is driven by the desire for both mobility and security as architectural underpinnings, to design a secure mobility support scheme in XIA [6]. XIA is a novel clean-slate architecture based on new designs expected to meet the emerging demands for security, mobility, content distribution and evolvement challenges of current Internet.XIA was founded by NSF FIA and FIA nextphase programs in 2010 and 2014 respectively [7]. In XIA, new narrow waist can be introduced to assure the network evolvability.Hashing of the public keys as the self-certifying identities achieves end-to-end authentication. Directed Acyclic Graphs (DAGs) are used as the routing addresses to improve the routing scalability and content distribution efficiency. Up to now, how to support mobility in a secure manner in XIA is not straightforward. It is productive for architecture insights via studying the ability of secure mobility in XIA. In this paper, we explore these novel features and propose a solution of secure mobility in XIA.

The rest of this paper is organized as follows. Section II introduces the related works and gives an overview of XIA. We introduce our mobility support mechanism in Section III.Section IV analyzes the potential threats and explains how the secure mobility is achieved utilizing the self-certifying features. Section V shows the experiments results of virtual machine migration and host mobility. Section VI gives some discussions about efficiency and security of the proposed mechanism. Section VII comes to our conclusion.

II. BACKGROUND AND RELATED WORKS

In this section, we first introduce the related works of mobility support in network layer.Then we give an overview of XIA as well as its novel features.

2.1 Mobility support in network layer

Mobility means that a mobile node moves from one location in one network to another,or its network attachment point changes [8]. In IP network, for example, this causes a change in the mobile node’s IP address. The change of IP address usually raises two issues. Firstly,the mobile node is no longer reachable at its old address. Secondly, existing connections,such as TCP connections between the mobile node and its peers become invalid. Mobility support in network layer aims to solve both problems: all transport-layer and higher-layer connections between the mobile node and its correspondents should survive the address change, and the mobile node should be reachable as long as connecting to the Internet in anywhere else.

Mobile IPv4 and Mobile IPv6 are mobility support protocols on top of the existing IP infrastructure [9, 10]. In Mobile IPv4/v6,a permanent address called home address(HoA) and a home agent (HA) are assigned to the mobile node. When roaming to another network, mobile node tells HA its current location, called the care-of-address (CoA), by sending a binding update (BU) message. Then,HA intercepts the traffic destined to HoA sent by correspondents and forwards them to CoA over an IP-in-IP tunnel. To solve the problem of triangle routing, a mechanism called route optimization (RO) is defined in Mobile IPv6.In RO, when the mobile changes its current address, a binding update message is sent to its correspondents to notify the new location.This enables more efficient routing of data to and from mobile nodes.

Unauthenticated or malicious binding update messages would open up the potential for additional attacks [11, 12], such as spoofing and denial-of-service. Mobile IPv6 uses an authentication mechanism called return routability (RR) to protect against these vulnerabilities. However, it is generally considered that authentication via routing property is a weak mechanism. Because the RR mechanism that is only to verify the MN reachability in both its home address and care-of address without being a security feature. Other works have attempted to solve the security issues in RR, using the Cryptographically Generated Address(CGA) based authentication, such as the CAM[13, 14], CAM-DM [15], CGA-OMIPv6 [16],and ERO [17]. But the drawbacks are that the CGA based authentication needs extra information transmission to verify the ownership of a given address, such as public keys and auxiliary parameters. It also needs the help of home agent taking part into the proof procedure,which is considered inefficient.

In order to conquer the shortcomings of IP network, some novel network protocols or architectures splitting the ID and locator have been found more effective in mobility support,such as Host Identity Protocol (HIP) [18],Locator/Identifier Separation Protocol (LISP)[19], Identifier Locator Network Protocol(ILNP) [20] and MobilityFirst [21,22]. HIP integrates mobility and security into one protocol by introducing a cryptographic tag in a new layer between network and transport layer. The tags take care of connections between two end-points despite of IP address changes.HIP requires operation in conjunction with IPsec. The HIP communication parties require a four-packet handshake to establish the pair of security association between them, and all packets traffic using ESP. The rendezvous server was introduced in HIP to handle the double jump case. However, the rendezvous server only relays initial UPDATE packets.It does not eliminate the need for end-to-end security association updates when the IP address changes [23]. LISP and ILNP rely on a mapping system to dynamically binding the ID and current locator of the mobile node. To achieve the reachability of the mobile node,all the mapping cache of the routers connecting with CN must be updated. MobilityFirst is another future Internet architecture founded by NSF FIA project. In MobilityFirst, a global name resolution service (GNRS) is proposed to dynamically update the mapping of GUID(Global Unique Identifier) and NA (Network Address). But we consider that one mobile event triggering the global mapping table update of the whole network is not scalable.

2.2 XIA overview

Different from today’s host-centric IP network, XIA is a novel future Internet architecture with native support for network evolvement by enabling the introduction of new type of principal [24-26]. Principal can be defined as a type of narrow waists, such as network domains, hosts, services and contents. Each principle type is identified with XIA identifier(XID), including network ID (NID), host ID(HID), service ID (SID) and content ID (CID).NID, HID and SID are the hash of the public key of subnet, host and service respectively,while CID is the hash of content. NID specifies a network address that supports global addressing, and determines the subnet that the device is connected. HID is used to identify the different devices within the same subnet and supports unicast host-based communication. SID supports communication with service instance and achieves anycast forwarding,and CID allows to retrieve content from anywhere in the network. Combining these XIDs,the routable address in XIA can be represented with Directed Acyclic Graph (DAG).

Routing is realized via DAGs in XIA.DAGs are highly flexible and allow packets to express intent as well as scoping to realize forwarding. The simplest DAG of a host has only a dummy source Ÿ and the intent as the sink, e.g., a HID in Figure 1(a). The dummy source represents the conceptual source with no specific meaning. In order to improve the routing scalability in the public Internet,DAG can also be used to implement scoping,as shown in Figure 1(b). Routers inspect the network address NID until the packets reach the destination subnet. Upon reaching the destination network identified with NID, routers forward packets using only HID. Figure 1(c)is a DAG with fallback path, shown as a dotted line, which pointing to an extra node N. If the direct HID is unreachable, the fallback is used by the router to forward packets to node N. The direct path (solid edge) in DAGs has the higher routing priority than fallback path(dotted ones).

III. MOBILITY SUPPORT IN XIA

In this section, we highlight the main ideas behind our design, and then we take a walkthrough over a simple mobility scenario to show how it works.

3.1 Mobility requirements

Fig. 1 DAGs example of a host in XIA

Fig. 2 A simple mobility scenario

Mobility in XIA implies a change of NID in mobile node’s DAG. Figure 2 demonstrates a simple scenario of mobility, as well as the DAGs of mobile node before and after moving. In this case, MN locates in NID1originally, and its DAG is NID1→HID. When roaming to another network NID2, MN’s DAG becomes NID2→HID. Obviously, after moving to another network, the mobile mode is no longer reachable at its old location and the existing connections between MN and its correspondents might be lost.

In order to continue communicating with its peers, two actions can be done: The mobile node somehow makes itself reachable via the original identifier. Or alternatively, the mobile node notifies its new DAG to its peers. Here are the general requirements of mobility management in XIA, which is similarly to IP mobility [8].

– Location management.If a mobile node offers/accepts services to/from other nodes,it must be able to be located by its peers as it changes its location.

– Transparency.Mobility management mechanisms should offer some level of transparency to higher-layer protocols and applications. For example, the act of readdressing should not normally cause a TCP connection to break.

– Security.Mobility management mechanisms should not introduce additional security vulnerabilities into the network.

– Performance.Mobility management mechanisms allow correspondent nodes to send subsequent packets directly to MN’s current location, in order to eliminate inefficient triangle routing.

3.2 Main idea

To address the mobility management requirements mentioned above, the main ideas of our solution are listed below.

1)Introduce a network entity providing mobility management service for mobile node,named as Rendezvous Agent (RA). RA maintains the current location of mobile nodes,and is responsible for redirecting packets to mobile nodes. RA is required for each mobile node and allows mobile nodes to update the binding, such as (HID, NID) in RA’s binding cache entry (BCE), as soon as the mobile node moves to a new location.

2)Add a fallback path in MN’s DAG and set the fallback pointing to RA by default.Fallback is optional in XIA, which allows routers to specify alternative actions if it cannot operate upon the primary intent via the direct path. The fallback here offers an extra route to the mobile node that has moved when normal routing has not yet caught up with the movement. The fallback pointing to RA ensures the reachability of packets destined to mobile nodes. This allows the peers to reach a mobile node that has moved to a different network after a mobile node registers itself in RA. The typically DAG of a mobile node in the simple mobility scenario is shown in Figure 3.

There are two other features of XIA which match the mobility requirements: ID/location decoupling and self-certifying identities.

3)Separating the host identity (HID) and network locator (NID) is central to mobility management approach. On one hand, it is conducive for the location management function to implement the late binding to track mobile node’s location. On the other hand, the transport protocols in XIA on top of the network layer are bound to the unchanged source and destination HIDs, thereby allowing the underlying NID part of the DAG to change. When receiving packets sent from MN’s new place,the correspondent node views as the same connection with before, this allows TCP endpoint to move transparently.

4)HID is cryptographically generated,which is the hash of owner’s public key. Such feature allows the mobile node to provide a proof of ownership of its identity and also to sign important messages with the owner’s private key. A mobile node may securely notify the new DAG to its correspondent node while moving from one place to another, so that subsequent packets will be route-optimized and no longer be routed through the mobile node’s rendezvous agent. This makes the spoofing or man-in-the-middle attack against the mobile node much harder.

Fig. 3 MN’s DAG supports for mobility

3.3 General principle for mobility management

The general principle of mobility support in XIA is shown in Figure 4. Here is a more detailed, step-by-step description.

1)When MN joins a network for the first time, MN registers its DAG to the rendezvous agent, as well as the name service. If succeeds,the rendezvous agent inserts and maintains a binding cache entry (BCE) for MN, and the name service presents the registered DAG to any clients that wish to connect with the mobile node. Note that the information of RA can be acquired from the XHCP beacon broadcast message belongs to the attached network. At this point, if a CN tries to connect to the mobile node, it looks up the mobile node’s name in the name server. The name server returns MN’s DAG with the rendezvous agent as a fallback. Then CN use this DAG to setup connection with MN.

2)MN leaves its original place and enters another network. MN notices that the network NID changes, updates the local host DAG and sends a binding update (BU) message to inform RA about its new location. After receiving the BU, RA refreshes its correspondent binding cache entry (BCE) of MN. Now, RA is able to direct packets to MN’s latest place.

3)Packets destined to MN arrive on the router in the original network via standard routing protocol of XIA. The route entry to MN is not available in the original router after MN left. Instead of sending an XCMP unreachable message to the source, the original router forwards these packets to RA according to the fallback path in the destination DAG.(XCMP is similar to ICMP in IP. The XMCP unreachable message would normally be sent by the last hop router serving a MN if it is no longer attached to the network via that router.)

Fig. 4 General principle of mobility support in IA

Fig. 5 Optimized routing between MN and CN

4)If a mobile node is not in its original network, packets originate from CN take a fallback and reach the rendezvous agent. While receiving packets via the fallback, RA checks its BCE and decides whether the HID of the destination DAG in the arrived packets is registered. If succeeds, RA rewrites the primary path in the received packet’s destination DAG to reflect the latest known location of the mobile node. And then the packet is sent on the network like a new one.

5)In the new place, MN receives the packets redirected by RA. Then, the new DAG of MN will be used as the source DAG for the response packets back to CN.

6)When CN receives the packets sent from MN’s new place, CN notices that the NID part of the source DAG changes, while remaining the same HID. CN views as the same connection with MN. Because the SOCK_STREAM typed connections are bound to the source and destination HIDs remain unchanged while MN roams from one network to another. In order to achieve more efficient routing, CN updates the destination DAG of the intended MN, and send the following packets directly to MN’s latest location. Thus, the subsequent traffic will be route-optimized and the triangle routing might be avoided. The optimized routing between CN and MN is shown in Figure 5.

3.4 Rendezvous agent

RA is required for mobile nodes that might roam from one place to another. RA allows MNs to update their mapping information of the stable host identifier (HID) and the changing network address (NID) as they move across the network. RA also intercepts packets sent by correspondents to MN’s old place via fallback, and delivers them to MNs’ latest place. In other words, the mobility management functions are centralized in RA, which combining the mobility management functionality of control plane and data plane.

Differences with Mobile IP:There are three important differences between RA in XIA and home agent in Mobile IP. Firstly,unlike Mobile IP where home agent has to be located in a mobile node’s home network, RA is not required to share the same NID with MN, and its location can be selected based on considerations of security, bandwidth, disaster recovery, etc., as long as the RA is not itself mobile or inside a mobile network. Secondly, RA redirects packets to MN by updating NID in packets destination DAG. No header in header (or DAG in DAG) or no tunnels are used, unlike IP where tunnels have to be used between home agent and care-of-address. Our design choice is natural to XIA addressing structure, which has the advantage of lower header size and processing overheads. Finally,RA is not assumed to have any pre-existing trust relationship with the mobile node. It is different from Mobile IP, in which there is a long-term IPSec tunnel between the mobile and its home agent.

IV. SECURE MOBILITY IN XIA

4.1 Security requirements

Security and mobility management are inexorably intertwined, because mobility might open up the potential for a number of security problems, including attacks against the mechanisms of mobility. In our proposed mobility support mechanism, it is necessary to send BU messages to RA as soon as MN has moved to a new place. BU to RA can assure the reachability of packets destined to MN’s old place.BUs are also used to inform CNs about the new DAG of MN in order to avoid the triangle routing. Attackers might forge the source DAG in the header to mislead CN directing the following packets to a wrong place. If the binding update messages to RA or CNs are not authenticated, the update procedure cannot be guaranteed to proceed correctly and vulnerability might be introduced, such as spoofing,man-in-the-middle, replaying attack and reflection attacks.

In XIA, HID is cryptographically generated, which is the hash of host’s public key.Such feature allows the mobile node to provide a proof of ownership of its identity and to sign the BU messages with its private key.This assures the correctness of the mobile node’s identity, making the spoofing or manin-the-middle attack against the mobile node much harder. But, it does little to ensure that the mobile node is actually reachable at that network part of the address. A malicious or compromised node could be lying about its own location in BUs, which opens the door for attacker to redirect traffic that was intended to the mobile node originally to a location of its choice. Attackers can flood a victim with unwanted packets by using the binding update to redirect a data stream towards it. If used in combination of distributed correspondent nodes, extra traffic will be burst toward the victim, which will consume victim resources.As shown in Figure 6, the victim is likely to suffer from terrible distributed denial-of-service attack.

The binding update process also might be threatened by the replaying attack (shown in Figure 7). Instead of forging or modifying the binding update, attackers might capture the binding information and then replay it later.It will misinform the correspondents to direct packets to the out-dated places. This can lead to denial-of-service because the mobile node is unable to reach.

To wrap up, the security requirements for XIA mobility include:

–A correspondent node or RA must not update its binding cache on receiving a binding update from any mobile node without verifying that the packet was sent by an authorized one.

–A correspondent node or RA must not update its binding cache until it has verified the sender of binding update is indeed at the claimed new address.

Fig. 6 Reflection flooding attack

Fig. 7 Replaying attack

Security is intrinsic in the XIA architecture with hash of a host’s public key as its self-certifying identifier. The current design of XIA team covers usage of intrinsic security between hosts and routers. In the following sections we will explain how this intrinsic security is used to address the security problem in the mobility management mechanism outlined above. We assume there is no existence of a PKI or other global security infrastructure and the security of the protocol depends on the partial reliability of the routing infrastructure.LetKUMN/KRMNrepresent the public and private key pair of a mobile node.

Fig. 9 Message exchange in update process

The objective behind XIA mobility is to allow MNs to update their network locations as they move across the global network. As shown in Figure 8, the main components involved in the secure mobility scheme consist of a mobile node, an access router, a rendezvous agent and a correspondent node. MN moves into network NIDNewand wants to inform RA and CN of its new binding: (HID,NIDNew). There are overall three parts messages exchange during the whole update processes, as shown in Figure 9, including Access Authentication, BU to RA Authentication and Route Optimization Authentication.

4.2 Access authentication

Access authentication in the access router is used to prevent the source address spoofing attacks. Source address spoofing refers to a host using a source address that has been assigned to another. Access authentication of a host in XIA inherits from Accountable Internet Protocol (AIP) [27].

If a mobile host enters into the service area of a network, it learns the NID and router’s HID via the XMCP beacon message. The mobile host registers itself to the new access router by sending a host registration request.When a access router receives a packet for the first time from a host, it drops the packet and sends a verification packet

back to the mobile host.HIDsrcandHIDdstare the source and destination HID of the original packet,HIDsrcis also the HID of host that was challenged, andifaceis the router’s network interface on which the packet was received.HMACRis a random value used to match the response message later. This allows the router to not maintain any state for challenges it sends. HMACRis generated from a secretkRknown only to the router,

When MN receives theverification V, it takesVas input and replies router witharesponse message R:

is the signature using the host’s private keyKRMN.KUMNis the public key of MN.

On receiving the response, the router performs a number of checks including:

–VerifiesHMACRto ensure this response is in response to a challenge sent by this router.

–Accepts packets only if theifaceroute to the packet’s source address points to the same interface on which the packet arrived.

–Verifies Hash of public key in response matches the sending host’s HID.

–Verifies the signature using the public key of the sender.

If all the checks are valid, the sending host’s HID is added to the routing table whitelist of senders allowed to send packets through this router. After successfully accesses, the mobile node updates the local host DAG with the new NID.

In practice, the packet being dropped is the registration message to the router notifying it that this host is now reachable through the router. This message is sent after the first XHCP beacon is detected by the XHCP Client running on the host. It is the host’s responsibility to retransmit that packet in order to register on the new network, after the access authentication process.

4.3 Binding update (BU)authentication

In our design, MN generates and sends BU to RA once it joins in a new network.

BU message generation:If a mobile node connects to a network for the first time, it sends a registering message to rendezvous agent reporting the binding about its HID and the current NID it attaches. When the mobile node moves to another network, it informs rendezvous agent about the new binding via a binding update message. Actually, RA registering and updating message are quite similar,with registering being a first-time update.Therefore, in examining security, our attention will be restricted to the binding update in the remainder.

On detecting to a new NID, mobile node notices the change of NID and sends RA a binding update message

signed by its private key. MN’spublic keyKUMNis added for the signature verification,timestampTBUis the creation time of the binding update used to verify the freshness of the BU and prevent the replaying attack.

Location verification in access router:The access router monitors BU packet going out of its network in order to verify the location in the binding generated by the inside mobile nodes. The role of access router can be seen as a filtering on path, it focuses on filtering out the forged BU to prevent the mobile node lying about its own location.

For the BU message, router first verifies the identity of the sender using MN’s public key.Then, the router checks whether the location information NIDNewin the binding update message matched with its actual local network identity. The BU packets will be dropped if the location information is false. Checking whether a packet is a BU packet is a process similar to that for detecting an ICMP packet in IP. We assume BU detection overhead is also on the level of XCMP packet detection in XIA. Location verification by the access router prevents a compromised node sending a fake BU to RA originates from the attacker’s network.

BU acceptance in RA:On receiving the BU message, the rendezvous agent does as follows:

–Verifies the MN’s public key included in BU message matches the sender’s HID.

–Verifies that the signature is valid, using the public key in the message.

–Verifies the timestamp is newer than the last seen timestamp for the same sender.The timestampTBUis used to avoid the replaying attack and BU flooding attack.Packets will be dropped if the received BU is out-dated.

If all the checking is passed, RA returns a binding acknowledgment (BA)to MN indicating the new binding is accepted.RA refreshes the corresponding BCE of MN,by recording the new NID that the mobile node joins currently. Finally, MN’s binding entry is stored at RA as: (HIDMN: NIDMN, TBU).At this point, RA is able to direct packets to MN’s latest place according to this BCE as long as RA is available.

4.4 Route optimization (RO)authentication

Route optimization means a mobile node notifies the new DAG to its peers while moving from one place another, so that subsequent packets from CN will be routed along the optimized path, no longer through the rendezvous agent. Route optimization is achieved by sending binding update messages with a signature to each remote peer.

Be similarly, the BU to CN for route optimization containsDAGMN, DAGCN, TBU, KUMNand the signature using MN’s private key.DAGMNis MN’s DAG with the new NID that was joined.DAGCNis the DAG of the correspondent node.TBUis the current timestamp to discourage replay attacks.KUMNis the public key matching theHIDMNinDAGMNthat can be used to verify the signature. BU for route optimization originated from MN is also firstly checked by the access router in order to found out the forged one.

When the legal BU arrives on CN, CN does the same as RA, including verifying the hash of MN’s public key, validating the signature and the timestamp. If all the checking is positive, CN responds with a BA messages signed by its private key, indicating receipt of the BU message and the new binding is accepted. CN updates the binding cache entry forHIDMNwithNIDNew, which allows future packets to be sent directly to MN’s latest locationNIDNew.

V. EXPERIMENTS

In this section, we develop a test environment to verify the proposed mechanism support for mobility in XIA context. Without loss of generality, the scenarios of virtual machine migration and host mobility are evaluated respectively in two tests. The effectiveness of the mobility mechanisms support for UDP based and TCP based application are also given.

5.1 Test environment

The topology of the test environment is shown in Figure 10. XIA Router1 and XIA Router2 are the gateway routers belonging to subnet1 and subnet2 respectively. In test1, A virtual machine (VM) originally runs in Host1, lively migrates to Host2. A mobile node (Client) is connected to Router2 via a LAN switch, simulating a remote user of VM. In test2, the VM stays in subnet1. Instead, the Client roams to subnet1. All PCs are connected with 100Mbps switched Ethernet networks. Linux (Ubuntu 12.04 with kernel version 3.5.0) is the operation system. And the XIA protocol prototype is based on Click Modular router. The source code of XIA prototype can be obtained from GitHub (http://www.github.com/xia-project/xiacore).

In the implementation, we do the following modifications of the XIA prototype.

–For XIA routers, the time-out mechanism of routing table is added, in order to trigger the router to forward the packets using fallback. Besides, the location verification function of Binding Update message filtering is added, in order to find out the forged BU and prevent the compromised mobile node lying about its NID.

–RA is a new functional entity introduced.We implement the function of location management and packets forwarding for registered mobile nodes in RA. RA maintains a binding cache entry table and changes the NID part of destination DAG when intercepting packets via fallback.

–For the purpose of RA discovery, we piggyback the DAG of RA in the XHCP beacon message in XHCP server.

– For each mobile node, the function of registrationto RA, movement detection and binding update are implemented in XHCP clients.

5.2 Test 1: VM migration

In this test, the VM is migrated from subnet1 to subnet2, while communicating with a Client. The VM locates in subnet1 originally, and its DAG is NID1àHIDVM. When migrating to subnet2, VM’s DAG becomes NID2àHIDVM.So, the VM is no longer reachable at subnet1 and the connections between MN and the Client might be lost. Kernel-based Virtual Machine (KVM) running on Host1 and Host2 are chosen as the hypervisor handling VM migration. To examine the effectiveness of the proposed method, we are interested in the service response time that a Client connecting to a service on the VM. To determine the exact service response time,Xpingis executed repeatedly on the Client, with VM as the target.For theXpingcommand, the XMCP message is sent to VM periodically. According to the interval time ofXpingand the number of responses, the service response time s obtained.

The service response time during VM migration is shown in Figure 11. The process of VM migration consists of four stages: before migration, ongoing migration, frozen VM, and after migration. The correspondent service response time varies. In the period of frozen VM, the service response time can be viewed as infinite. The mean and standard deviation of service response time are shown in Table 1.

According to Table 1, in the stage of ongoing migration, both of the average service response time (8.16ms) and the value of Std.(1.51)are obviously larger than that of before and after migration. This is because during the ongoing migration, dirty pages of VM transferring takes up a lot of network bandwidth,and the pre-copy operation of dirty pages is erratic. On the contrary, there is no other application sharing the bandwidth before and after migration, so the latency between VM and Client is shorter and smoother. We also notice that, after migration, the mean value of service response time is higher than that of migration happening (2.91msvs.1.92ms).This is because the destination DAG of the XCMP messages originates from Client point to the old place of VM. Thus,Xpingpackets are indirectly forwarded by RA, and an extra processing delay of RA is introduced, which prolongs the response time. To solve this issue, it is better to check the Name Server periodically to update the DAG of VM for the UDP based applications. For a public service,the VM should actively updates the Name Server when a network change is detected by its XHCP client, to make sure that the new connections point to the new place of VM.

Table I Service response time

Fig. 11 Service response time during VM migration

5.3 Test 2: Host Mobility

In this test, the Client plays the role of a mobile node. It roams from subnet2 to subnet1 while communicating with VM (runs in subnet1). During the movement, the performance of route optimization is evaluated via a Plus application. In Plus application, the VM sends a number to Client periodically. The number is incremented by one and is then sent back by the Client. To get the service response time, a timer is set in VM when a number is sent out.After receiving the return number, the time recorded in timer is the service response time.The exact service response time before and after Client movement is shown in Figure 12.

It can be found that the average response time after Client moving is shorter than before.It implies that the messages originate from VM are forwarded to the latest place of Client directly, other than redirected by RA. It proofs that the route optimization mechanism works.For the TCP based or SOCK_STREAM typed applications in our design, the mobile node would notify its CNs about its new DAG via the signed binding update message. In this test, the Client sends a binding update to VM after connecting to subnet1. VM verifies the signature, updates the DAG, and sends the future packets directly to the latest location of Client. The processing time of RA and Router2 is eliminated compared with before, which brings a lower service response time.

Fig. 12 Service response time before and after moving

For the mobile service migration scenario[33], the binding update to CN is piggybacked in the payload of a SYNACK packet, when the mobile service receives a SYN request and notices that it went through RA. Our design is a mobility support solution in the network layer other than the transport layer. The binding update info is the payload of a type of XCMP message in the control plane, other than piggybacked in the payload of a SYNACK packet in the data plane or at the session level. This design makes our method a more general solution support for diverse mobility scenarios in XIA, including host/device mobility, service migration, and subnet mobility.

VI. DICUSSION

6.1 Efficiency and flexibility

We introduce a rendezvous agent to allow seamless network handover in XIA. RA is responsible for mobility management of mobile nodes.

Support for Micro mobility:RA could serve a set of mobile nodes. RA might be a single-point-of-failure and become the potential bottleneck, if it is not sufficient to serve all mobile nodes. To solve this, in XIA, RA can be designed as a rendezvous service (RS) for registered mobile nodes. RS can be achieved by distributed rendezvous agents (servers)provided by ISP. If MN registers to RS instead of a single RA, the fallback in the DAG of MN will point to a service ID (SID) of RS.When MN moves, the BU message will be sent to RS via SID routing supported by XIA router. It gives a choice to decide the optical RS instance in charge of MN according to the policy of SID routing, such as shortest path or service level. This gives a solution for micro-mobility management optimization [29],which using distributed logic to optimize handover efficiency and avoid unnecessarily long routes of binding updates.

Support for NEtwork MObility (NEMO):Network mobility refers to the mobility of an entire network, such as networks attached to people (Personal Area Networks, PANs), net-works deployed in aircrafts, boats, cars, trains(Vehicle Area Networks, VANs) dynamically changes its attachment points to the roadside wireless access networks.

In NEMO, mobile router (MR) manages its internal routing and connects the whole moving network to the external network. In our solution, RA can be assigned to each MR,reachability achieving by having the MR sends the binding updates. A single message to the RA of the MR will be sufficient to update the whole network, thus offering reduction in time and bandwidth consumption. Moreover,there is no pinball routing problem as the level of nested mobile network increases. Despite of the number of nested layers, all data packets destined to nested MR within up-layer mobile network are forwarded to its own RA first via fallback and then directed to its current location directly. There is no needing of passing each RA for every nested MR. On the contrary, network mobility basic support (NEMO-BS) [28] proposed in RFC3963, suffers terrible pinball routing problem as the level of nesting increases. All the HAs being involved in the communication path will lead to a large number of encapsulations, which might result in long delays in control plane and serious header overheads in data plane.

Application Optimality:Our solution might gain more benefits for the scenarios that the movement of MN can be predicated, such as public transportation or VM migration. For public transportation, the router on bus have planned and scheduled routes. The place a bus moves to can be known based on its current position before the handover happens. Be similarly, for the case of VM migration, the target location and the time migration happens can be obtained by the hypervisor. These two cases give an opportunity to perform the signaling action to RA in advance. By enabling the MN update the binding info in the near future to RA, it will save one RTT (round-trip-time) between MN and RA, when the handoff actually happens. The handover latency and packets loss would be reduced. It is important for the task critical vehicles or time sensitive service that requiring high handover performance.

6.2 Security

In XIA, the access authentication is achieved using self-certifying addresses to verify the source of packets. The packets will be dropped if the source addresses are spoofed. This prevents the source spoofing attack, in which a source uses a spoofed address cannot receive packets.

In our design, we did not assume safe tunnel exists between MN and RA, or MN and CN, as that in Mobile IP. So it is necessary to protect the binding update messages between them. A binding update message contains two pieces of information, the HID and NID. RA or the CNs should check correctness of both the HID and the NID in the binding update.We use self-certifying addresses to validate the binding update message in two places.

First, the first-hop router verifies that its directly-connected hosts are not lying about its claimed location NID. The role of access router can be seen as a filtering on path, it focuses on filtering out spoofing packets coming from local access network and checking location information in BU to prevent the mobile lying about its own location. The BU requests will be rejected when the location information is false. The location verification in access router can prevent most of reflecting attacks.

Second, the signature of MN verifies the integrity and authenticity of the sender’s identity. HID is cryptographically generated, which is the hash of owner’s public key. Such feature allows the mobile node to provide a proof of ownership of its identity. Binding update signed by MN’s private key provides a level of assurance that the HID is not spoofed, which can protect against masquerading attack and man-in-the-middle attack. Attackers cannot claim to be the mobile node, because only the mobile node knows its private key. It is computationally hard to either find the private key or forge a digital signature given a public key.Replaying attack can be mitigated by having a timestamp in each binding update process.

Computational Cost:There are mainly three computational processes for MN (the same as CN), including signing a BU message using a private key, hashing the public key and verifying a signed BA message using a public key. The cost to generate a key pair is omitted here. The computational cost of the Hash operations and signature verification is much smaller than the signing operation. According to cost measures in eBACS (ECRYPT Benchmarking of Cryptographic Systems) [34], for the CPU of Intel Core i5-3210M, 2x2.5GHz,the time to sign a message using 1024-bit RSA signatures is almost 1.4×106CPU cycles. The time of hashing a 128-byte public key using SHA-1 (1024) and the time of verifying a signature on a short message is approximate 1408 and 39412 CPU cycles respectively. So public-key cryptography is computationally much less efficient than authentication through a shared secret key [32]. In order to minimize the number of computation-expensive operations during every movement, the routing optimization authentication process can be divided into two phases. In the first phase, mobile node negotiates an initial shared secret key with the correspondent node using its signature and Diffie-Hellman key exchange, which is executed only once. In the second phase, a more effective hashing operation other than asymmetric cryptographic operation can be used to authenticate the future binding update message.

Network-based Method:In order to reduce the burden of MN, there is another design choice based on the same set of mechanisms,with the difference in access routers send BU messages on behalf of MN. In this router-based variant, it is helpful to MN, because the movement is transparent to MN. However,the choice has significance in meeting with security requirements. We strive to achieve a design with protection against forged BU,which can be a real threat in a competitive and potentially hostile environment of mobility.For non-router based version in this paper, our design rule forbids different sender of BU to RA other than MN itself. Therefore, additional authentication with nodes other than the original MN is not required, simplifying security issues that arise from using RA for MN.

VII. CONCLUSION

The experiences from the future Internet architecture design processes highlight the need to consider early the solution of mobility and security. This paper focuses on secure mobility support in XIA architecture context. We gave a mobility support mechanism in XIA: introduced a rendezvous agent providing mobility service for each mobile node, and set the fallback to RA in mobile node’s DAG to ensure the reachability. Threats created by the proposed mechanism were also analyzed. What is more, inspired by the self-certifying features,we proposed a secure procedure for mobility support, including access authentication, BU to RA authentication and route optimization authentication, to overcome the potential threats. The greatest advantage is that it does not rely on a public key infrastructure. If such a protocol were implemented in XIA, most of the attacks mentioned can be effectively prevented. Finally, we illustrated that utilizing the versatile routing with fallback in DAG, the proposed mechanism can give flexible support for mobility cases, such as micro-mobility management, NEMO, and other specific application optimality. Our design is reasonably efficient, with no tunnels used. It is believed that this design will reduce the complexity of handover procedure, eliminate the pinball routing and serious header overheads, especially in nested NEMO case.

ACKNOWLEDGEMENTS

The work presented in this study is supported by NSFC (No. 61672060), and National High Technology Research and Development Program of China (863 Program, No.2015AA015701).

[1] J. Pan, S. Paul, and R. Jain, “A Survey of the Research on Future Internet Architectures,” IEEE Communications Magazine, July 2011.

[2] V. Mann, A. Vishnoi, K. Kannan and S. Kalyanaraman, “CrossRoads: Seamless VM Mobility across Data Centers through Software Defined Networking,” Network Operations and Management Symposium (NOMS), IEEE, 2012.

[3] U. Kalim, M.K. Gardner, E.J. Brown, and Wu-chun Feng, “Seamless Migration of Virtual Machines Across Networks,” Computer Communications and Networks (ICCCN), 2013 22nd International Conference.

[4] Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2011-2016.

[5] Z. Zhu, R. Wakikawa, and L. Zhang, “A Survey of Mobility Support in the Internet,” RFC 6301,July, 2011.

[6] XIA Project. http://www.cs.cmu.edu/～xia/ ,2013.

[7] NSF Future Internet Architecture Project Next Phase. http://www.nets-fia.net/, 2014.

[8] T. R. Henderson, “Host Mobility for IP Networks:A Comparison,” IEEE Network, 6(17): 18-26, November, 2003.

[9] C. Perkins, “IP Mobility Support for IPv4,” RFC 3344, August, 2002.

[10] D. Johnson, C. Perkins and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June, 2004.

[11] T. Aura, M. Roe, “Designing the mobile IPv6 security protocol,” ANN. Telecommun, 61(3-4):332-356, 2006.

[12] A. Mankin, B. Patil, D. Harkins, et al., “Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6”, draft-ietfmobile-ip-mipv6-scrty-reqts-02, Expired IETF Internet draft, November 2001.

[13] G. Shea, M. Roe, “Child-Proof Authentication for MIPv6 (CAM)”, Computer Communications Review, April 2001.

[14] T. Aura, “Cryptographically Generated Addresses (CGA)” RFC 3972, March 2005.

[15] M. Roe, T. Aura, G. OShea, J. Arkko, “Authentication of Mobile IPv6 Binding Updates and Acknowledgments”, draftroe-mobileip-updateauth-02.txt, Expired IETF Intenet draft, 2002.

[16] W. Haddad, L. Madour, J. Arkko, F. Dupont, “Applying Cryptographically Generated Addresses to Optimize MIPv6 (CGAOMIPv6)”, draft-haddad-mip6-cga-omipv6-03, Expired IETF Internet draft, 2004.

[17] J. Arkko, C. Vogt, W. Haddad, “Enhanced Route Optimization for Mobile IPv6”, RFC 4866, May 2007.

[18] P. Nikander, J. Yljtalo. J. Wall, “Integrating security, mobility, and multi-homing in a HIP way,” In Proc.Network and Distributed Systems Security Symposium (NDSS’03). pp. 87-99, San Diego,CA USA, February 2003.

[19] P. Raad, G. Colombo, D.P. Chi, S. Secci, etc.,“Achieving Sub-Second Downtimes in Internet-wide Virtual Machine Live Migrations in LISP Networks,” Integrated Network Management (IM 2013).

[20] S.N. Bhatti, R. Atkinson, “Secure & Agile Wide-Area Virtual Machine Mobility,” MILITARY COMMUNICATIONS CONFERENCE, 2012.

[21] D. Raychaudhuri, K. Nagaraja and A. Venkataramani, “MobilityFirst: A Robust and Trustworthy MobilityCentric Architecture for the Future Internet,” ACM SIGMobile Mobile Computing and Communication Review (MC2R), Volume 16 Issue 4, October, 2012.

[22] X. Liu, W. Trappe and Y. Zhang, “Secure Name Resolution for Identifier-to-Locator Mappings in the Global Internet,” IEEE International Conference on Computer Communications and Networks (ICCCN), Nassau, Bahamas, July, 2013.

[23] M. M. Muslam, H. A. Chan and N. Ventura, “HIP based Micro-Mobility Management Optimization,” Fifth International Conference on Wireless and Mobile Communications, 2009.

[24] D. Naylor, M. K. Mukerjee, et al., “XIA: Architecting a More Trustworthy and Evolvable Internet,”ACM SIGCOMM Computer Communication,Volume 44, Number 3, pp. 50-57, July 2014.

[25] D. Han, A. Anand, et al., “XIA: Efficient Support for Evolvable Internetworking,” The 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI’12), San Jose, CA, April 25-27, 2012.

[26] A. Anand, F. Dogar, D. Han, et al., “XIA: An Architecture for an Evolvable and Trustworthy Internet. Tenth ACM Workshop on Hot Topics in Networks (HotNets-X), Cambridge, MA, November, 2011.

[27] D. G. Andersen, H. Balakrishnan, N. Feamster, T.Koponen, D. Moon, and S. Shenker, “Accountable Internet Protocol (AIP),” SIGCOMM’08, 2008,17-22.

[28] V. Devarapalli, R. Wakikawa, A. Petrescu, and P.Thubert, “Network mobility (NEMO) basic support protocol”, RFC 3963, January 2005.

[29] H. Soliman, C. Castelluccia, K. El Malki, L. Bellier,“Hierarchical Mobile IPv6 Mobility Management（HMIPv6),” IETF RFC 4140, 2005.8.

[30] F. Yang, S. Wang, et al., “An Overview of Internet of Vehicles,” China Communications, 2014,11(10): 1-15.

[31] J. Liu, T. Li, G. Cheng, H.Yu, and Z. Lei, “Mining and Modeling the Dynamic Patterns of Service Providers in Cellular Data Network Based on Big Data Analysis,” China Communications, 2013,10(12): 25-36.

[32] S. Kuang, R. Elz and S. Kamolphiwong, “Investigating Enhanced Route Optimization for Mobile IPv6”, 13th Asia-Pacific on Computer Systems Architecture Conference(ACSAC 2008), Hsinchu,Taiwan, 2008.

[33] XIA Mobility and Intrinsic Security. https://github.com/XIA-Project/xia-core/wiki/XIA-Mobility-and-Intrinsic-Security#mobile-service-migration-using-rendezvous-service,2015.

[34] eBACS (ECRYPT Benchmarking of Cryptograph-ic Systems). http://bench.cr.yp.to/ebats.html,2015.