Transcript An End-to-End Mobility Architecture for the NGI

Migrate: An End-to-end Mobility
Architecture for the NGI
Hari Balakrishnan
Alex Snoeren
Jon Salz Dave Andersen
Frans Kaashoek
MIT Lab for Computer Science
http://nms.lcs.mit.edu/
Networks and Mobile Systems
iNAT Project: Motivation
• Increasing heterogeneity in the Internet
 Nodes:
Mobiles, devices, sensors,...
 Links: Optical, wireless,...
 Services & applications: Web, telepresence,
streaming, remote device control
• Need a general solution for applications to
deal with mobility and discover resources
• Need a general framework for learning about
and adapting to changing network conditions
iNAT Approach
• Intelligent naming and mobility



Resource discovery: Intentional Naming System (INS) using
expressive names and self-configuring name resolver
overlay network
Migrate: Secure connection migration + dynamic naming
(this talk)
Demo this evening: “vertical mobility” between 802.11 &
Bluetooth (Snoeren)
• Adaptive transmission



End-system congestion management and adaptation
framework for the NGI
Congestion Manager software and algorithms
Demo this evening: Adaptive MPEG-4 delivery using CM &
SR-RTP protocol (Feamster & Goraczko)
Migrate
• Mobility support for NGI
• Goals




Handle moving nodes
Handle “vertical mobility” across network technologies
Handle moving applications (across hosts)
Handle disconnections followed by reconnection (on-going;
Snoeren’s dissertation)
• End-to-end mobility system


Architecture leverages dynamic DNS for host location
Secure transport-later connection migration enables
separation of TCP connections from IP addresses
Anatomy of a Connection
Some socket on
nms.lcs.mit.edu
18.31.0.82:5678
www.cnn.com’s
HTTP service (port)
207.25.71.23:80
• Connection defined by IPA:PortAIPB:PortB
• An IP address does not identify a host; it only
identifies a network interface
• Is this a good definition of a connection?
Problem: Host Mobility
• Cerf’s comment from DoD 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.”
• Problem: Changing IP breaks TCP
connections
• Two options today for connections:
 Terminate
and retry
 Somehow preserve IP address and continue
• Another problem: “Horizontal” mobility isn’t
quite enough...
Vertical mobility: Seamless
inter-network movement
Example: cellular telephony
across wide-area cellular,
802.11 and Bluetooth
Motivations:
• Energy
• Capacity
Regional-Area
Metro-Area
Campus-Area
Packet Radio
In-building & In-room
Possible solutions
1. Force constant IP address for end-point


Mobile IP
Layer-N switches with “Virtual IPs”
2. Make names routable


All packets identify destination by name, which serves as
routing identifier
INS approach (late binding), also in TRIAD
3. In-band migration


Don’t confound end-point and routing identifiers!
DNS name identifies end-point; IP address is routing ID
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
dFA
D
Temporary address dtmp
changes with mobility
The Case Against Mobile IP
• Requires additional network support and
infrastructure (HA, FA, authentication,…)
• Triangle routing even for “local” interactions
• Many types of mobile applications



Connections that don’t care for seamlessness
Connection initiators
Both initiators and responders
• Ingress filtering requires reverse tunneling too
• Vertical mobility can’t be properly handled in
application-specific manner
• Applications can’t be made aware of mobility
What Should a Connection Be?
• Between communicating applications, not network
interfaces
• Should be possible for an application to easily
change network interface of connection:


While preserving good unicast routes
Securely
• Should not require a priori knowledge of valid
network interfaces
• Dynamism should not affect semantics or
correctness, nor worsen reliability (or performance)
Migrate Overview
Location Query
(DNS Lookup)
Location Update
(Dynamic DNS Update)
Name server
Connection Initiation
Fixed
Host
Connection Migration
Secured using Diffie-Hellman
exchange (with SYN exch)
Migrating Host
foo.bar.edu
yyy.yyy.yyy.yyy
xxx.xxx.xxx.xxx
Problems
• Consistency of name mapping
• Correctness
 Handling
packet losses around time of movement
 What if someone else gets your old address?
• Security
 Connection
hijacking
 Denial-of-service protection
• Semantics
 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:


Race condition between name update and movement
• Simply retry! This isn’t a new failure mode
What about extra DNS load?
• Turns out low-TTL A-record appear not to affect DNS
scalability much
• (See Jung, Sit, Balakrishnan, Morris; “DNS Performance
and the Effectiveness of Caching,” ACM SIGCOMM
Internet Measurement Workshop, Nov. 2001.)
Migrating a Connection
• Initiate migration from new network address
 Identify
previous connection with token, on SYN
 Secure token to protect against hijacking
 Requires some state machine changes to
guarantee correctness
• Preserves service model to application
• Handles “middle boxes”
 Works
with most NATs, PEPs, stateful firewalls
• Requires changes to transport protocol
 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)
• 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
Modified
TCP State
Machine
MIGRATE_WAIT
2MSL timeout
Securing the Migration
• Problem: Increased vulnerability to hijacking


Ingress filtering (RFC 2827) doesn’t help
Attacker only needs token and sequence space
• Solution: Keep the token secret




Negotiate it using Diffie-Hellman exchange (Elliptic-Curve
DH)
Use sequence numbers to prevent replay
Crypto exchange completed in SYN handshake
Implemented in a new TCP option
• Result: Connections are as secure as standard TCP
Migration Trace with SACK
SYN/ACK
Buffered
Packets
(old address)
ACK
w/SACK
Migrate SYN
Summary
• The Migrate architecture enables end-to-end
connections to be separated from, and move
between, IP addresses
• Handles host and application mobility in an end-toend fashion
• Exports API for mobility adaptation
• Current work: handling disconnections
• iNAT demo this evening (Bluetooth+802.11 end-toend migration)
• Got code?
Networks and Mobile Systems
Migrate code for Linux 2.2 available from:
http://nms.lcs.mit.edu/software/
Migrate project Web page (has code, papers):
http://nms.lcs.mit.edu/migrate/