15-849: Hot Topics in Networking

Mobility

Srinivasan Seshan

Key Questions

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

2. 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?

3. 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?

4. Performance & handoff5. 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

connections3

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 address10

Key Questions

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

2. 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?

3. 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?

4. Performance & handoff5. 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

DNS Server

Mobile Hostfoo.bar.edu

Location Query(DNS Lookup)

Connection Initiation

Location Update(Dynamic DNS Update)

Connection Migration

xxx.xxx.xxx.xxxyyy.yyy.yyy.yyy

CorrespondentHost

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 firewalls18

TCP ConnectionMigration1. 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 ConnectionMigration1. 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 ConnectionMigration1. 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) 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 small23

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

26

Mobile IP (MH at Home)

Mobile Host (MH)

Visiting Location

Home

Internet

Correspondent Host (CH)

Packet

27

Mobile IP (MH Moving)

Visiting Location

Home

Internet

Correspondent Host (CH)

Packet

Home Agent (HA) Mobile Host (MH)I am here

28

Mobile IP (MH Away – Foreign Agent)

Visiting Location

Home

Internet

Correspondent Host (CH)

Packet

Home Agent (HA) Foreign Agent (FA)Encapsulated

Mobile Host (MH)

29

Mobile IP (MH Away - Collocated)

Visiting Location

Home

Internet

Correspondent Host (CH)

Packet

Home Agent (HA) Mobile Host (MH)Encapsulated

30

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

Outline

• TCP Migrate

• Mobile IP

• I3

31

Multicast

S1

C1 C2

S2

R RP RR

RR

RP: Rendezvous Point

32

Mobility

HA FA

Home Network

Network 5

5.0.0.1 12.0.0.4

Sender

Mobile Node

5.0.0.333

34

i3: Motivation

• Today’s Internet based on point-to-point abstraction

• Applications need more:• Multicast• Mobility• Anycast

• Existing solutions:• Change IP layer• Overlays

So, what’s the problem?A different solution for each service

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

35

IndirectionEvery problem

in CS …

Only primitiveneeded

i3: Rendezvous Communication

• Packets addressed to identifiers (“names”)• Trigger=(Identifier, IP address): inserted by

receiver

36

Sender Receiver (R)

ID R

trigger

send(ID, data)send(R, data)

Senders decoupled from receivers

37

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

control implemented at end-hosts

i3: Implementation

• Use a Distributed Hash Table • Scalable, self-organizing, robust• Suitable as a substrate for the Internet

38

Sender Receiver (R)

ID R

trigger

send(ID, data)send(R, data)

DHT.put(id)

IP.route(R)

DHT.put(id)

39

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

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

43

Sender(GIF)

Receiver R(JPG)

ID_GIF/JPG S_GIF/JPGID R

send((ID_GIF/JPG,ID), data)

S_GIF/JPG

send(ID, data) send(R, data)

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 “close-by”

i3-servers• Security -- private ids are shared-secrets 44