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

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

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

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

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

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

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

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

9. 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)idR1 send(id,data) send(R1, data) Receiver (R2) idR2 send(R2, data)

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

11. istoica@cs.berkeley.edu Anycast (cont’d) Anycast is simply a byproduct of the new matching scheme, e.g., –Each receiver R i in the anycast group inserts IDs with the same prefix p and a different suffix s i Sender Receiver (R1) p|s 1 R1 send(p|a,data) Receiver (R2) p|s 2 R2 p|s 3 R3 Receiver (R3) send(R1,data)

12. 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/JPEG id R send((id_ MPEG/JPEG,id), data) S_ MPEG/JPEG send(id, data) send(R, data)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27. 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 Applications so far –Mobility with support for legacy applications –Large scale multicast –Primitives for shared overlay infrastructure

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