internet indirection infrastructure n.
Skip this Video
Loading SlideShow in 5 Seconds..
Internet Indirection Infrastructure PowerPoint Presentation
Download Presentation
Internet Indirection Infrastructure

Loading in 2 Seconds...

play fullscreen
1 / 51

Internet Indirection Infrastructure - PowerPoint PPT Presentation

Download Presentation
Internet Indirection Infrastructure
An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Internet Indirection Infrastructure Ion Stoica April 16, 2003

  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 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 (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. 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) // 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. 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 • In the current implementation: ID length, m = 256, l = 128

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

  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( 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 2: Scalable Multicast (Discussion) Unlike IP multicast, i3 • Implements only small scale replication  allow infrastructure to remain simple, robust, and scalable • 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. 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

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

  29. Research Issues • Security • See the rest of the talk! • Efficiency • Preliminary work • Deployment/economical model • Not done yet

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

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

  32. id V Victim (V) Attacker (A) send(x’,..) id’ A send(A,..) 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?

  33. id x Receiver (R) x R Sender (S) 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

  34. 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) id x Receiver R Sender x R • Tradeoffs • Decreased efficiency • i3 has to differentiate between public and private triggers

  35. 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. 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. idc C 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 DoS-Filter (A) t S Server (S) Client (C) A id

  38. Solution 3: Multicast Access Control • Have a trusted 3rd party maintaining a unique trigger for each sender • 3rd party can easily perform access control and revocation R1 S1 R1 idR1 idG idR1 ids1 id1 id1 idG idR2 id1 R2 R2 idR2 idG idR3 ids2 id1 S2 R3 idR3 R3 Triggers maintained by 3rd party

  39. 3) Don’t Introduce New Vulnerabilities • Hardest to do! • i3 opens lots of opportunities for attack • Eavesdropping • Loops • Confluences • Dead ends

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

  41. Loops id2 id1 id3 id2 send(id,data) id4 id1 id3 id4 Attacker

  42. Confluences id2 id3 Attacker id1 id2 id3 id2 id3 Victim (V) V id2 id3

  43. Dead-Ends id2 Attacker id1 id3 id4 id3 id2

  44. Solution: Secure-i3 • Constrained triggers • Solves eavesdropping, loops, confluences • Push back • Dead-ends • Trigger challenges • Malicious trigger removal

  45. Constrained Triggers • Add a new field, key, to ID • Use key to constrain a trigger (x, y) • hl and hr are one way hash functions y.key = hr(x) must match x y prefix key suffix 64 128 64 192-bit prefix must mach r-constrained trigger x.key = hl(y) x.key = hl(y.key) y x y end-host address l-constrained trigger l-constrained trigger pointing to an endhost

  46. 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 = hl(y) • Let (x, y’) be an r-constrained trigger, i.e., y’.key = hl(x) • Then i3 will store only (x, y)

  47. 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 hl, which is infeasible x.key = hl(y) x.key = hl(y.key) y x y end-host address

  48. Loops and Confluences • We prove that creating loops and confluences is equivalent to inverting either hl or hr infeasible; more difficult than breaking a 512 bit RSA key

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