An End-to-EndApproach 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 Hostfoo.bar.edu

Location Query(DNS Lookup)

Connection Initiation

Location Update(Dynamic DNS Update)

Connection Migration

xxx.xxx.xxx.xxxyyy.yyy.yyy.yyy

CorrespondentHost

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 ConnectionMigration

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 ConnectionMigration

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 ConnectionMigration

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 StateMachineChanges

MIGRATE_WAIT2MSL timeout

recv

: SY

N (

mig

rate

T, R

)se

nd: S

YN

, AC

K

recv:

RST

appl:

migrate

send:

SYN (migr

ate 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

FixedBasestation

FixedServer

100Mbps Ethernet

MobileLocation 1

19.2KbpsModem

MobileLocation 2

19.2KbpsModem

…then moves to a new location

Mobile client initiates a transfer…

Migration Trace

SYN/ACK

BufferedPackets

(old address)

Migrate SYN

A Lossy Trace with SACK

SYN/ACK

Migrate SYN

BufferedPackets

(old address)

ACKw/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:

http://nms.lcs.mit.edu/projects/migrate

Networks and Mobile Systems