internet indirection infrastructure ion stoica april 16, 2003
Post on 26-Dec-2015
221 Views
Preview:
TRANSCRIPT
istoica@cs.berkeley.edu
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– …
istoica@cs.berkeley.edu
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
istoica@cs.berkeley.edu
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
istoica@cs.berkeley.edu
Application Level Solutions
• Implement the required functionality at the application level, e.g., – Application level multicast (e.g., Fastforward,
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
istoica@cs.berkeley.edu
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
istoica@cs.berkeley.edu
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
istoica@cs.berkeley.edu
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)
istoica@cs.berkeley.edu
Service Model
• API– sendPacket(p);– insertTrigger(t);– removeTrigger(t) // optional
• Best-effort service model (like IP)• Triggers are periodically refreshed by end-
hosts• Reliability, congestion control, and flow-
control implemented at end-hosts
istoica@cs.berkeley.edu
The Promise
• Provide support for– Mobility– Multicast – Anycast– Service composition
istoica@cs.berkeley.edu
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)
istoica@cs.berkeley.edu
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)
istoica@cs.berkeley.edu
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)
istoica@cs.berkeley.edu
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• In the current implementation: ID length, m = 256, l = 128
istoica@cs.berkeley.edu
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)
istoica@cs.berkeley.edu
Service Composition
• Use a stack of IDs to encode the successions of operations to be performed on data
• Advantages– Don’t need to configure path– Load balancing and robustness easy to achieve
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)
istoica@cs.berkeley.edu
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)
istoica@cs.berkeley.edu
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)
istoica@cs.berkeley.edu
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
istoica@cs.berkeley.edu
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”
istoica@cs.berkeley.edu
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
istoica@cs.berkeley.edu
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)
istoica@cs.berkeley.edu
Examples of Using i3
• Heterogeneous multicast• Scalable Multicast• Load balancing• Proximity
istoica@cs.berkeley.edu
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)
istoica@cs.berkeley.edu
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)
istoica@cs.berkeley.edu
Example 2: Scalable Multicast (Discussion)
Unlike IP multicast, i3
1. Implements only small scale replication allow infrastructure to remain simple, robust, and scalable
2. Gives end-hosts control on routing enable end-hosts to – achieve scalability, and– optimize tree construction to match their needs, e.g.,
delay, bandwidth
istoica@cs.berkeley.edu
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
istoica@cs.berkeley.edu
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)
istoica@cs.berkeley.edu
Research Issues
• Security – See the rest of the talk!
• Efficiency– Preliminary work
• Deployment/economical model– Not done yet
istoica@cs.berkeley.edu
Security
• Argue that i3 does is not “worse” than today’s Internet
• Actually, show that i3 can provide better protection against DoS attacks
istoica@cs.berkeley.edu
Protection Against DoS Attacks
• Principles for a generic solution based on an overlay infrastructure1) Enable end-hosts to communicate without
revealing their IP address
2) Give end hosts control to defend against DoS attacks
3) Make sure that the solution does not introduce new vulnerabilities
istoica@cs.berkeley.edu
1) Communicate without revealing IP address
• Trivially done in i3: sender needs only to know receiver’s trigger ID not IP address
• What about attacking i3 server storing the trigger via IP? – How can the sender learn the i3 server’s IP
address?
Attacker (A) Victim(V)send(x’,..)
id V
id’ A
send(A,..)
istoica@cs.berkeley.edu
Solution
• Preclude an i3 server that stores public triggers to store any trigger that points to an end-host
• Receiver R can insert two triggers (id, x), (x, R) instead of (id, R)
• Tradeoffs– Decreased efficiency– i3 has to differentiate between public and private
triggers
Sender (S)
Receiver (R)x R
id x
istoica@cs.berkeley.edu
Solution (cont’d)
• Preclude an i3 server that stores public triggers to store any trigger that points to an end-host
• Receiver R can insert two triggers (id, x), (x, R) instead of (id, R)
Receiver RSenderid x
x R
• Tradeoffs– Decreased efficiency– i3 has to differentiate between public and private
triggers
istoica@cs.berkeley.edu
2) Give end hosts control to defend against DoS attacks
• Usually end-hosts are in the best position to detect when they are under attack– Flash crowds vs. DoS attack
• Once an end-host detects that is under attack it should have the ability to defend against the attack
• This is very hard to do in today’s Internet – If the attacker know your IP address, the only
solution is to involve the ISP
istoica@cs.berkeley.edu
Solution 1: Stop the Attack
• If a receiver is attacked via a private trigger just dropp 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
istoica@cs.berkeley.edu
Solution 2: Slow Down The Attack
• 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)
istoica@cs.berkeley.edu
Solution 3: Multicast Access Control
• Have a trusted 3rd party maintaining a unique trigger for each sender
• 3rd party can easily perform access control and revocation
idG
id1 idR3
S1
id1
R1
R2
R3
ids2 idG
ids1 idG
S2
id1 idR2
id1 idR1
idR1 R1
idR2 R2
idR3 R3
Triggers maintainedby 3rd party
istoica@cs.berkeley.edu
3) Don’t Introduce New Vulnerabilities
• Hardest to do!• i3 opens lots of opportunities for attack
– Eavesdropping– Loops– Confluences– Dead ends
istoica@cs.berkeley.edu
Eavesdropping
SenderReceiver (R)id R
send(id,data) send(R, data)
Attacker (A)
id A
istoica@cs.berkeley.edu
Solution: Secure-i3
Constrained triggers– Solves eavesdropping, loops, confluences
• Push back– Dead-ends
• Trigger challenges– Malicious trigger removal
istoica@cs.berkeley.edu
Constrained Triggers
• Add a new field, key, to ID• Use key to constrain a trigger (x, y)• hl and hr are one way hash functions
prefix key suffix64 128 64
must match
x y
y.key = hr(x)
y
x.key = hl(y)
x y
x.key = hl(y.key)
end-host address
192-bit prefix must mach r-constrained trigger
l-constrained trigger l-constrained trigger pointing to an endhost
istoica@cs.berkeley.edu
Constrained Triggers (cont’d)
• Public i3 servers store only l-constrained triggers
• An l-constrained trigger has strict priority over an r-constrained trigger– Let (x, y) be an l-constrained trigger, i.e., x.key
= hl(y)
– Let (x, y’) be an r-constrained trigger, i.e., y’.key = hl(x)
– Then i3 will store only (x, y)
istoica@cs.berkeley.edu
Eavesdropping
• Use only public triggers (x, y) that are l-constrained• Chose the key of the destination field to be secret• An attacker can eavesdrop only if it can invert
function hl, which is infeasible
y
x.key = hl(y)
x y
x.key = hl(y.key)
end-host address
istoica@cs.berkeley.edu
Loops and Confluences
• We prove that creating loops and confluences is equivalent to inverting either hl or hr infeasible; more difficult than breaking a 512 bit RSA key
istoica@cs.berkeley.edu
Status
• Prototype deployed on – PlanetLab: ran over > 112 nodes
• i3 header with one identifier 48 bytes• Experimental results (on Millennium):
– PIII, 700 MHz, running Linux– Trigger insertion: 80,000 triggers/sec– Throughput of data forwarding overhead
• ~35,500 pps (0 byte payload)• ~23,300 pps (1,400 byte payload) 261 Mbps
• Secure-i3: all techniques involve control path data path not affected!
istoica@cs.berkeley.edu
Conclusions
• Indirection – key technique to implement basic communication abstractions and services such as– Multicast, Anycast, Mobility, …
• This research advocates for:– Build an efficient Indirection layer on top of IP – Leave IP do what is doing best: point-to-point unicast
communication
istoica@cs.berkeley.edu
Conclusions (cont’d)
• i3 gives end-hosts and third parties the ability to control routing – Easy to implement and deploy new services
• General research theme: explore new communication abstractions for overlay network based infrastructures– This work proposes a rendezvous-based
communication abstraction– Other abstractions?
top related