1. i3 Status Ion Stoica UC Berkeley Jan 13, 2003

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

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

4. 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 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 The Promise Provide support for –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? Performance improvements –Routing efficiency –Robustness Security

14. 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 –90 th percentile latency < 500 ms –90 th 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

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

16. 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)

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

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

19. istoica@cs.berkeley.edu Example Server maintains a public trigger id public –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 id public S Server (S) Host (A) send(id privateA,data) id privateA S id privateB S send(id privateB,data) Host (B)

20. istoica@cs.berkeley.edu Attack on Private Trigger Defense: just remove trigger under attack! id public S Server (S) Attacker (A) send(id privateA,data) id privateA S id privateB S send(id privateB,data) Host (B)

21. 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 id public S Server (S) Attacker (A) send(id privateA,data) id privateB S send(id privateB,data) Host (B)

22. 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 id public1 S Server (S) Attacker (A) id privateB S send(id privateB,data) Host (B) id public2 S id publicn S …

23. 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 id public1 S Server (S) Attacker (A) id privateB S send(id privateB,data) Host (B) id public2 S id publicn S …

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

25. 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 id public1 F Server (S) Attacker (A) id privateB S send(id privateB,data) Host (B) id public2 F id publicn S … Fake server (F)

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

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

28. istoica@cs.berkeley.edu Future Work More applications –So far: mobility, multicast –Next: light-weight name resolution, modular protocols, … Resource management and QoS

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

30. 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)

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