Indirection

1. Indirection Jennifer Rexford Advanced Computer Networks http://www.cs.princeton.edu/courses/archive/fall08/cos561/ Tuesdays/Thursdays 1:30pm-2:50pm Slides borrowed liberally from Ion Stoica’s CS 268 class at UC Berkeley

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 • Implicitly assumes there is one sender • … and one receiver, • … and that they are placed at fixed and well-known locations • Network location tied to network layer identifier • E.g., a host identified by the IP address 128.32.xxx.xxx is located in Berkeley

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: • Inefficiency: hard to achieve good performance • 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. “Any problem in computer science can be solved by adding a layer of indirection” 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. Application Build an efficient indirection layer on top of IP Indir. layer TCP/UDP IP I3 Solution • Use overlay network to implement this layer • Incrementally deployable; don’t need to change IP

8. trigger data data data id id R id R Internet Indirection Infrastructure (i3) • Each packet is associated an identifier id • To receive packet with identifier id, receiver R inserts trigger (id, R) into overlay network Sender Receiver (R)

9. Service Model • API • sendPacket(p); • insertTrigger(t); • removeTrigger(t) // optional • Best-effort service model (like IP) • Triggers periodically refreshed by end hosts • ID length: 256 bits

10. Receiver (R1) id id R1 R2 Receiver (R2) Mobility • Host just needs to update its trigger as it moves from one subnet to another Sender

11. data data data data R2 R1 id id Multicast • Receivers insert triggers with same identifier • Dynamically switch between multicast and unicast id R1 Receiver (R1) Sender id R2 Receiver (R2)

12. p|a data p|a data data R1 Anycast • Use longest prefix matching instead of exact matching • Prefix p: anycast group identifier • Suffix si: encode application semantics, e.g., location Receiver (R1) R1 p|s1 R2 p|s2 Sender Receiver (R2) R3 p|s3 Receiver (R3)

13. idT,id T,id data data data data id R idT,id data Service Composition: Sender Initiated • Use a stack of IDs to encode sequence of operations to be performed on data path • Advantages • Don’t need to configure path • Load balancing and robustness easy to achieve Transcoder (T) Receiver (R) Sender id R T idT

14. id data idF,R F,R id data data data data R Service Composition: Receiver Initiated • Receiver can also specify the operations to be performed on data Firewall (F) Receiver (R) F Sender idF id idF,R

15. Quick Implementation Overview • ID space is partitioned across infrastructure nodes • Each node responsible for a region of ID space • Each trigger (id, R) is stored at the node responsible for id • Use Chord to route triggers and packets to nodes responsible for their IDs • O(log N) hops

16. 37 R data data 37 R Example • IDs[0..63] partitioned across five i3 nodes • Each host knows one i3 node • R inserts trigger (37, R); S sends packet (37, data) [8..20] [4..7] [42..3] [21..35] Sender (S) [36..41] Receiver (R)

17. 37 R data data 37 R cache node Optimization: Path Length • Sender/receiver caches i3 node mapping a specific ID • Subsequent packets are sent via one i3 node [8..20] [4..7] [42..3] [21..35] Sender (S) [36..41] Receiver (R)

18. 37 30 R R data data [2] [2] 2 30 37 R R S S 2 [30] [30] Optimization: Triangular Routing • Use well-known trigger for initial rendezvous • Exchange a pair of (private) triggers well-located • Use private triggers to send data traffic [8..20] [4..7] [42..3] [21..35] Sender (S) [36..41] Receiver (R)

19. Outline • Overview • Security • Discussion

20. Loop id1 id2 id2 id3 id4 id1 id4 id3 Attacker id A Confluence Dead-End Attacker (A) id2 id3 id1 id2 id1 id2 Attacker Attacker id2 id3 id3 V id2 id3 Victim (V) id2 id3 Some Attacks Eavesdropping R id R S

21. Right constrained y.key = hr(x) must match ID: prefix key suffix x y 64 128 64 Left constrained x.key = hl(y.key) x.key = hl(y) x y x y end-host address Constrained Triggers • hl(), hr(): well-known one-way hash functions • Use hl(), hr() to constrain trigger (x, y)

22. Attacks & Defenses Attack Defense

23. Design Principles • Give hosts control on routing • A trigger is like an entry in a routing table! • Flexibility, customization • End-hosts can • Source route • Set-up acyclic communication graphs • Route packets through desired service points • Stop flows in infrastructure • … • Implement data forwarding in infrastructure • Efficiency, scalability

24. Design Principles (cont’d) Infrastructure Host Data plane Internet Control plane p2p & End-host overlays Data plane Control plane i3 Control plane Data plane

25. Conclusions • Indirection – key technique to implement basic communication abstractions • Multicast, Anycast, Mobility, … • Building efficient indirection layer on IP • Triggers, and DHTs to map to the location

26. Discussion • Value of composition? • Middlebox functionality • E.g., transcoding, firewall, caching, etc. • Efficiency cost? • Stretch by traversing intermediate node • Processing and storing of triggers • Complexity? • When trying to reduce stretch • When trying to cache information • … • Should indirection be part of future Internet?

27. Next Two Weeks • Guest lectures • 11/18: Mike Freedman • 11/20: Sharon Goldberg • 11/25: Mung Chiang • No class on 11/27 due to Thanksgiving • I’ll be in Thailand • Co-chairing Asia Internet Engineering Conference • After Thanksgiving • Programmability and virtualization…