Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "An End-to-End Approach to Host Mobility Alex C. Snoeren and Hari Balakrishnan MIT Laboratory for Computer Science."— Presentation transcript:

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 Kbps Modem Mobile Location Kbps 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: 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

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


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

Similar presentations


Ads by Google