Indirection
Jennifer Rexford
Advanced Computer Networks
http://www.cs.princeton.edu/courses/archive/fall08/cos561/
Tuesdays/Thursdays 1:30pm-2:50pm
Slides borrowed liberally from Ion Stoica’s CS 268 class at UC Berkeley
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
– Implicitly assumes there is one sender
– … and one receiver,
– … and that they are placed at fixed and wellknown locations
• Network location tied to network layer
identifier
– E.g., a host identified by the IP address
128.32.xxx.xxx is located in Berkeley
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:
– Inefficiency: hard to achieve good performance
– 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
“Any problem in computer science can
be solved by adding a layer of indirection”
I3 Solution
Build an efficient indirection layer
on top of IP
• Use overlay network to implement this layer
– Incrementally deployable; don’t need to change IP
Application
Indir.
TCP/UDP
layer
IP
Internet Indirection Infrastructure (i3)
• Each packet is associated an identifier id
• To receive packet with identifier id, receiver R
inserts trigger (id, R) into overlay network
data id
Sender
Receiver (R)
data R
id R
trigger
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
Mobility
• Host just needs to update its trigger as it
moves from one subnet to another
Sender
id R2
R1
Receiver
(R1)
Receiver
(R2)
Multicast
• Receivers insert triggers with same identifier
• Dynamically switch between multicast and
unicast
data id
Sender
data R1
id R1
Receiver (R1)
id R2
data R2
Receiver (R2)
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)
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)
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
data idF,R
id idF,R
Receiver (R)
Quick Implementation Overview
• ID space is partitioned across infrastructure
nodes
– Each node responsible for a region of ID space
• Each trigger (id, R) is stored at the node
responsible for id
• Use Chord to route triggers and packets to
nodes responsible for their IDs
– O(log N) hops
Example
• IDs[0..63] partitioned across five i3 nodes
• Each host knows one i3 node
• R inserts trigger (37, R); S sends packet (37,
data)
[8..20]
[4..7]
data 37
Sender (S)
[42..3]
[21..35]
[36..41]
data R
37 R
Receiver (R)
Optimization: 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)
Optimization: Triangular Routing
• Use well-known trigger for initial rendezvous
• Exchange a pair of (private) triggers welllocated
• 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)
Outline
• Overview
Security
• Discussion
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
Constrained Triggers
• hl(), hr(): well-known one-way hash functions
• Use hl(), hr() to constrain trigger (x, y)
Right constrained
must match
ID: prefix
64
key
128
y.key = hr(x)
suffix
64
x
y
Left constrained
x.key = hl(y.key)
x.key = hl(y)
x
y
x
y
end-host address
Attacks & Defenses
Attack
Defense
Eavesdropping&
Impersonation
Loops &
Confluences
Dead-ends
Reflection &
Malicious
trigger-removal
Confluences
Trigger
Pushbac
constraint k
s
Trigger
Public i3
challenge node
s
constraint
s
Design Principles
• Give hosts control on routing
– A trigger is like an entry in a routing table!
– Flexibility, customization
– End-hosts can
• Source route
• Set-up acyclic communication graphs
• Route packets through desired service points
• Stop flows in infrastructure
•…
• Implement data forwarding in infrastructure
– Efficiency, scalability
Design Principles (cont’d)
Host
Infrastructure
Data plane
Internet
Control plane
p2p &
End-host overlays
i3
Data plane
Control plane
Control plane
Data plane
Conclusions
• Indirection – key technique to implement
basic communication abstractions
– Multicast, Anycast, Mobility, …
• Building efficient indirection layer on IP
– Triggers, and DHTs to map to the location
Discussion
• Value of composition?
– Middlebox functionality
– E.g., transcoding, firewall, caching, etc.
• Efficiency cost?
– Stretch by traversing intermediate node
– Processing and storing of triggers
• Complexity?
– When trying to reduce stretch
– When trying to cache information
–…
• Should indirection be part of future Internet?
Next Two Weeks
• Guest lectures
– 11/18: Mike Freedman
– 11/20: Sharon Goldberg
– 11/25: Mung Chiang
• No class on 11/27 due to Thanksgiving
• I’ll be in Thailand
– Co-chairing Asia Internet Engineering Conference
• After Thanksgiving
– Programmability and virtualization…