An End-to-End Approach to Host Mobility Alex C. Snoeren and Hari Balakrishnan MIT Laboratory for Computer Science
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