Internet Indirection Infrastructure (i3): Enhancing Network Services

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

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

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

4. send(R, data) send(id, data) trigger id R 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 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. The Promise • Provide support for • 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? • Performance improvements • Routing efficiency • Robustness • Security istoica@cs.berkeley.edu

14. 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 • 90th percentile latency < 500 ms • 90th 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 istoica@cs.berkeley.edu

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

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

17. Key Observation • To improve end-host security it is necessary to give end-hosts more control on routing and data forwarding in the infrastructure istoica@cs.berkeley.edu

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

19. Example • Server maintains a public trigger idpublic • 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 Server (S) send(idprivateA,data) idpublic S Host (A) idprivateA S send(idprivateB,data) idprivateB S Host (B) istoica@cs.berkeley.edu

20. Attack on Private Trigger • Defense: just remove trigger under attack! Server (S) send(idprivateA,data) idpublic S Attacker (A) idprivateA S send(idprivateB,data) idprivateB S Host (B) istoica@cs.berkeley.edu

21. Attack on Private Trigger • Defense: just remove trigger under attack • Offending traffic stopped in the network, before arriving at server’s inbound connection Server (S) send(idprivateA,data) idpublic S Attacker (A) send(idprivateB,data) idprivateB S Host (B) istoica@cs.berkeley.edu

22. 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 idpublic1 S idpublic2 S Server (S) … Attacker (A) idpublicn S send(idprivateB,data) idprivateB S Host (B) istoica@cs.berkeley.edu

23. 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 idpublic1 S idpublic2 S Server (S) … Attacker (A) idpublicn S send(idprivateB,data) idprivateB S Host (B) istoica@cs.berkeley.edu

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

25. 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 Fake server (F) idpublic1 F idpublic2 F Server (S) … Attacker (A) idpublicn S send(idprivateB,data) idprivateB S istoica@cs.berkeley.edu Host (B)

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

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

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

30. send(R, data) send(id, data) send((id_MPEG/JPEG, R), data) Service Composition (cont’d) • Receiver can also specify the operations to be performed on data S_MPEG/JPEG Receiver R (JPEG) Sender (MPEG) S_MPEG/JPEG id_MPEG/JPEG id (id_MPEG/JPEG, R) istoica@cs.berkeley.edu

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