End-to-End Host Mobility Using SCTP

Transcription

1 End-to-End Host Mobility Using SCTP Lei Li, Russell Clark, Ellen Zegura College of Computing, Georgia Institute of Technology, Atlanta, Georgia Abstract We present the design and implementation of an end-to-end mobility architecture using the Stream Control Transmission Protocol. We propose a new Secure host IDentifier (SID) used to identify Internet hosts. The SID is used as the transport layer endpoint identifier, allowing connections to be maintained across an IP address change. We have designed and implemented a mobility extension to SCTP which includes security mechanisms to prevent connection hijacking and man-in-the-middle attacks. The architecture provides a mobility-enabled transport layer that is truly independent of network layer address changes. I. INTRODUCTION With the growing use of mobile communication devices such as laptops, PDAs and cellular phones, mobility support is increasingly important for applications requiring reliable network connectivity. However, today s Internet was not designed for a mobile user base. The current fixed IP address hierarchy remains critical for achieving scalability in the global routing architecture. Further, the IP address is overloaded in the sense that it not only serves for routing packets, but also functions as a host identifier. This overloading is a significant obstacle to host mobility. For instance, if a mobile host is assigned a new IP address as it moves in the network, the host s identity changes. In the case of current open connections such as TCP, the established state is no longer valid and a new connection must be established. Network-based solutions such as Mobile IP [1] have been developed to support mobile host location in the current fixed address model. However, this solution is still not widely deployed and suffers from scaling limitations, due to both management complexities and triangle routing inefficiencies. By comparison, an end-to-end mobility architecture reduces complexity by efficiently handling mobility at the two communicating endpoints. Existing end-to-end approaches such as TCP migration [2] and Reliable Sockets [3] are extensions to TCP. Both approaches provide transparent network mobility for applications to survive a change in the IP address of one of the endpoints. They use a Diffie-Hellman key exchange to establish a token, identifying the connection as the IP address changes. Also a secret session key is negotiated to protect the reconnection after address change. While guarding against connection hijacking, neither approach can protect the connection from a man-in-the-middle attack [4]. We propose that network hosts should have a unique, long-lived identifier that forms the basis of all endpoint identification. The Secure Host ID, a new host identifier, is introduced to separate the host identity function from the packet delivery function in the network layer. In addition to the host identification support, a public key pair is associated with the Secure Host ID to provide the security basis for host mobility. The Secure Host ID concept is applicable to a wide range of protocols and applications. We have developed a prototype implementation of our ideas using SCTP (Stream Control Transmission Protocol) [5]. SCTP is a reliable transport protocol with two major features favoring end-to-end host mobility: multi-homing and dynamic IP address change [6]. We have designed an extensible approach to incorporating the secure host identifier in the SCTP connection management. We have also successfully implemented and tested this approach to demonstrate feasibility. The rest of this paper is organized as follows. The next section describes the host identity concept by introducing the Secure Host Identifier. Section III describes our proposed endto-end mobility architecture. Section IV expands on our implementation design for mobile SCTP together with experiment and discussions. Conclusions and future work are presented in Section V. II. SID - PUBLIC KEY BASED SECURE HOST ID We introduce the Secure Host ID (SID), a cryptographically based host ID independent of IP address. SID is a globally unique, 128 bit identifier assigned to a network host. This identifier has built-in end-to-end security based on public key authentication. The SID is a new hierarchical namespace. A central authority allocates subspaces to different domains. The domain authority then assigns a SID to each host in the domain. Each SID is associated with a pair of asymmetric keys, used for authentication and other security services. In the current work, this is used for the secure re-addressing of the host when its IP address changes. An asymmetric key pair consists of a private signing key only known to the SID owner and a public verification key publicly known. The association between SID, Key pair and SID ownership information needs to be established through secure mechanisms. One approach is to store SID and its associated parameters (public key, ownership) in a directory service like secure DNS or secure LDAP. Secure access and update mechanism like DNSSEC [7] is applied to ensure the authenticity of each SID and associated parameters. Another mechanism to secure the mapping between SID and associated parameters is certification through a Public Key Infrastructure (PKI) [8]. A Public Key Infrastructure consists of components to securely distribute, manage the certification of SIDs. Each

2 SID and its associated parameters are certified by a Certificate Authority (CA). Based on the PKI s chain of trust model, the communication endpoints in different domains can locate each other s trust anchor and discover a trust verification chain from the trust anchor to the target SID. In a related work, Host Identity Payload (HIP) [9] defines Host Identity (HI), also a new namespace that decouples internetworking from the transport layer. The public key associated with HI is hashed into a 128 bit identifier tag (Host Identity Tag). Hashing secures the mapping between host identifier and a particular public key, but it complicates the hierarchical domain management if HIT is used as a globally unique identifier. III. END-TO-END APPROACH TO HOST MOBILITY In this section, we generalize several major components of an end-to-end mobility architecture, and present our choice of design by applying the Secure Host ID as an endpoint identifier to allow transport layer mobility. Connection Initialization (SID Exchange) Connection Resumption (SID Verification) Network 1 Network 2 Fig. 1. Connection Initialization End-to-End Approach to Mobility A mobility-enabled communication must perform some work in connection establishment in order to survive a change of IP address in the middle of a connection. To eliminate the current transport layer s dependency on IP addresses, a connection identifier independent of IP addresses is needed. Communicating peers use this identifier to identify the previous connection and reconnect. Current practice for such a connection identifier includes using Diffie Hellman key exchange to negotiate a connection token [2], or a connection ID negotiated based on addresses of both endpoints and a timestamp [3]. A shared key is negotiated for authentication purpose in later reconnection to defend against threats like connection hijacking. Instead of negotiating a connection token for each session, our approach uses each peer s SID as the host identifier instead of a changeable IP address. Two peers exchange SIDs during connection initialization. In the place of the IP address, the SID is bound to the transport layer socket. A connection is uniquely identified by two peers SIDs and port numbers, which are static even if the IP address of either peer changes due to mobility. The IP address only serves for packet routing. Diffie Hellman key exchange is vulnerable to the well known man-in-the-middle attack [4]. Instead of negotiating a shared key for each session, peers use the asymmetric key pairs associated with their SIDs for identity authentication. The connection establishment and reconnection is protected through signature verification. Mobile Host Location When a moving host moves into a different network as in Figure 1, it is assigned with a new IP address through mechanisms such as manual allocation or the Dynamic Host Configuration Protocol (DHCP) [10]. Then the mobile host can actively inform the fixed host of its new location, since a mobile host is aware of its movement and change of IP address. A reconnect request is sent to fixed host to resume the previous connection. This end-to-end approach to mobile host location requires no third party support by direct notification from the mobile end to the fixed end. However, if two communicating hosts move simultaneously, then active reconnection fails without support from a third party providing dynamic host location update, such as using dynamic DNS update in [2]. Dynamic DNS updating is beneficial for mobile servers. When the mobile server moves, it has to update DNS entry to let other clients know its new IP address, otherwise, the server simply disappears from the Internet. Normally, fixed server is not likely to move around, locating a mobile host through dynamic DNS update increases the time cost of reconnection. Connection Resumption When a request to resume a previous connection arrives, the connection identifier is presented to locate the connection to be resumed. To protect against the potential connection hijacking threat, this reconnect request should also be verified to be a legitimate request for the connection. In [2], the connection token is used to locate the previous connection, and another parameter request is computed by mobile host based on the pre-established Diffie Hellman Key and request packet data. The fixed host verifies this request using the shared Diffie Hellman Key to authenticate the reconnect request. In [3], the authentication is done through a challenge-response protocol based on the pre-negotiated Diffie Hellman shared key. In our approach, a reconnect request from a mobile host uses its SID:port to indicate which connection to resume. In addition, a mobile host signs the reconnect request using the private key associated with its SID. This signature could be verified by the fixed host using the public key associated with the mobile host s SID. Security Issues Today s network communication is exposed to various security threats such as connection hijacking, man-in-the-middle attack, replay attack, DoS (Denial of Service) attack [4]. Due to the reconnection from a new IP address, these threats are strengthened (a better verb?) in a mobile environment.

3 A malicious party can eavesdrop a mobile communication session, send a spoofed reconnect request or replay the session later to impersonate other host identity. We present solutions to defend against these threats in our mobility extension to SCTP in next section. IV. IMPLEMENTATION OVER SCTP SCTP [5], a reliable transport protocol with features of multi-homing and dynamic IP address configuration [6], is a good candidate to implement our transport layer end-toend host mobility architecture. Based on a Linux user level prototype of SCTP [11], we have implemented our SCTP mobility extension. A Reliable Transport Protocol IV-1. SCTP OVERVIEW SCTP is a reliable transport protocol originally designed for transmission of signaling data. Some essential properties of SCTP are Multi-homing. Each endpoint may have multiple interfaces and an SCTP endpoint can use multiple IP addresses to communicate with another endpoint. A connection between two SCTP endpoints (multi-homed or not) is called an association. IP address can be dynamically added or deleted from an association [6] upon interface changes. Multi-streaming. In each SCTP association, multiple streams are exchanged between endpoints. This partial insequence message delivery reduces the head-of-line block problem in TCP where there is only one byte stream between peers. SCTP s general use of TLV (Type-Length-Value) format parameters gives great flexibility for protocol extension. Each SCTP packet contains one or more chunks defined in TLV (Type-Length-Value) format. Each chunk also consists of multiple parameters in TLV format. As a support for multi-homing, the SCTP Dynamic Address Configuration [6] defines control chunks ADDIP and DELIP to allow changing a multi-homed SCTP endpoint s IP address set. This provides convenient facility for IP handoff to support mobility. The mobile host s new IP address is dynamically added into a SCTP association by sending an ADDIP chunk to fixed host, the invalid old IP address is removed by sending an DELIP chunk. SCTP Limitations Regarding Mobility SCTP s multi-homing is really designed for redundancy, not mobility. An SCTP association is still identified based on IP addresses. It can t survive the change of the last and only IP address if the endpoint has only one interface, as generally occurs with a mobile host. During the IP handoff phase, a temporary link failure will break the current SCTP association. Although multiplexing of the wireless interface [12] may get around this limitation, a general mobility solution independent of the IP layer change is needed to handle IP handoff and connection disruption. The problem of a connection being hijacked by a malicious party, especially a man-in-the-middle attack is well known for end-to-end host mobility. Since SCTP was not designed for mobility, there are no security measures taken to defend against such threats for dynamic IP address change. In our SCTP mobility extension, we overcome these limitations by implementing Secure Host ID as the endpoint identifier, an SCTP association is identified based on SIDs, thus an association is kept valid and alive when the underlying IP address changes due to mobility. Signature-based authentication is implemented to defend against connection hijacking and man-in-the-middle attack. IV-2. SCTP MOBILITY EXTENSION In this section, we first briefly describe the process of a mobility-enabled SCTP association s initialization and resumption, then the detail of the mobility extension is presented. An SCTP communication with mobility extension proceeds as in Figure 2. First, two endpoints exchange SID (The number in superscript refers to the step in Figure 2) during association initialization, then similar to DNS resolution, each endpoint can query a SID server to get public key and Certificate associated with the peer s SID. After successful authentication of each other s identity and initiation request, an SCTP association is created and data communication starts. After mobile client moves into a new network and obtains a new IP address, it sends an ADDIP request to the fixed host to resume a previous association, the fixed host sends back an ADDIP ACK to the mobile client after verifies the ADDIP request. The mobile host also verifies that AD- DIP ACK is valid, then data communication resumes. 12 Move to 5. Authentication Mobile SCTP Client Mobile SCTP Client Fig SID_QUERY 4. SID_REPLY SID Server 1. INIT (SID) 2. INIT_ACK (SID, SIG) 6. COOKIE_ECHO (SID, SIG) 10. COOKIE_ACK 11. DATA 7. SID_QUERY 8. SID_REPLY 13. ADDIP (SID, SIG) 15. ADDIP_ACK 16. DATA SCTP with Mobility Extension SID Exchange in Association Initialization 9. Authentication 14. Authentication of ADDIP During SCTP s four way hand-shake process as in Figure 3, each peer s SID is exchanged in the SCTP INIT chunk s

4 optional/variable-length parameter. To start an SCTP association, the client first sends its SID in the INIT chunk to the server. The server sends back its own SID and signature (SIG) in INIT ACK chunk. A client proves its identity with a signature of its own in the third COOKIE ECHO chunk. To defend against a replay attack, two peers also exchange a random number (also called Nonce) during SID exchange. The signature (SIG) is computed over chunk data including SID, IP addresses to be used, Nonce, etc. The signature not only serves as a proof of identity but also ensures the integrity of critical information like IP addresses to be used. This is essential to protecting the association from being hijacked in a mobile environment. An initiated SCTP association is uniquely identified by two peer s SID and port numbers. With the SID in place of the IP address as the transport layer connection identifier, an SCTP association is able to sustain the temporary link failure and IP handoff when a mobile host moves into a different network. SCTP Mobile Client INIT(R c, SIDc ) INIT_ACK (R s, SID s, SIG=K s {INIT_ACK}) COOKIE_ECHO (SIG=K c {COOKIE_ACK}) COOKIE_ACK DATA Association Initialization Fig. 3. SCTP Mobile Client SCTP packet exchange SID Lookup and Signature Verification. ADDIP(SID c, newip, SIG) ADDIP_ACK (SIDs, newip, SIG) DELIP(SIDc, oldip, SIG) DELIP_ACK (SIDs, oldip, SIG) DATA Association Resumption After receiving chunks with SID and SIG parameters, each endpoint needs to verify the host identity and its signature. A peer s public key and certificate are to be retrieved from a directory service by the SID server. The SID server stores each SID s public key and certificate. Optionally the host s public key and certificate could be sent in the INIT and INIT ACK chunks, to save the time of querying the SID server. Certificate verification authenticates a peer s identity by verifying the validity of his SID and public key. Since there is no shared key negotiated during initialization, each host s private key is never exposed, man-in-the-middle attack against security key is prevented. Then using the peer s valid public key, an endpoint can verify the peer s signature. The four way handshake of SCTP initiation was designed to protect against DoS attack. Each time a server receives an INIT chunk, it generates a cookie containing all the information needed to create a association with the client, sends it over to the client and forgets about it. The server does not do heavy computation and allocates no resource until the client returns the cookie. In our mobility extension, public key signing and verification are heavyweight computations. A malicious attacker can launch a denial of service attack by flooding the server with invalid INIT chunks. The verification of these packets can use up a server s resource and legitimate requests are denied. We mitigate this threat by delaying the signature verification until the client returns the COOKIE ECHO chunk. However, signing each INIT ACK chunk still expose server in DoS attack because of the expensive public key computation. Association Resumption After the mobile host moves into a different network, it gets assigned with a different IP address through mechanisms like DHCP. Obtaining a new IP address is a network layer issue separated from transport layer in our architecture. The SCTP layer could be informed of this change of IP through a monitoring daemon. A mobile host s change of IP causes connection disruption between endpoints. To resume a disconnected association, a mobile host needs to update the association of this IP change. After a new IP address is assigned, an ADDIP chunk is sent to the fixed host to add this new IP address into its association state. Although the ADDIP chunk has a source IP address new to the fixed host, the fixed host can identify which association to resume through the SID parameter presented in the ADDIP chunk. The ADDIP chunk is signed by the mobile host. The fixed host can authenticate that this packet is from a previous communicating peer through signature verification. This prevents connection hijacking by an attacker pretending to be the mobile host. If signature verification is successful, the new IP address is added to the fixed host s association state. Then an AD- DIP ACK chunk is sent back to mobile host to confirm the reconnection request. The mobile host also needs to verify the signature in the ADDIP ACK chunk to prevent connection hijacking by attackers pretending to be the fixed host. For consistency with current SCTP specification, if a host has only one interface, this only IP address can not be removed from a live association, the old IP address, although not belonging to the mobile host any more, is still kept in the association until the new IP is safely added into the association. A DELIP chunk is sent to the fixed host to remove this invalid IP address from the association. After the DELIP chunk is acknowledged, the data communication resumes again between two endpoints. In this reconnection phase, either end do not need to access the SID server again to retrieve the other peer s public key and certificate, this info is cached during association initialization as part of the association state data. In our approach, the reconnection is done actively by the mobile host, the fixed host just waits for the moving host to reconnect. If the client doesn t reconnect within a time threshold, the association is closed as the timer expires. IV-3. EXPERIMENT AND DISCUSSIONS We have experimented with mobility in both wired and wireless networks. Figure 4 shows the network topology for the experiments. We created the host mobility by using DHCP renew to explicitly request a new IP address for the wireless interface (inside wireless network to location 2), or physically plugging in network cables connected to different local area networks (across wired networks to location 3).

5 Network 1 Access Point Fixed Host Location 2 Location 1 Location 3 Fig. 4. Network topology for mobility experiment Network 2 Currently, ADDIP and DELIP operations are performed manually after a change of IP address. We expect to automate this process using a daemon monitoring IP change and resuming the connection in the future. Results An established SCTP association is kept alive after a host moved to a different network or changed its IP address. Although querying to the SID server and public key verification during initialization causes increased overhead compared to ordinary SCTP connection establishment, these per-session security operations are acceptable considering the mobility and security achieved. In the reconnect phase, efficient reconnection is achieved through the ADDIP and DELIP exchanging without a third party involved. Interoperability Our mobility extension does not introduce any new messages to the SCTP specification [5], thus providing interoperability with ordinary SCTP implementations. Extension parameters like SID, SIG are in the Optional/Variable Parameter format defined in SCTP specification. An SCTP association initialization with presence of SID is detected as SCTP with the mobility extension, otherwise everything falls back to ordinary SCTP. The current SCTP specification requires at least one valid IP address for each SCTP endpoint in association state. To follow this specification and avoid major modification to the prototype implementation, the old invalid IP address is still kept in the association until the new IP address is added into the association. A better long term solution is to add a RESUMPTION WAIT state into SCTP state transition [5] in future. An SCTP endpoint enters RESUMPTION WAIT state when there is no valid IP address due to IP handoff or link failure. After the SCTP association is resumed, the endpoint returns back to ESTABLISHED state. IPsec and SSL/TLS In our work, we have focused on the security issues associated with mobility (hijacking, etc.) and not on the issue of securing the data stream itself such as through encryption. IPsec [13] and SSL/TLS [14] can be used in conjunction to protect data communication. Our public key based approach to security issues are similar to IPsec and SSL/TLS. However, an IPsec Security Association (SA) and its Security Policy Database(SPD) entry are keyed on IP addresses, it does not directly support changing IP addresses nor does it provide the transparency necessary to maintain an upper layer (e.g. TCP) connection. SSL/TLS is an application layer solution for secure communications. One aspect of SSL/TLS which is similar to our work is the ability to maintain a peer s certificate, cipher spec and master secret from a previous session through the use of a session ID. However, this session ID does not equate to maintaining a connection across address changes, and the cost to re-establish communication in such an event is higher than in our approach. V. CONCLUSION The current Mobile IP approach to host mobility is necessitated by the need to maintain hierarchical routing while also maintaining a host s IP address identity. We present an end-to-end mobility solution that provides host identity separate from network location. Our solution allows users to maintain communication sessions across network moves while protecting the session from security attacks such as hijacking and man-in-the-middle. We have developed an implementation of the proposed solution using SCTP and presented the specific issues identified during this implementation work. Based on our results, we believe it is reasonable to generalize the end-to-end approach to other transport and session protocols. Our future work includes generalizing the end-to-end model as well as looking at different mobile application environments. ACKNOWLEDGMENT The authors would like to thank Cisco Systems for their support of this research. REFERENCES [1] C. E. Perkins, IP mobility support, RFC 2002, Oct [2] A. C. Snoeren and H. Balakrishna, An end-to-end approach to host mobility, in Proc. 6th International Conference on Mobile Computing and Networking, [3] V. C. Zandy and B. P. Miller, Reliable network connection, in Proc. 8th International Conference on Mobile Computing and Networking, [4] C. Kaufman, R. Perlman, and M. Speciner, Network Security: Private Communication in a Public World, 2nd Edition. Prentice Hall, [5] R. Stewart and Q. Xie, Stream control transmission protocol, RFC 2960, Oct [6] R. Stewart and M. Ramalho. (2002) Stream control transmission protocol dynamic address reconfiguration. Internet draft. [Online]. Available: [7] B. Wellington, Secure domain name system dynamic update, RFC 3007, Nov [8] Public Key Infrastructure (X.509). [Online]. Available: [9] R. Moskowitz. (2001) Host identity payload and protocol. Internet draft. [Online]. Available: hip/draftmoskowitz-hip-05.txt [10] R. Droms, Dynamic host configuration protocol, RFC 2131, Mar [11] R. Stewart and Q. Xie. (2001) SCTP reference implementation [Online]. Available: [12] M. Riegel and M. Tuexen. (2003) Mobile SCTP. Internet draft. [Online]. Available: [13] S. Kent and R. Atkinson, Security architecture for the internet protocol, RFC 2401, Nov [14] T. Dierks and C. Allen, The TLS protocol version 1.0, RFC 2246, Jan