An End-to-End Approach to Host Mobility By, Alex C. Snoeren and Prof. Hari Balakrishnan MIT Laboratory for Computer Science Presented by, Parag Namjoshi

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

Schizophrenic IP addresses. IP addresses can be considered as being semantically equivalent to FQDNs. They are used to keep track of internal state in upper layers. (e.g. TCP, NFS) The Contradiction  On one hand, mobile host needs a stable IP address so that it can be identified (and reached) by other hosts.  On the other hand stable address implies stable routing; thus no mobility.

The competition… Mobility-aware routing (Mobile IP)  Completely transparent to end hosts  Requires a home agent  Often inefficient packet routes Endpoint ID (EID) schemes (Huitema)  Retains standard unicast routes, but…  Yet another level of indirection  Also requires changes to transport layer

Lets talk about the competition… Mobile IP  All traffic to a mobile host may travel via the home agent. The necessity of a home agent can be a significant burden.  Mobile IP requires that the home address continue to be allocated to the mobile host. If the available address space is small, such a restriction may make re-addressing prohibitive.  Ingress filtering may cause “reverse tunneling”.

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

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

TCP connection migration 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)

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

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 Smooth handoffs not possible.

Benefits Exposes address changes to end hosts  Agile applications can adapt to changing conditions for better performance (Invoke end-to- end argument.)  Mobility per connection, not just per host Preserves IP addressing semantics  No changes to the routing infrastructure  No additional entities like home agent & foreign agent come into picture. (Invoke Occam’s razor.) Minimal penalty for mobility support  Obtain optimal unicast packet routing

Conclusion. The architecture is compatible with the current routing infrastructure. Does not add additional levels of indirection. Does not change TCP headers, instead using a new TCP option. End hosts are notified of the mobility, upper layers can use this knowledge. May even be deployed.May even be deployed.

Any questions ?

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