internet indirection infrastructure (i3) status – summer ‘03 ion stoica uc berkeley june 5, 2003
Post on 15-Jan-2016
223 views
TRANSCRIPT
![Page 1: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/1.jpg)
Internet Indirection Infrastructure (i3)
Status – Summer ‘03
Ion Stoica
UC Berkeley
June 5, 2003
![Page 2: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/2.jpg)
Collaborators
• Students:– Daniel Adkins– Karthik Lakshminarayanan– Ananth Rajagopala-Rao– Sonesh Surana– Shelley Zhuang
• Postdocs:– Kevin Lai
• Faculty:– Randy Katz– Scott Shenker
![Page 3: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/3.jpg)
What is i3?
• A highly efficient name-based routing implemented as an overlay network
IP router
i3 node
![Page 4: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/4.jpg)
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)
![Page 5: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/5.jpg)
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
![Page 7: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/7.jpg)
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)
![Page 8: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/8.jpg)
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)
![Page 9: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/9.jpg)
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)
![Page 10: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/10.jpg)
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
![Page 11: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/11.jpg)
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)
![Page 12: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/12.jpg)
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)
![Page 13: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/13.jpg)
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
![Page 14: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/14.jpg)
What We’ve Done Since Summer?
Security• Shared overlay infrastructure • Robustness
![Page 15: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/15.jpg)
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
![Page 16: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/16.jpg)
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
![Page 17: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/17.jpg)
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)
![Page 18: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/18.jpg)
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
![Page 19: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/19.jpg)
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
![Page 20: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/20.jpg)
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
![Page 21: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/21.jpg)
What We’ve Done Since Summer?
• Security Shared overlay infrastructures • Robustness
![Page 22: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/22.jpg)
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
![Page 23: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/23.jpg)
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
![Page 24: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/24.jpg)
Architecture
Weather Service 1
Weather Service 2
Client A
Client DClient B
Network measurements
Query/reply routing info.
Setup routes
Client C
![Page 25: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/25.jpg)
What We’ve Done Since Summer?
• Security• Shared overlay infrastructure Robustness
![Page 26: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/26.jpg)
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
![Page 27: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/27.jpg)
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
![Page 28: Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003](https://reader036.vdocuments.site/reader036/viewer/2022062409/56649d4c5503460f94a2ada4/html5/thumbnails/28.jpg)
Future Work
• Use i3 as a substrate for web services– E.g., routing XML queries
• Multiple providers environment– Economic model, policies