View
215
Download
2
Category
Tags:
Preview:
Citation preview
istoica@cs.berkeley.edu
The Problem
• Indirection: a key technique in implementing many network services, e.g., – Mobility– Multicast, anycast– Web caching, replication, load-balancing– Anonymity
• IP doesn’t provide efficient support for indirection difficult and complex to deploy these services
• Our approach: make indirection a first level design principle in network architecture
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
What We’ve Done Since Summer?
• Performance improvements– Routing efficiency– Robustness
• Security
istoica@cs.berkeley.edu
Routing Efficiency
• Recall that i3 uses Chord for routing• Use simple heuristics to reduce Chord’s
routing latency• Results using 16,384 node networks (path
length = 7), and real latency distributions– 90th percentile latency < 500 ms– 90th percentile relative delay penalty (RDP) < 2
• Note: in i3 the latency cost is paid only first time when a trigger is accessed– Trigger’s location is cached after first access
istoica@cs.berkeley.edu
Robustness
• Use cooperative algorithms to reduce time to detect a node failure – Same message overhead as a simple keep-
alive alg.
• Can achieve recovery times on the order of a few RTTs– Bottleneck in practice: the time it takes to
make sure that a node has failed with high probability
• See Shelley and Matt’s talk
istoica@cs.berkeley.edu
Security
• Show that i3’s flexibility can improve (not hurt) end-host security
• Redesign i3 to make it secure without compromising its flexibility and performance (see Dan’s talk tomorrow)
istoica@cs.berkeley.edu
Key Observation
• To improve end-host security it is necessary to give end-hosts more control on routing and data forwarding in the infrastructure
istoica@cs.berkeley.edu
Why?
• End-hosts are in the best position to detect when they are under attack– E.g., flash-crowd vs. DoS, SYN attack
• Once an end-host detects an attack, it should be able to stop/redirect the offending traffic before it arrives at its inbound connection– i3 gives end-host this flexibility
istoica@cs.berkeley.edu
Example
• Server maintains a public trigger idpublic
– Clients contact the server via its public trigger
• For each client i , the server allocates a private trigger – The private trigger is a shared secret between the server and
client
idpublic SServer
(S)Host (A)
send(idprivateA,data)
idprivateA S
idprivateB Ssend(idprivateB,data)
Host (B)
istoica@cs.berkeley.edu
Attack on Private Trigger
• Defense: just remove trigger under attack!
idpublic SServer
(S)Attacker (A)
send(idprivateA,data)
idprivateA S
idprivateB Ssend(idprivateB,data)
Host (B)
istoica@cs.berkeley.edu
Attack on Private Trigger
• Defense: just remove trigger under attack– Offending traffic stopped in the network, before
arriving at server’s inbound connection
idpublic SServer
(S)Attacker (A)
send(idprivateA,data)
idprivateB Ssend(idprivateB,data)
Host (B)
istoica@cs.berkeley.edu
Attack on Public Trigger
• Server maintains n (instead of one) public triggers
• To establish a connection, a client randomly selects one of the public triggers
idpublic1 S
Server (S)Attacker (A)
idprivateB Ssend(idprivateB,data)
Host (B)
idpublic2 S
idpublicn S
…
istoica@cs.berkeley.edu
Attack on Public Trigger (cont’d)
• Assume flooding attack• Defense: remove the highest loaded m triggers
– Eliminate f=m/n of the offending traffic– Trade-off: clients need to make 1/(1-f) tries to connect– Ongoing connections (i.e., private triggers) not affected
idpublic1 S
Server (S)Attacker (A)
idprivateB Ssend(idprivateB,data)
Host (B)
idpublic2 S
idpublicn S
…
istoica@cs.berkeley.edu
Attack on Public Trigger (cont’d)
• An intelligent attacker can detect when a public trigger was removed and redirect its attack on the remaining public triggers
• Server can defend against this by periodically changing the subset of active triggers– Every period T make active a different subset of m
triggers out of the available n public triggers
istoica@cs.berkeley.edu
Attack on Public Trigger (cont’d)
• Assume bottleneck is computation not communication• Defense: redirect traffic to a fake server instead of
removing triggers – Make it more difficult for attacker to detect when a trigger was
redirected
idpublic1 F
Server (S)Attacker (A)
idprivateB Ssend(idprivateB,data)
Host (B)
idpublic2 F
idpublicn S
…
Fake server
(F)
istoica@cs.berkeley.edu
Attack on Public Trigger (cont’d)
• Have the fake server reply with puzzles which, if solved, reveal active public triggers
• Can use captchas, i.e., puzzles easy to solve by humans, but very difficult by machines– E.g., distorted words:
• A human user can always connect after the second try
istoica@cs.berkeley.edu
Conclusions
• Indirection, key primitive to support– Basic communication abstractions, e.g., multicast,
anycast, mobility– Improve end-host security
• This research advocates for:– Leaving IP do what is doing best: point-to-point unicast
communication– Building an efficient Indirection Layer on top of IP
istoica@cs.berkeley.edu
Future Work
• More applications– So far: mobility, multicast– Next: light-weight name resolution, modular
protocols, …
• Resource management and QoS
istoica@cs.berkeley.edu
Increasing Routing Efficiency
• i3 uses Chord for routing– Study simple heuristics to reduce Chord’s
routing latency
• Proximity Node Selection, PNS(K)– Each node maintains for each finger the set of
its K successors– Chose the closest successor of the finger to
route instead the finger
• Proximity Route Selection (PRS)– Choose a finger that balances the progress in
the ID space vs. the latency cost
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)
Recommended