Embed Size (px)
Citation preview
Internet Indirection Infrastructure (i3)
Status – Summer ‘03
Ion Stoica
UC Berkeley
June 5, 2003
Collaborators
• Students:– Daniel Adkins– Karthik Lakshminarayanan– Ananth Rajagopala-Rao– Sonesh Surana– Shelley Zhuang
• Postdocs:– Kevin Lai
• Faculty:– Randy Katz– Scott Shenker
What is i3?
• A highly efficient name-based routing implemented as an overlay network
IP router
i3 node
Communication Abstraction
• 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) // optional
• Best-effort service model (like IP)• Triggers are periodically refreshed by end-
hosts• Reliability, congestion control, and flow-
control implemented at end-hosts
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• In the current implementation: ID length, m = 256, l = 128
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
• 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)
What We’ve Done Since Summer?
• Security (see Dan’s talk)– Preliminary solution presented at last retreat
• Shared overlay infrastructure (see Karthik’s talk)
• Robustness: fast detection of i3 node failures (see Shelley’s talk)– Preliminary solution presented at last retreat
What We’ve Done Since Summer?
Security• Shared overlay infrastructure • Robustness
Security
• Develop a complete solution to protect against IP level denial of service attacks
• Show that a communication infrastructure can provide both more functionality and security than Internet
Design Principles
1) Hide IP address
2) Give end-hosts ability to stop the attack in the infrastructure
3) Make sure that proposed solution does not introduce new security vulnerabilities
1) Hide IP Address
• Enable end-hosts to communicate without revealing their IP address– Otherwise, hosts are vulnerable to IP level
flooding attacks
• i3 trivially implement this principle as data is exchanged via IDs not IP addresses
Sender Receiver (R)
id R
trigger
send(id, data)send(R, data)
2) Enable End-hosts to Defend
• In general, end-hosts are in 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
• With i3 end-hosts can – Stop traffic by removing the trigger under attack– Route around a region of i3 under attack by
moving triggers around– Implement access control for multicast
Example: Avoid Collateral Damage
• Two services shares the same connection to the Internet
• If one service is under attack, the user can save the other one (not possible in the Internet)
idATM S1
Web server (S2)
Customer (C)
idWEB S
Attacker (A)
ATM server (S1)
Bank Company
3) Avoid New Vulnerabilities
• Use light-weight techniques to – Avoid cycles– Confluences – Eavesdropping– Dead ends
• Properties– Most of techniques involves only control plane
no impact on data plane efficiency – Minimal impact on i3 functionality
What We’ve Done Since Summer?
• Security Shared overlay infrastructures • Robustness
Shared Overlay Infrastructure
• Problem: Today’s overlay networks– Mostly independent efforts– Sharing happens mainly at the hardware level (e.g.,
Planetlab)
• Goal: Propose a shared generic overlay infrastructure to support a variety of functionalities
• Solution: Overlay architecture that exports only two primitives (implemented using i3)– Path selection: similar to source routing– Packet replication
What Can We Do With These Primitives?
• Routing control • Coarse grained data manipulation• Measurements – estimate performance
between any two overlay nodes using only the two primitives– RTT– Unidirectional loss rate– Available bandwidth– Bottleneck capacity
Architecture
Weather Service 1
Weather Service 2
Client A
Client DClient B
Network measurements
Query/reply routing info.
Setup routes
Client C
What We’ve Done Since Summer?
• Security• Shared overlay infrastructure Robustness
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
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
• Applications so far– Mobility with support for legacy applications– Large scale multicast– Primitives for shared overlay infrastructure
Future Work
• Use i3 as a substrate for web services– E.g., routing XML queries
• Multiple providers environment– Economic model, policies
