Internet Indirection Infrastructure Slides thanks to Ion Stoica

Motivations Today’s Internet is built around a unicast point-to-point communication abstraction: –Send packet “p” from host “A” to host “B” This abstraction allows Internet to be highly scalable and efficient, but… … not appropriate for applications that require other communications primitives: –Multicast –Anycast –Mobility –…

Why? Point-to-point communication abstraction implicitly assumes that there is one sender and one receiver, and that they are placed at fixed and well-known locations –E.g., a host identified by the IP address xxx.xxx is located in Berkeley Network location tied to network layer identifier - Exception: VPN (tunneled through location)

IP Solutions Extend IP to support new communication primitives, e.g., –Mobile IP –IP multicast –IP anycast Disadvantages: –Difficult to implement while maintaining Internet’s scalability (e.g., multicast) –Require community wide consensus -- hard to achieve in practice

Application Level Solutions Implement the required functionality at the application level, e.g., –Application level multicast –Application level mobility Disadvantages: –Efficiency hard to achieve –Redundancy: Each application implements the same functionality over and over again –No synergy: each application implements usually only one service, services hard to combine

Key Observation All previous solutions use a simple but powerful technique: indirection –Assume a logical or physical indirection point interposed between sender(s) and receiver(s) Examples: –IP multicast assumes a logical indirection point: the IP multicast address –Mobile IP assumes a physical indirection point: the home agent

Proposed Solution: Internet Indirection Infrastructure (i3) Add an efficient indirection layer on top of IP Use an overlay network to implement it –Incrementally deployable; no need to change IP IP router i3 node

i3 Communication Abstraction Provide a rendezvous based communication abstraction (instead of point-to-point) –Each packet is associated an identifier id –To receive a packet with identifier id, receiver R maintains a trigger ( id, R) into the overlay network SenderReceiver (R) idR trigger send(id, data) send(R, data)

Service Model API –sendPacket( p ); –insertTrigger( t ); –removeTrigger( t ) Best-effort service model (like IP) Triggers are periodically refreshed by end- hosts – i.e. soft state at i3 servers Reliability, congestion control, and flow- control implemented at end-hosts

The Promise Provide support for –Mobility –Multicast –Anycast –Service composition

Mobility Host just needs to update its trigger as it moves from one subnet to another Sender Receiver (R1) idR1 send(id,data) send(R1, data)

Mobility Host just needs to update its trigger as moves from one subnet to another Sender Receiver (R2) idR2 send(id,data) send(R2, data)

Multicast Unifies multicast and unicast abstractions –Multicast: receivers insert triggers with the same identifier An application can dynamically switch between multicast and unicast Sender Receiver (R1)idR1 send(id,data) send(R1, data) Receiver (R2) idR2 send(R2, data)

Anycast Generalize the matching scheme used to forward a packet –Until now we assumed exact matching Next, we assume: –Longest prefix matching (LPM) using a prefix larger than a predefined constant l to avoid collisions

Anycast (cont’d) Anycast is simply a byproduct of the new matching scheme, e.g., –Each receiver R i in the anycast group inserts IDs with the same prefix p and a different suffix s i Sender Receiver (R1) p|s 1 R1 send(p|a,data) Receiver (R2) p|s 2 R2 p|s 3 R3 Receiver (R3) send(R1,data)

Service Composition Use a stack of IDs to encode the successions of operations to be performed on data Sender (MPEG) Receiver R (JPEG) id_ MPEG/JPEG S_ MPEG/JPEG id R send((id_ MPEG/JPEG,id), data) S_ MPEG/JPEG send(id, data) send(R, data)

Service Composition (cont’d) Receiver can also specify the operations to be performed on data Receiver R (JPEG) id_ MPEG/JPEG S_ MPEG/JPEG id (id_ MPEG/JPEG, R) send(id, data) S_ MPEG/JPEG Sender (MPEG) send((id _MPEG/JPEG, R), data) send(R, data)

Quick Implementation Overview i3 is implemented on top of Chord –But can easily use CAN, Pastry, or Tapestry Each trigger t = ( id, R ) is stored on the node responsible for id Use Chord recursive routing to find best matching trigger for packet p = ( id, data )

Routing Example R inserts trigger t = (37, R) ; S sends packet p = (37, data) An end-host needs to know only one i3 node to use i3 –E.g., S knows node 3, R knows node R R S R trigger(37,R) send(37, data) send(R, data) Chord circle S R 0 2 m-1

Optimizations Sender/receiver caches node that maps a specific ID –Similar to Seattle resolver caching Subsequent packets are sent via one i3 node R S R send(R, data) send(37, data) cache node “41”

Optimizations (cont’d) Address “triangular routing problem”: Public triggers for initial rendezvous Private triggers for efficient routing: Choose private trigger IDs to map onto nearby nodes –Sample identifier space (done off-line), or –Assume end-hosts know the ID of a close by node Note: only applications are aware of private/public distinction; i3 isn’t

Optimizations (cont’d) H1 wants to contact H2 –H1 knows H2’s public trigger (e.g., Hash(cnn.com)) id public H2 H1 id1 private id2 private H2 H1 H2 send(id public, id1 private ) send(H2, id1 private ) send(id1 private, id2 private ) send(id2 private, data) send(H2, data)

Examples of Using i3 Heterogeneous multicast Scalable Multicast Load balancing Proximity

Example 1: Heterogeneous Multicast Sender not aware of transformations Receiver R1 (JPEG) id_ MPEG/JPEG S_ MPEG/JPEG id (id_ MPEG/JPEG, R1) send(id, data) S_ MPEG/JPEG Sender (MPEG) send((id _MPEG/JPEG, R1), data) send(R1, data) id R2 Receiver R2 (MPEG) send(R2, data)

Example 2: Scalable Multicast i3 doesn’t provide direct support for scalable multicast –Triggers with same identifier are mapped onto the same i3 node Solution: have end-hosts build a hierarchy of trigger of bounded degree R2R2 R1R1 R4R4 R3R3 g R 2 g R 1 gxgx x R 4 x R 3 (g, data) (x, data)

Example 3: Load Balancing Servers insert triggers with IDs that have random suffixes Clients send packets with IDs that have random suffixes S S S S4 S1 S2 S3 S4 A B send( ,data) send( ,data)

Example 4: Proximity Suffixes of trigger and packet IDs encode the server and client locations S S S3 S1 S2 S3 send( ,data)

Security i3 does is not “worse” than today’s Internet Actually, show that i3 can provide better protection against DoS attacks

Eavesdropping Sender Receiver (R) idR send(id,data) send(R, data) Attacker (A) idA

Solution Random private triggers Periodically change private triggers Multiple private triggers per flow Public key cryptography to exchange private triggers

Trigger hijacking Malicious user can isolate a host by removing its public trigger Solution: Another level of indirection Receiver R can insert two triggers (id, x), (x, R) instead of (id, R) Sender (S) Receiver (R) x R id x

DOS attack on end hosts Victim (V) id 3 V Attacker id 2 id 1 id 3

Solution 1: Stop the Attack If a receiver is attacked via a private trigger just drop that trigger

Solution 2: Third party firewall Use a DoS-filter server A more powerful than S that maintains S’ public trigger on its behalf A sends puzzles to client C before establishing connection between C and S Server (S) tS id A DoS-Filter (A) id c C Client (C)

Take-home lessons The idea of “indirection” Rendezvous based communication abstraction DHTs and flat name lookups enable new Internet architectures Performance trade-off vs. simplifying abstractions

Conclusions Could be useful as a multicast and mobility overlay Anycast gains are questionable due to the indirection latency Not a good argument for using in unicast scenarios Incremental deployment, without changing underlying IP implementation could benefit particular application classes Essentially a publish-subscribe architecture on top of Chord.