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 & handoff 5.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 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.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 & handoff 5.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 Host foo.bar.edu Location Query (DNS Lookup) Connection Initiation Location Update (Dynamic DNS Update) Connection Migration xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy Correspondent Host 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 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 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

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 S1S1 C1C1 C2C2 S2S2 RRPRR RR RP: Rendezvous Point 32

Mobility HAFA Home Network Network Sender Mobile Node

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 Indirection Every problem in CS … Only primitive needed

i3: Rendezvous Communication Packets addressed to identifiers (“names”) Trigger=(Identifier, IP address): inserted by receiver 36 SenderReceiver (R) IDR 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 SenderReceiver (R) IDR 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 R i that inserts the trigger (id, R i ) 41

Generalization: Identifier Stack Stack of identifiers i3 routes packet through these identifiers Receivers trigger maps id to Sender can also specify id-stack in packet Mechanism: first id used to match trigger rest added to the RHS of trigger recursively continued 42

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/JPG ID 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