1. An End-to-End Approach to Host Mobility Alex C. Snoeren and Hari Balakrishnan MIT Laboratory for Computer Science

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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)

10. 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)

11. 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)

12. 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

13. Experimental Topology Fixed Basestation Fixed Server 100Mbps Ethernet Mobile Location 1 19.2Kbps Modem Mobile Location 2 19.2Kbps Modem …then moves to a new location Mobile client initiates a transfer…

14. Migration Trace SYN/ACK Buffered Packets (old address) Migrate SYN

15. A Lossy Trace with SACK SYN/ACK Migrate SYN Buffered Packets (old address) ACK w/SACK

16. 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

17. 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

18. 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

19. Software now available on the web: http://nms.lcs.mit.edu/projects/migrate Networks and Mobile Systems

20. 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

21. Continuing Research Host mobility  End-to-End support for disconnectivity Connection migration  Other transport protocols (RTP)  Load balancing/fast fail-over techniques http://nms.lcs.mit.edu/projects/migrate

22. 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)

23. 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

24. 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)

25. 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