Transcript pptx

15-849: Hot Topics in Networking
Mobility
Srinivasan Seshan
Key Questions
1.
2.
3.
4.
5.
Mobility vs. Portability -- Mobile IP tries to ensure that your
TCP connections and connectivity survive as we move from
network to network. Do we really need this or just need
the ability to reconnect anywhere (i.e. portability)
Layers again - What layer should we address mobility network, naming, transport, "link"/local network (i.e. within
a bridged LAN/cellular network)? Do we address portability
at a different layer?
Incremental support -- Should we force all nodes in the
Internet to add features to support mobility or do we place
the burden on the mobile hosts/mobile networks to "fit in"
with the rest of the network?
Performance & handoff
Location privacy
2
How to Handle Mobile Nodes?
• Dynamic Host Configuration (DHCP)
• Host gets new IP address in new locations
• Problems
• Host does not have constant name/address  how do
others contact host
• What happens to active transport connections?
• Naming
• Use DHCP and update name-address mapping
whenever host changes address
• Fixes contact problem but not broken transport
connections
3
Handling Mobile Nodes (Transport)
• TCP currently uses 4 tuple to describe
connection
• <Src Addr, Src port, Dst addr, Dst port>
• Modify TCP to allow peer’s address to be
changed during connection
• Security issues
• Can someone easily hijack connection?
• Difficult deployment  both ends must
support mobility
4
Handling Mobile Node
• Link layer mobility
• Learning bridges can handle mobility  this is
how it is handled at CMU
• Encapsulated PPP (PPTP)  Have mobile host act
like he is connected to original LAN
• Works for IP AND other network protocols
• Multicast
• Solves similar problem  how to route packets to
different sets of hosts at different times
• Can’t we just reuse same solutions?
• Don’t really have solution for multicast either!
5
Handling Mobile Nodes (Routing)
• Allow mobile node to keep same address and
name
• How do we deliver IP packets when the endpoint
moves?
• Why can’t we just have nodes advertise route to their
address?
• What about packets from the mobile host?
• Routing not a problem
• What source address on packet?
• Key design considerations
• Scale
• Incremental deployment
6
Basic Solution to Mobile Routing
• Same as other problems in Computer
Science
• Add a level of indirection
• Keep some part of the network informed
about current location
• Need technique to route packets through this
location (interception)
• Need to forward packets from this location
to mobile host (delivery)
7
Interception
• Somewhere along normal forwarding path
•
•
•
•
At source
Any router along path
Router to home network
Machine on home network (masquerading as
mobile host)
• Clever tricks to force packet to particular
destination
• “Mobile subnet” – assign mobiles a special
address range and have special node advertise
route
8
Delivery
• Need to get packet to mobile’s current
location
• Tunnels
• Tunnel endpoint = current location
• Tunnel contents = original packets
• Source routing
• Loose source route through mobile current
location
• Network address translation (NAT)
• What about packets from the mobile host?
9
Mobile IP (RFC 2290)
• Interception
• Typically home agent – hosts on home network
• Delivery
• Typically IP-in-IP tunneling
• Endpoint – either temporary mobile address or
foreign agent
• Terminology
• Mobile host (MH), correspondent host (CH), home
agent (HA), foreign agent (FA)
• Care-of-address, home address
10
Key Questions
1.
2.
3.
4.
5.
Mobility vs. Portability -- Mobile IP tries to ensure that your
TCP connections and connectivity survive as we move from
network to network. Do we really need this or just need
the ability to reconnect anywhere (i.e. portability)
Layers again - What layer should we address mobility network, naming, transport, "link"/local network (i.e. within
a bridged LAN/cellular network)? Do we address portability
at a different layer?
Incremental support -- Should we force all nodes in the
Internet to add features to support mobility or do we place
the burden on the mobile hosts/mobile networks to "fit in"
with the rest of the network?
Performance & handoff
Location privacy
11
Outline
• TCP Migrate
• Mobile IP
• I3
12
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
13
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
14
Migrate Architecture
Location Query
(DNS Lookup)
Location Update
(Dynamic DNS Update)
DNS Server
Connection Initiation
Connection Migration
Correspondent
Host
Mobile Host
foo.bar.edu
yyy.yyy.yyy.yyy
xxx.xxx.xxx.xxx
15
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
16
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
17
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
18
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)
19
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)
20
TCP
Connection
Migration
1. Initial SYN
2. SYN/ACK
3. ACK (with data)
4. Normal data transfer
5. Migrate SYN
6. Migrate SYN/ACK
(Note typo in proceedings)
7. ACK (with data)
21
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
22
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
23
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
24
Outline
• TCP Migrate
• Mobile IP
• I3
25
Mobile IP (MH at Home)
Packet
Correspondent Host (CH)
Internet
Home
Mobile Host (MH)
Visiting
Location
26
Mobile IP (MH Moving)
Packet
Correspondent Host (CH)
Internet
Visiting
Location
Home
Home Agent (HA)
I am here
Mobile Host (MH)
27
Mobile IP (MH Away – Foreign
Agent)
Packet
Correspondent Host (CH)
Mobile Host (MH)
Internet
Visiting
Location
Home
Encapsulated
Home Agent (HA)
Foreign Agent (FA)
28
Mobile IP (MH Away - Collocated)
Packet
Correspondent Host (CH)
Internet
Visiting
Location
Home
Encapsulated
Home Agent (HA)
Mobile Host (MH)
29
Other Mobile IP Issues
• Route optimality
• Resulting paths can be sub-optimal
• Can be improved with route optimization
• Unsolicited binding cache update to sender
• Authentication
• Registration messages
• Binding cache updates
• Must send updates across network
• Handoffs can be slow
• Problems with basic solution
• Triangle routing
• Reverse path check for security
30
Outline
• TCP Migrate
• Mobile IP
• I3
31
Multicast
S1
S2
R
RP
R
R
R
C1
C2
R
RP: Rendezvous
Point
32
Mobility
Sender
HA
FA
5.0.0.1
12.0.0.4
Home Network
Network 5
Mobile
Node
5.0.0.3
33
i3: Motivation
• Today’s Internet based on point-to-point
abstraction
• Applications need more:
• Multicast
• Mobility
• Anycast
So, what’s the problem?
A different solution for each service
• Existing solutions:
• Change IP layer
• Overlays
34
The i3 solution
• Solution:
• Add an indirection layer on top of IP
• Implement using overlay networks
• Solution Components:
• Naming using “identifiers”
• Subscriptions using “triggers”
• DHT as the gluing substrate
Only primitive
needed
Indirection
Every problem
in CS … 
35
i3: Rendezvous Communication
• Packets addressed to identifiers (“names”)
• Trigger=(Identifier, IP address): inserted by
receiver
send(R, data)
send(ID, data)
Sender
trigger
ID
Receiver (R)
R
Senders decoupled from receivers
36
i3: Service Model
• API
• sendPacket(id, p);
• insertTrigger(id, addr);
• removeTrigger(id, addr); //
optional
• Best-effort service model (like IP)
• Triggers periodically refreshed by end-hosts
• Reliability, congestion control, and flowcontrol implemented at end-hosts
37
i3: Implementation
• Use a Distributed Hash Table
• Scalable, self-organizing, robust
• Suitable as a substrate for the Internet
IP.route(R)
send(R, data)
send(ID, data)
Sender
trigger
ID
DHT.put(id)
Receiver (R)
R
DHT.put(id)
38
Mobility and Multicast
• Mobility supported naturally
• End-host inserts trigger with new IP
address  transparent to sender
• Robust and supports location privacy
• Multicast
• All receivers insert triggers under same ID
• Sender uses that ID for sending
• Can optimize tree construction to balance
load
39
Mobility
• The change of the receiver’s address
• from R to R’ is transparent to the
sender
40
Multicast
• Every packet (id, data) is forwarded to each
receiver Ri that inserts the trigger (id, Ri)
41
Service Composition
• Receiver mediated: R sets up chain and
passes id_gif/jpg to sender: sender oblivious
• Sender-mediated: S can include (id_gif/jpg, ID)
in his packet: receiver oblivious
S_GIF/JPG
send((ID_GIF/JPG,ID), data)
Sender
(GIF)
ID_GIF/JPG
send(R, data)
send(ID, data)
S_GIF/JPG
ID
R
Receiver R
(JPG)
43
Public, Private Triggers
• Servers publish their public ids: e.g.,
via DNS
• Clients contact server using public ids,
and negotiate private ids used
thereafter
• Useful:
• Efficiency -- private ids chosen on “closeby” i3-servers
• Security -- private ids are shared-secrets
44