Connection Migration Why How Hari Balakrishnan Networks and
Connection Migration: Why & How Hari Balakrishnan Networks and Mobile Systems Group MIT Lab for Computer Science http: //nms. lcs. mit. edu/ Joint work with Alex Snoeren & Dave Andersen
Anatomy of a connection Some socket on breeze. lcs. mit. edu 18. 31. 0. 83: 5678 www. cnn. com’s HTTP service (port) 207. 25. 71. 23: 80 • Connection defined by IPA: Port. A IPB: Port. B • An IP address does not identify a host; it only identifies a network interface • Is this a good definition of a connection?
Problem #1: Host mobility • Cerf’s comment from Do. D Internet paper: “If a host were to move, its network (and host) addresses would change and this would affect the connection identifiers used by the TCP. This is rather like a problem called "dynamic reconnection" which has plagued network designers since the inception of the ARPANET project in 1968. ” • Two options today for connections: q Terminate and retry q Somehow preserve IP address and continue • “Horizontal” mobility isn’t quite enough. . .
Vertical mobility: Seamless inter-provider movement Regional-Area/ ”wireless cable” Metro-Area Campus-Area Packet Radio In-building & In-room
Problem #2: Unreliable components cnn. com • Individual components rather unreliable • Replicate for improved reliability and availability • What happens to a bound connection on failure or unresponsiveness?
Possible solutions • 1. Force constant IP address for end-point q Mobile IP q Layer-N switches with “Virtual IPs” • 2. Make names routable q All packets identify destination by name, which serves as routing identifier q Intentional naming (late binding), TRIAD • 3. In-band migration q Don’t confound end-point and routing identifiers!
Address constancy: Mobile IP Correspondent Hosts D Foreign Agent (FA) “Detunnel” to D on addr dtmp D Mobile Host D Home Agent Intercepts “Tunnel” to FA pkts d. FA D Temporary address dtmp changes with mobility
Why Mobile IP isn’t right • Requires additional network support and infrastructure (HA, FA, authentication, …) • Triangle routing even for “local” interactions • Many types of mobile applications q Connections that don’t care for seamlessness q Connection initiators q Both initiators and responders • Ingress filtering reverse tunneling too! • Vertical mobility can’t be properly handled • Applications can’t be made aware of mobility
Address constancy: Layer-N switching With work can solve: Local distribution Client But we want: Global distribution
Name-based routing (example) Intentional name [service = camera] [building = NE 43 [room = 510]] Lookup image Intentional name resolvers form an overlay network Late binding: integrate resolution and message routing
What should a connection be? • Between communicating applications, not network interfaces • Should be possible for an application to easily change network interface of connection: q While preserving good unicast routes q Securely • Should not require a priori knowledge of valid network interfaces • Dynamism should not affect semantics or correctness, nor worsen reliability If done right, can solve both problems at once!
Migrate overview Location Query (DNS Lookup) Location Update (Dynamic DNS Update) Name server Connection Initiation Connection Migration Fixed Host Migrating Host foo. bar. edu yyy xxx
Problems • Consistency of name mapping • Correctness q Handling packet losses around time of movement q What if someone else gets your old address? • Security q Connection hijacking q Denial-of-service protection • Semantics q How to maintain semantics of connection sequence across different nodes?
Dynamic name mappings • Zero TTL on A-records for migratable names • Use Dynamic DNS (RFC 2136, 2137) for Internet names • Potential problems: q Race condition between name update and movement • Simply retry! This isn’t a new failure mode q What about old BIND implementations? • Pray that they’ll vanish off the face of the earth q What about extra DNS load? • What load? Ask Akamai!
Migrating a connection • Initiate migration from new network address q Identify previous connection with token, on SYN q Secure token to protect against hijacking q Requires some state machine changes to guarantee correctness • Preserves service model to application • Handles “middle boxes” q Works with most NATs, PEPs, stateful firewalls • Requires changes to transport protocol q Kernel TCP, SCTP, RTP (linked library)
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)
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)
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)
Two correctness issues • SYN uses 1 byte of sequence space; what should SYN ACK value be set to? q Needed to correctly handle lost segments • What if someone else gets your previous address? q Peer TCP will reset connection
Correctness: SYN ACK corresponds to data 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)
Modified TCP State Machine • 2 new transitions between existing states - and • 1 new state handles potential race condition due to rapid readdressing recv: SYN (migrate T, R) send: SYN, ACK re cv : se SYN nd : S (m YN igr , A ate CK T, R ) MIGRATE_WAIT R) te T, a r e ig rat : l m mig p ( ap N SY d: n e s T RS : v c re 2 MSL timeout
Securing the Migration • Problem: Increased vulnerability to hijacking q Ingress filtering (RFC 2827) doesn’t help q Attacker only needs token and sequence space • Solution: Keep the token secret q Negotiate it using Diffie-Hellman exchange (Elliptic -Curve DH) q Use sequence numbers to prevent replay q Complete crypto exchange in SYN handshake • Result: Connections are as secure as standard TCP q Use IPsec or SSH for real security
Semantics of multi-machine migration ACK 9000 7801 -9000 • Sequence spaces across different machines may not have same application-layer semantics
One solution: Soft-state synchronzation foo. mp 3 ISN = I Token = T caddr = Ca cport = Cp preload-tcb Health Monitor ACK 9000 7801 -9000 • Technique for static content (e. g. , file) • Information about mapping between filename and TCP initial sequence periodically disseminated
Implementation • Use application-specific stream mapper to map between sequence space and app (e. g. , HTTP range requests) Client request To client HTTP GET parser/creator HTTP header parser/ Response stripper handler Data relay HTTP range request Backend HTTP Response server • Stream mapper involved in initial connection processing and in re-establishment
Experiment #1: Mobility Mobile client initiates a transfer… Mobile Location 1 19. 2 Kbps Modem Fixed Server 100 Mbps Ethernet Fixed Basestation 19. 2 Kbps Modem …then moves to a new location Mobile Location 2
Migration Trace SYN/ACK Buffered Packets (old address) Migrate SYN
A Lossy Trace with SACK SYN/ACK Buffered Packets (old address) Migrate SYN ACK w/SACK
Experiment #2: Failover works! 0. 000 cl. 1065 > s. A. 8080: . ack 0505 win 31856 ----> (Erroneous) s. A death pronouncement issued 0. 080 s. A. 8080 > cl. 1065: P 0505: 1953(1448) ack 1 win 31856 ----> Successful connection migration to s. B 0. 095 s. B. 1033 > cl. 1065: S 0: 0(0) win 0 <migrate PRELOAD 1> 0. 096 cl. 1065 > s. B. 1033: S 0: 0(0) ack 1953 win 32120 0. 142 s. B. 1033 > cl. 1065: . ack 1 win 32120 ----> Continued data transmission from s. A (Reset by client) 0. 174 s. A. 8080 > cl. 1065: P 0505: 1953(1448) ack 1 win 31856 0. 174 cl. 1065 > s. A. 8080: R 1: 1(0) win 0 ----> Resumed data transmission from s. B 0. 241 s. B. 1033 > cl. 1065: P 1953: 3413(1460) ack 1 win 32120. . .
Oscillations aren’t a problem
Summary • Host mobility and service failover are examples of the same fundamental problem: q Connections must be between applications • The Migrate architecture enables connections to be separated from, and move between, IP addresses • Mobility & service failover are both really end-to-end issues! • Got code?
Networks and Mobile Systems Migrate code for Linux 2. 2 available from: http: //nms. lcs. mit. edu/software/ Migrate project Web page: http: //nms. lcs. mit. edu/projects/migrate/
- Slides: 32