Internet Indirection
Infrastructure
Modified version of
Ion Stoica’s talk
at ODU
Nov 14, 2005
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
…
2
Why?
• Point-to-point communication  implicitly
assumes 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
3
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
4
Application Level Solutions
• Implement the required functionality at the
application level, e.g.,
– Application level multicast (e.g., Narada, Overcast,
Scattercast…)
– 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
5
Internet Indirection Infrastructure (i3)
• 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
data id
Sender
Receiver (R)
data R
id R
trigger
6
Service Model
• API
– sendPacket(p);
– insertTrigger(t);
– removeTrigger(t) // optional
• Best-effort service model (like IP)
• Triggers periodically refreshed by end-hosts
• ID length: 256 bits
7
Mobility
• Host just needs to update its trigger as it moves
from one subnet to another
Sender
id R2
R1
Receiver
(R1)
Receiver
(R2)
8
Multicast
• Receivers insert triggers with same identifier
• Can dynamically switch between multicast and
unicast
data id
Sender
data R1
id R1
Receiver (R1)
id R2
data R2
Receiver (R2)
9
Anycast
• Use longest prefix matching instead of exact
matching
– Prefix p: anycast group identifier
– Suffix si: encode application semantics, e.g., location
data p|a
Sender
data R1
p|s1 R1
p|s2 R2
Receiver (R1)
Receiver (R2)
p|s3 R3
Receiver (R3)
10
Service Composition: Sender Initiated
• Use a stack of IDs to encode sequence of
operations to be performed on data path
• Advantages
– Don’t need to configure path
– Load balancing and robustness easy to achieve
Transcoder (T)
data idT,id
Sender
data id
data T,id
idT T
data R
id R
Receiver (R)
11
Service Composition: Receiver
Initiated
• Receiver can also specify the operations to be
performed on data
data id
Sender
Firewall (F)
data R
data F,R
idF F
Receiver (R)
data idF,R
id idF,R
12
Quick Implementation Overview
• i3 is implemented on top of Chord
– But can easily use CAN, Pastry, Tapestry, etc
• 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)
13
Routing
14
Routing Table
• Chord uses an m bit circular identifier space where 0
follows (2**m) -1
• Each identifier ID is mapped on the server with the
closest identifier that follows ID on the identifier
circle. This server is called successor of ID
• Each server maintains a routing table of size m. The
ith entry in the routing table of server n contains the
first server that follows n + 2**(i-1)
• A server sends the packet to the closest server
(finger) in its routing table that precedes ID.
• It takes O(log N) hops to route a packet to the server
storing the best matching trigger for the packet,
where N is the number of i3 servers.
15
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
S
2m -1 0
S
3
send(37, data)
20
[8..20]
7
7
[4..7]
3
[42..3]
Chord circle
37 R
[21..35]
41
41
20
37 R
35
[36..41]
trigger(37,R)
35
send(R, data)
R
R
16
Optimization #1: Path Length
• Sender/receiver caches i3 node mapping a
specific ID
• Subsequent packets are sent via one i3 node
[8..20]
[4..7]
data 37
[42..3]
Sender (S)
cache node
[21..35]
[36..41]
data R
37 R
Receiver (R)
17
Optimization #2: Triangular Routing
• Use well-known trigger for initial rendezvous
• Exchange a pair of (private) triggers well-located
• Use private triggers to send data traffic
[8..20]
[4..7]
37
data
[2] 30
2 S
Sender (S)
[42..3]
S
[30]
[21..35]
[36..41]
[2] R
37 R
data
R
2
[30]
30 R
Receiver (R)
18
Examples
–
–
–
–
Heterogeneous multicast
Scalable Multicast
Load balancing
Proximity
19
Example 1: Heterogeneous
Multicast
• Sender not aware of transformations
S_MPEG/JPEG
send(R1, data)
send(id, data)
id_MPEG/JPEG S_MPEG/JPEG
Sender
(MPEG)
Receiver R1
(JPEG)
send((id_MPEG/JPEG, R1), data)
id
(id_MPEG/JPEG, R1)
id
R2
send(R2, data)
Receiver R2
(MPEG)
20
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
(g, data)
g
x
g g
R1 R2
R2
(x, data)
x
R3
R3
x
R4
R1
R4
21
Example 2: Scalable Multicast
(Discussion)
Unlike IP multicast, i3
1. Implement only small scale replication  allow
infrastructure to remain simple, robust, and
scalable
2. Gives end-hosts control on routing  enable endhosts to
– Achieve scalability, and
– Optimize tree construction to match their needs, e.g.,
delay, bandwidth
22
Example 3: Load Balancing
• Servers insert triggers with IDs that have random suffixes
• Clients send packets with IDs that have random suffixes
send(1010 0110,data)
S1
1010 0010 S1
A
S2
1010 0101 S2
1010 1010 S3
S3
send(1010 1110,data)
B
1010 1101 S4
S4
23
Example 4: Proximity
• Suffixes of trigger and packet IDs encode the
server and client locations
S2
S3
S1
send(1000 0011,data)
1000 0010
1000 1010 S2
1000 1101 S3
S1
24
Security: Some Attacks
Eavesdropping
Loop
id1 id2
id R
id A
S
R
id4 id1
Attacker (A)
id2 id3
id3 id4
Attacker
Confluence
Dead-End
id2 id3
Attacker id1 id2
id2 id3
id2 id3
id3 V
Victim
(V)
Attacker
id1 id2
id2 id3
25
Possible Defense Measures
• End-hosts can use the public triggers to choose a pair of private triggers,
and then use these private triggers to exchange the actual data. To keep the
private triggers secret, one can use public key cryptography to exchange
the private triggers.
• Instead of inserting the trigger (id, S), the server can insert two triggers,
(id, x) and (x, S) , where x is an identifier known only by S .
• An i3 server can easily verify the identity of a receiver S by sending a
challenge to S the first time the trigger is inserted. The challenge consists
of a random nonce that is expected to be returned by the receiver. If the
receiver fails to answer the challenge the trigger is removed.
• Each server can put a bound on the number of triggers that can be inserted
by a particular end-host.
• When a trigger that doesn’t point to an IP address is inserted, the server
checks whether the new trigger doesn’t create a loop
26
Traffic Isolation
• Drop triggers being flooded without affecting
other triggers
– Protect ongoing connections from new connection
requests
– Protect a service from an attack on another
services
Transaction server
Legitimate client
(C)
ID1 V
ID2 V
Victim (V)
Web server
Attacker
(A)
27
Traffic Isolation
• Drop triggers being flooded without affecting
other triggers
– Protect ongoing connections from new connection
requests
– Protect a service from an attack on another
services
Transaction server
Legitimate client
(C)
ID1 V
Victim (V)
Web server
Attacker
(A)
Traffic of transaction server
protected from attack on web server
28