An End-to-End Approach to Host Mobility Alex C. Snoeren and Hari Balakrishnan MIT Laboratory for Computer Science
A Moving Target Internet hosts are increasingly mobile Changing physical media or attachment points often requires changing IP address Mobile hosts need to remain locatable Packets are routed by IP address Preserve transport service model Connection-oriented protocols provide reliable end-to-end connectivity
Previous Approaches to Mobility Mobility-aware routing (Mobile IP) Completely transparent to end hosts Requires a home agent Often inefficient packet routes Endpoint ID (EID) schemes Retains standard unicast routes, but… Yet another level of indirection Also requires changes to transport layer
The Migrate Approach Locate hosts through existing DNS Secure, dynamic DNS is currently deployed and widely available (RFC 2137) Maintains standard IP addressing model IP address are topological addresses, not Ids Fundamental to Internet scaling properties Ensure seamless connectivity through connection migration Notify only the current set of correspondent hosts Follows from the end-to-end argument
Migrate Architecture DNS Server Mobile Host foo.bar.edu Location Query (DNS Lookup) Connection Initiation Location Update (Dynamic DNS Update) Connection Migration xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy Correspondent Host
Previous Migration Schemes Multi-homed schemes Require new transport protocols (SCTP) Often require a priori knowledge of possible set of IP addresses Connection-ID schemes May not preserve transport semantics May require a per-packet overhead Many security and DoS issues
Our Migration Approach Join together two separate connections By unifying the context space Reference previous connection with token Requires minimal transport state machine changes Preserve semantics, both internal and external to the connection Implicit address assignment Works with NATs, PEPs, all middle boxes
An Application: TCP Provide special Migrate option Sent on SYN packets of new connection Indicates new connection should be joined to a previous one Use previous sequence space Works with SACK, FACK, Snoop… Preserve three-way SYN handshake Works with statefull firewalls
TCP Connection Migration 1.Initial SYN 2.SYN/ACK 3.ACK (with data) 4.Normal data transfer 5.Migrate SYN 6.Migrate SYN/ACK 7.ACK (with data)
TCP Connection Migration 1.Initial SYN 2.SYN/ACK 3.ACK (with data) 4.Normal data transfer 5.Migrate SYN 6.Migrate SYN/ACK 7.ACK (with data)
TCP Connection Migration 1.Initial SYN 2.SYN/ACK 3.ACK (with data) 4.Normal data transfer 5.Migrate SYN 6.Migrate SYN/ACK 7.ACK (with data) (Note typo in proceedings)
TCP State Machine Changes MIGRATE_WAIT 2MSL timeout recv: SYN (migrate T, R) send: SYN, ACK recv: RST appl: migrate send: SYN (migrate T, R) recv: SYN (migrate T, R) send: SYN, ACK 2 new transitions between existing states - and - 1 new state handles pathological race condition
Experimental Topology Fixed Basestation Fixed Server 100Mbps Ethernet Mobile Location Kbps Modem Mobile Location Kbps Modem …then moves to a new location Mobile client initiates a transfer…
Migration Trace SYN/ACK Buffered Packets (old address) Migrate SYN
A Lossy Trace with SACK SYN/ACK Migrate SYN Buffered Packets (old address) ACK w/SACK
Securing the Migration Problem: Increased vulnerability to hijacking Ingress filtering doesn’t help Attacker only needs token and sequence space Solution: Keep the token secret Negotiate it using Diffie-Hellman exchange Use sequence numbers to prevent replay Resulting connections are as secure as standard TCP (not very) Use IPsec or SSH for real security
Preventing DoS Attacks Migrate SYNs are heavyweight Require real computation (SHA-1 hash) Thus Migrate SYN floods are more dangerous than standard SYN floods A pre-computable token guards against frivolous computation Refreshing tokens after each successful migration makes replay window very small
Benefits & Limitations Exposes address changes to end hosts Agile applications can adapt to changing conditions for better performance Mobility per connection, not just per host Preserves IP addressing semantics No changes to the routing infrastructure Minimal penalty for mobility support Obtain optimal unicast packet routing End hosts can’t move “simultaneously” Relatively rare in non ad-hoc environments
Software now available on the web: Networks and Mobile Systems
Implementation Details Patched Linux kernel to support TCP connection migration Processes can migrate open connections using ioctl() system calls Daemon/users can migrate existing connections through the /proc file system Bind 8 provides dynamic updates User-land DNS update script
Continuing Research Host mobility End-to-End support for disconnectivity Connection migration Other transport protocols (RTP) Load balancing/fast fail-over techniques
Performance Implications Migration takes a round-trip time No dependence on previous location or “home” location Congestion state is tricky In general, restart from scratch (slow-start) However, if paths are similar, could trigger fast retransmit (Cáceres & Iftode ’95) Congestion state may be available elsewhere (Balakrishnan et al. ’99)
Limitations End hosts can’t move “simultaneously” Relatively rare in non ad-hoc environments DNS caching Today’s load-balancing techniques are pushing clients to be more agile
Migrate Options Kind Token Token (cont) Request Request (cont) LenReqNo ECDH Key Material (cont) KindLenCurveECDH ECDH Key Material (cont) Migrate-PermittedMigrate 8 bit curve domain specifier 136 (+64) bits of key material Request Number 64 bit pre-computed token SHA-1(N i,N j,Key) 64 bit signed request SHA-1(N i,N j,Key,S,ReqNo)
A Note on Key Strength 200 bits of Elliptic Curve Crypto is a lot Cracking a 193 bit ECC key would take 8.52*10 14 MIPS years [Lenstra ’99] Or 1.89*10 12 years on an Intel 450Mhz PII TCP hijacking with IP spoofing is easier TCP alone is inherently insecure Real security requires end host authentication and strong session keys