1 / 19

An End-to-End Approach to Host Mobility

An End-to-End Approach 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

katoka
Download Presentation

An End-to-End Approach to Host Mobility

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An End-to-EndApproach 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. Location Query (DNS Lookup) Location Update (Dynamic DNS Update) DNS Server Connection Initiation Connection Migration Mobile Host foo.bar.edu yyy.yyy.yyy.yyy Migrate Architecture Correspondent Host xxx.xxx.xxx.xxx

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

  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) (Note typo in proceedings)

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

  13. 19.2Kbps Modem Mobile Location 2 …then moves to a new location Experimental Topology Mobile Location 1 Mobile client initiates a transfer… 19.2Kbps Modem Fixed Server Fixed Basestation 100Mbps Ethernet

  14. SYN/ACK Migration Trace Buffered Packets (old address) Migrate SYN

  15. SYN/ACK A Lossy Trace with SACK Buffered Packets (old address) ACK w/SACK Migrate SYN

  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: http://nms.lcs.mit.edu/projects/migrate Networks and MobileSystems

More Related