1. Internet Indirection Infrastructure Ion Stoica April 16, 2003

2. istoica@cs.berkeley.edu Motivations Today’s Internet is built around a unicast point-to-point communication abstraction: –Send packet “p” from host “A” to host “B” This abstraction allows Internet to be highly scalable and efficient, but… … not appropriate for applications that require other communications primitives: –Multicast –Anycast –Mobility –…

3. istoica@cs.berkeley.edu Why? Point-to-point communication abstraction implicitly assumes that there is one sender and one receiver, and that they are placed at fixed and well-known locations –E.g., a host identified by the IP address 128.32.xxx.xxx is located in Berkeley

4. istoica@cs.berkeley.edu IP Solutions Extend IP to support new communication primitives, e.g., –Mobile IP –IP multicast –IP anycast Disadvantages: –Difficult to implement while maintaining Internet’s scalability (e.g., multicast) –Require community wide consensus -- hard to achieve in practice

5. istoica@cs.berkeley.edu Application Level Solutions Implement the required functionality at the application level, e.g., –Application level multicast (e.g., Fastforward, Narada, Overcast, Scattercast…) –Application level mobility Disadvantages: –Efficiency hard to achieve –Redundancy: Each application implements the same functionality over and over again –No synergy; each application implements usually only one service, services hard to combine

6. istoica@cs.berkeley.edu Key Observation All previous solutions use a simple but powerful technique: indirection –Assume a logical or physical indirection point interposed between sender(s) and receiver(s) Examples: –IP multicast assumes a logical indirection point: the IP multicast address –Mobile IP assumes a physical indirection point: the home agent

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

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

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

10. istoica@cs.berkeley.edu The Promise Provide support for –Mobility –Multicast –Anycast –Service composition

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

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

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

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

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

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

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

18. istoica@cs.berkeley.edu Quick Implementation Overview i3 is implemented on top of Chord –But can easily use CAN, Pastry, or Tapestry Each trigger t = ( id, R ) is stored on the node responsible for id Use Chord recursive routing to find best matching trigger for packet p = ( id, data )

19. istoica@cs.berkeley.edu Routing Example R inserts trigger t = (37, R) ; S sends packet p = (37, data) An end-host needs to know only one i3 node to use i3 –E.g., S knows node 3, R knows node 35 3 7 20 35 41 37R 3 7 20 35 41 37R S R trigger(37,R) send(37, data) send(R, data) Chord circle S R 0 2 m-1

20. istoica@cs.berkeley.edu Optimizations Sender/receiver caches node that maps a specific ID Subsequent packets are sent via one i3 node 3 7 20 35 41 37R S R send(R, data) send(37, data) cache node “41”

21. istoica@cs.berkeley.edu Optimizations (cont’d) Address “triangular routing problem”: Public triggers for initial rendezvous Private triggers for efficient routing: Choose private trigger IDs to map onto nearby nodes –Sample identifier space (done off-line), or –Assume end-hosts know the ID of a close by node Note: only applications are aware of private/public distinction; i3 isn’t

22. istoica@cs.berkeley.edu Optimizations (cont’d) H1 wants to contact H2 –H1 knows H2’s public trigger (e.g., Hash(cnn.com)) id public H2 H1 id1 private id2 private H2 H1 H2 send(id public, id1 private ) send(H2, id1 private ) send(id1 private, id2 private ) send(id2 private, data) send(H2, data)

23. istoica@cs.berkeley.edu Examples of Using i3 Heterogeneous multicast Scalable Multicast Load balancing Proximity

24. istoica@cs.berkeley.edu Example 1: Heterogeneous Multicast Sender not aware of transformations Receiver R1 (JPEG) id_ MPEG/JPEG S_ MPEG/JPEG id (id_ MPEG/JPEG, R1) send(id, data) S_ MPEG/JPEG Sender (MPEG) send((id _MPEG/JPEG, R1), data) send(R1, data) id R2 Receiver R2 (MPEG) send(R2, data)

25. istoica@cs.berkeley.edu Example 2: Scalable Multicast i3 doesn’t provide direct support for scalable multicast –Triggers with same identifier are mapped onto the same i3 node Solution: have end-hosts build an hierarchy of trigger of bounded degree R2R2 R1R1 R4R4 R3R3 g R 2 g R 1 gxgx x R 4 x R 3 (g, data) (x, data)

26. istoica@cs.berkeley.edu Example 2: Scalable Multicast (Discussion) Unlike IP multicast, i3 1.Implements only small scale replication  allow infrastructure to remain simple, robust, and scalable 2.Gives end-hosts control on routing  enable end-hosts to –achieve scalability, and –optimize tree construction to match their needs, e.g., delay, bandwidth

27. istoica@cs.berkeley.edu Example 3: Load Balancing Servers insert triggers with IDs that have random suffixes Clients send packets with IDs that have random suffixes S1 1010 0101 S2 1010 S3 1010 1101 S4 S1 S2 S3 S4 A B send(1010 0110,data) send(1010 1110,data) 1010 0010

28. istoica@cs.berkeley.edu Example 4: Proximity Suffixes of trigger and packet IDs encode the server and client locations 1000 0010 S1 1000 1010 S2 1000 1101 S3 S1 S2 S3 send(1000 0011,data)

29. istoica@cs.berkeley.edu Research Issues Security – See the rest of the talk! Efficiency –Preliminary work Deployment/economical model –Not done yet

30. istoica@cs.berkeley.edu Security Argue that i3 does is not “worse” than today’s Internet Actually, show that i3 can provide better protection against DoS attacks

31. istoica@cs.berkeley.edu Protection Against DoS Attacks Principles for a generic solution based on an overlay infrastructure 1)Enable end-hosts to communicate without revealing their IP address 2)Give end hosts control to defend against DoS attacks 3)Make sure that the solution does not introduce new vulnerabilities

32. istoica@cs.berkeley.edu 1) Communicate without revealing IP address Trivially done in i3: sender needs only to know receiver’s trigger ID not IP address What about attacking i3 server storing the trigger via IP? –How can the sender learn the i3 server’s IP address? Attacker (A) Victim (V) send(x’,..) id V id’A send(A,..)

33. istoica@cs.berkeley.edu Solution Preclude an i3 server that stores public triggers to store any trigger that points to an end-host Receiver R can insert two triggers (id, x), (x, R) instead of (id, R) Tradeoffs –Decreased efficiency –i3 has to differentiate between public and private triggers Sender (S) Receiver (R) x R id x

34. istoica@cs.berkeley.edu Solution (cont’d) Preclude an i3 server that stores public triggers to store any trigger that points to an end-host Receiver R can insert two triggers (id, x), (x, R) instead of (id, R) Receiver R Sender id x x R Tradeoffs –Decreased efficiency –i3 has to differentiate between public and private triggers

35. istoica@cs.berkeley.edu 2) Give end hosts control to defend against DoS attacks Usually end-hosts are in the best position to detect when they are under attack –Flash crowds vs. DoS attack Once an end-host detects that is under attack it should have the ability to defend against the attack This is very hard to do in today’s Internet –If the attacker know your IP address, the only solution is to involve the ISP

36. istoica@cs.berkeley.edu Solution 1: Stop the Attack If a receiver is attacked via a private trigger just dropp that trigger In general shutting down a compromised service could save other services that share the same incoming link –Not true in today’s Internet

37. istoica@cs.berkeley.edu Solution 2: Slow Down The Attack Use a DoS-filter server A more powerful than S that maintains S’ public trigger on its behalf A sends puzzles to client C before establishing connection between C and S Server (S) tS id A DoS-Filter (A) id c C Client (C)

38. istoica@cs.berkeley.edu Solution 3: Multicast Access Control Have a trusted 3rd party maintaining a unique trigger for each sender 3 rd party can easily perform access control and revocation id G id 1 id R3 S1 id 1 R1 R2 R3 id s 2 id G id s 1 id G S2 id 1 id R2 id 1 id R 1 R1 id R2 R2 id R3 R3 Triggers maintained by 3 rd party

39. istoica@cs.berkeley.edu 3) Don’t Introduce New Vulnerabilities Hardest to do! i3 opens lots of opportunities for attack –Eavesdropping –Loops –Confluences –Dead ends

40. istoica@cs.berkeley.edu Eavesdropping Sender Receiver (R) idR send(id,data) send(R, data) Attacker (A) idA

41. istoica@cs.berkeley.edu Loops Attacker send(id,data) id 4 id 1 id 2 id 3 id 1 id 4 id 3 id 2

42. istoica@cs.berkeley.edu Confluences Victim (V) id 3 V Attacker id 2 id 1 id 3

43. istoica@cs.berkeley.edu Dead-Ends id 4 Attacker id 2 id 1 id 3 id 2 id 3

44. istoica@cs.berkeley.edu Solution: Secure-i3  Constrained triggers –Solves eavesdropping, loops, confluences Push back –Dead-ends Trigger challenges –Malicious trigger removal

45. istoica@cs.berkeley.edu Constrained Triggers Add a new field, key, to ID Use key to constrain a trigger (x, y) h l and h r are one way hash functions prefixkeysuffix 6412864 must match xy y.key = h r (x) y x.key = h l (y) xy x.key = h l (y.key) end-host address 192-bit prefix must machr-constrained trigger l-constrained trigger l-constrained trigger pointing to an endhost

46. istoica@cs.berkeley.edu Constrained Triggers (cont’d) Public i3 servers store only l-constrained triggers An l-constrained trigger has strict priority over an r-constrained trigger –Let (x, y) be an l-constrained trigger, i.e., x.key = h l (y) –Let (x, y’) be an r-constrained trigger, i.e., y’.key = h l (x) –Then i3 will store only (x, y)

47. istoica@cs.berkeley.edu Eavesdropping Use only public triggers (x, y) that are l-constrained Chose the key of the destination field to be secret An attacker can eavesdrop only if it can invert function h l, which is infeasible y x.key = h l (y) xy x.key = h l (y.key) end-host address

48. istoica@cs.berkeley.edu Loops and Confluences We prove that creating loops and confluences is equivalent to inverting either h l or h r  infeasible; more difficult than breaking a 512 bit RSA key

49. istoica@cs.berkeley.edu Status Prototype deployed on –PlanetLab: ran over > 112 nodes i3 header with one identifier  48 bytes Experimental results (on Millennium): –PIII, 700 MHz, running Linux –Trigger insertion: 80,000 triggers/sec –Throughput of data forwarding overhead ~35,500 pps (0 byte payload) ~23,300 pps (1,400 byte payload)  261 Mbps Secure-i3: all techniques involve control path  data path not affected!

50. istoica@cs.berkeley.edu Conclusions Indirection – key technique to implement basic communication abstractions and services such as –Multicast, Anycast, Mobility, … This research advocates for: –Build an efficient Indirection layer on top of IP –Leave IP do what is doing best: point-to-point unicast communication

51. istoica@cs.berkeley.edu Conclusions (cont’d) i3 gives end-hosts and third parties the ability to control routing –Easy to implement and deploy new services General research theme: explore new communication abstractions for overlay network based infrastructures –This work proposes a rendezvous-based communication abstraction –Other abstractions?