Internet Indirection Infrastructure

1. Internet Indirection Infrastructure Slides thanks to Ion Stoica

2. 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. 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 • Network location tied to network layer identifier

4. 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. Application Level Solutions • Implement the required functionality at the application level, e.g., • Application level multicast • 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. 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. 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. 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)

9. Service Model • API • sendPacket(p); • insertTrigger(t); • removeTrigger(t) • Best-effort service model (like IP) • Triggers are periodically refreshed by end-hosts • Reliability, congestion control, and flow-control implemented at end-hosts

10. The Promise • Provide support for • Mobility • Multicast • Anycast • Service composition

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

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

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

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

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

16. 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 • Similar to the idea of delegation in DOA S_MPEG/JPEG Receiver R (JPEG) Sender (MPEG) id R S_MPEG/JPEG id_MPEG/JPEG

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

18. 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. send(37, data) 37 R trigger(37,R) send(R, data) 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 S 0 2m-1 S 3 20 7 7 Chord circle 3 35 41 41 20 37 R 35 R R

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

21. 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. send(H2, id1private) send(idpublic, id1private) H2 idpublic H1 id1private H2 id2private send(H2, data) send(id1private, id2private) send(id2private, data) Optimizations (cont’d) • H1 wants to contact H2 • H1 knows H2’s public trigger (e.g., Hash(cnn.com)) H2 H1

23. Examples of Using i3 • Heterogeneous multicast • Scalable Multicast • Load balancing • Proximity

24. send(R2, data) id R2 Receiver R2 (MPEG) Example 1: Heterogeneous Multicast • Sender not aware of transformations S_MPEG/JPEG send(R1, data) send(id, data) Receiver R1 (JPEG) Sender (MPEG) S_MPEG/JPEG id_MPEG/JPEG send((id_MPEG/JPEG, R1), data) id (id_MPEG/JPEG, R1)

25. (g, data) g x g R1 g R2 R2 (x, data) x R3 x R4 R1 R3 R4 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

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

27. Example 4: Proximity • Suffixes of trigger and packet IDs encode the server and client locations S2 S3 S1 send(1000 0011,data) 1000 1010 S2 S3 1000 1101 1000 0010 S1

28. Security • i3 does is not “worse” than today’s Internet • Actually, show that i3 can provide better protection against DoS attacks

29. Eavesdropping send(R, data) send(id,data) Receiver (R) id R Sender id A Attacker (A)

30. Solution • Random private triggers • Periodically change private triggers • Multiple private triggers per flow • Public key cryptography to exchange private triggers

31. id x Receiver (R) x R Sender (S) Trigger hijacking • Malicious user can isolate a host by removing its public trigger • Solution: Another level of indirection • Receiver R can insert two triggers (id, x), (x, R) instead of (id, R)

32. DOS attack on end hosts id2 id3 Attacker id1 id2 id3 id2 id3 Victim (V) V id2 id3

33. Solution 1: Stop the Attack • If a receiver is attacked via a private trigger just drop 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

34. idc C Solution 2: Third party firewall • 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 DoS-Filter (A) t S Server (S) Client (C) A id

35. Take-home lessons • The idea of “indirection” • Rendezvous based communication abstraction • DHTs and flat name lookups enable new Internet architectures