An End-to-End Approach to Host Mobility

1
An End-to-EndApproach to Host Mobility

• By,
• Alex C. Snoeren
• and Prof. Hari Balakrishnan
• MIT Laboratory for Computer Science
• Presented by,
• Parag Namjoshi

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

4
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

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

6
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

7
Migrate Architecture
Correspondent Host
xxx.xxx.xxx.xxx
8
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

9
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

10
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)
11
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)
12
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)
13
TCP StateMachineChanges

• 2 new transitions between existing states
• - and -
• 1 new state handles pathological race condition

appl migrate send SYN (migrate T, R)
recv SYN (migrate T, R) send SYN, ACK
recv SYN (migrate T, R) send SYN, ACK
recv RST
2MSL timeout
MIGRATE_WAIT
14
Experimental Topology
Mobile Location 1
Mobile client initiates a transfer
19.2Kbps Modem
Fixed Basestation
Fixed Server
100Mbps Ethernet
15
Migration Trace
Buffered Packets (old address)
Migrate SYN
16
A Lossy Trace with SACK
Buffered Packets (old address)
ACK w/SACK
Migrate SYN
17
Securing the Migration

• Problem Increased vulnerability to hijacking
• Ingress filtering doesnt 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

18
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

19
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)

20
Limitations

• End hosts cant move simultaneously
• Relatively rare in non ad-hoc environments
• DNS caching
• Todays load-balancing techniques are pushing
  clients to be more agile
• Smooth handoffs not possible.

21
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 Occams razor.)
• Minimal penalty for mobility support
• Obtain optimal unicast packet routing

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

23
Any questions ?
24
Migrate Options
Migrate-Permitted
Migrate

• Request Number
• 64 bit pre-computed token
• SHA-1(Ni,Nj,Key)
• 64 bit signed request
• SHA-1(Ni,Nj,Key,S,ReqNo)

• 8 bit curve domain specifier
• 136 (64) bits of key material

25
A Note on Key Strength

• 200 bits of Elliptic Curve Crypto is a lot
• Cracking a 193 bit ECC key would take 8.521014
  MIPS years Lenstra 99
• Or 1.891012 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