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

128.32.xxx.xxx is located in Berkeley

• Network location tied to network layer identifier

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

Our 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

Sender Receiver (R)

id R

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

SenderReceiver

(R1)id R1

send(id,data) send(R1, data)

Mobility

• Host just needs to update its trigger as moves from one subnet to another

Sender

Receiver(R2)

id R2

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)id R1

send(id,data) send(R1, data)

Receiver (R2)

id R2

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 Ri in the anycast group inserts IDs

with the same prefix p and a different suffix si

Sender

Receiver (R1)p|s1 R1send(p|a,data)

Receiver (R2)p|s2 R2

p|s3 R3

Receiver (R3)

send(R1,data)

Service Composition

• Use a stack of IDs to encode the successions of operations to be performed on data

• Similar to the idea of delegation in DOA

Sender(MPEG)

Receiver R(JPEG)

id_MPEG/JPEG S_MPEG/JPEGid 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 35

3

7

20

35

41

37 R

3

7

20

3541

37 R

S

R

trigger(37,R)

send(37, data)

send(R, data)

Chord circle

S

R

02m-1

Optimizations

• Sender/receiver caches node that maps a specific ID• Subsequent packets are sent via one i3 node

3

7

20

3541

37 R

S

Rsend(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))

idpublic H2

H1id1private id2private H2

H1 H2send(idpublic, id1private) send(H2, id1private)

send(id1private, id2private)

send(id2private, 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 an hierarchy of trigger of bounded degree

R2

R1

R4R3

g R2

g R1

gx

x R4

x R3

(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

S1

1010 0101 S2

1010 1010 S3

1010 1101 S4

S1

S2

S3

S4

A

B

send(1010 0110,data)

send(1010 1110,data)

1010 0010

Example 4: Proximity

• Suffixes of trigger and packet IDs encode the server and client locations

1000 0010 S1

1000 1010 S21000 1101 S3

S1

S2S3

send(1000 0011,data)

Security

• i3 does is not “worse” than today’s Internet

• Actually, show that i3 can provide better protection against DoS attacks

Eavesdropping

SenderReceiver (R)id R

send(id,data) send(R, data)

Attacker (A)

id A

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)

id3

id3

id3

V Attacker id2 id2

id2

id2

id1 id3

Solution 1: Stop the Attack

• If a receiver is attacked via a private trigger just drop that trigger

• In general shutting down a compromised service could save other services that share the same incoming link– Not true in today’s Internet

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)t S

id A

DoS-Filter (A)

idc C

Client (C)

Take-home lessons

• The idea of “indirection”• Rendezvous based communication

abstraction• DHTs and flat name lookups enable new

Internet architectures