Internet Indirection Infrastructure (i3) Status – Summer ‘03

1. Internet Indirection Infrastructure (i3) Status – Summer ‘03 Ion Stoica UC Berkeley June 5, 2003

2. Students: Daniel Adkins Karthik Lakshminarayanan Ananth Rajagopala-Rao Sonesh Surana Shelley Zhuang Postdocs: Kevin Lai Faculty: Randy Katz Scott Shenker Collaborators istoica@cs.berkeley.edu

3. What is i3? • A highly efficient name-based routing implemented as an overlay network IP router i3 node istoica@cs.berkeley.edu

4. send(R, data) send(id, data) trigger id R 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) istoica@cs.berkeley.edu

5. 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

6. What Does i3 Support? • Mobility • Multicast • Anycast • Service composition istoica@cs.berkeley.edu

7. send(R1, data) send(id,data) Mobility • Host just needs to update its trigger as it moves from one subnet to another Receiver (R1) Sender id R1 istoica@cs.berkeley.edu

8. send(id,data) Mobility • Host just needs to update its trigger as moves from one subnet to another send(R2, data) Sender id R2 Receiver (R2) istoica@cs.berkeley.edu

9. Multicast • Unifies multicast and unicast abstractions • Multicast: receivers insert triggers with the same identifier • An application can dynamically switch between multicast and unicast send(R1, data) send(id,data) id R1 Receiver (R1) Sender id R2 send(R2, data) Receiver (R2) istoica@cs.berkeley.edu

10. 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

11. 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 send(R1,data) Receiver (R1) p|s1 R1 send(p|a,data) p|s2 R2 Sender Receiver (R2) p|s3 R3 Receiver (R3) istoica@cs.berkeley.edu

12. send((id_MPEG/JPEG,id), data) send(R, data) send(id, 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 S_MPEG/JPEG Receiver R (JPEG) Sender (MPEG) id R S_MPEG/JPEG id_MPEG/JPEG istoica@cs.berkeley.edu

13. 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 istoica@cs.berkeley.edu

14. What We’ve Done Since Summer? • Security • Shared overlay infrastructure • Robustness istoica@cs.berkeley.edu

15. 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 istoica@cs.berkeley.edu

16. Design Principles • Hide IP address • Give end-hosts ability to stop the attack in the infrastructure • Make sure that proposed solution does not introduce new security vulnerabilities istoica@cs.berkeley.edu

17. send(R, data) send(id, data) 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) trigger id R istoica@cs.berkeley.edu

18. 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 istoica@cs.berkeley.edu

19. 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) ATM server (S1) idATM S1 Customer (C) Web server (S2) idWEB S Bank Company Attacker (A) istoica@cs.berkeley.edu

20. 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 istoica@cs.berkeley.edu

21. What We’ve Done Since Summer? • Security • Shared overlay infrastructures • Robustness istoica@cs.berkeley.edu

22. 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 istoica@cs.berkeley.edu

23. 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 istoica@cs.berkeley.edu

24. Weather Service 1 Weather Service 2 Architecture Client A Network measurements Query/reply routing info. Setup routes Client B Client D Client C istoica@cs.berkeley.edu

25. What We’ve Done Since Summer? • Security • Shared overlay infrastructure • Robustness istoica@cs.berkeley.edu

26. 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 istoica@cs.berkeley.edu

27. 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 istoica@cs.berkeley.edu

28. Future Work • Use i3 as a substrate for web services • E.g., routing XML queries • Multiple providers environment • Economic model, policies istoica@cs.berkeley.edu