Upload
telepresence
View
377
Download
1
Tags:
Embed Size (px)
Citation preview
Migrate: An End-to-end Mobility Architecture for the NGI
Hari BalakrishnanAlex Snoeren Jon Salz Dave Andersen
Frans Kaashoek
MIT Lab for Computer Sciencehttp://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
• Connection defined by IPA:PortAIPB:PortB
• An IP address does not identify a host; it only identifies a network interface
• Is this a good definition of a connection?
Some socket onnms.lcs.mit.edu
www.cnn.com’sHTTP service (port)
18.31.0.82:5678 207.25.71.23:80
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
In-building & In-room
Campus-Area Packet Radio
Metro-Area
Regional-AreaExample: cellular telephonyacross wide-area cellular,802.11 and BluetoothMotivations:• Energy• Capacity
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
Home AgentIntercepts
pkts
Address Constancy: Mobile IP
Foreign Agent (FA)
Mobile Host
Correspondent Hosts
Temporary address dtmp
changes with mobility
D
“Tunnel” to FA
D
dFA
“Detunnel” to Don addr dtmp
D
D
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
Name server
Migrating Hostfoo.bar.edu
Location Query(DNS Lookup)
Connection Initiation
Location Update(Dynamic DNS Update)
Connection MigrationSecured using Diffie-Hellman
exchange (with SYN exch)
xxx.xxx.xxx.xxxyyy.yyy.yyy.yyy
FixedHost
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 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)
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)
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)
Modified TCP State Machine
MIGRATE_WAIT2MSL timeout
recv
: SY
N (
mig
rate
T, R
)se
nd: S
YN
, AC
K
recv:
RST
appl:
migrate
send:
SYN (migr
ate T, R
)recv: SYN (migrate T, R)
send: SYN, ACK
• 2 new transitions between existing states
- and -• 1 new state
handles potential race condition due to rapid readdressing
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
Migrate SYN
BufferedPackets
(old address)
ACKw/SACK
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-to-end fashion
• Exports API for mobility adaptation• Current work: handling disconnections• iNAT demo this evening (Bluetooth+802.11 end-to-
end migration)• Got code?
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/
Networks and Mobile Systems