1 / 31

i3 Status

i3 Status. Ion Stoica UC Berkeley Jan 13, 2003. The Problem. Indirection: a key technique in implementing many network services, e.g., Mobility Multicast, anycast Web caching, replication, load-balancing Anonymity

dbarnwell
Télécharger la présentation

i3 Status

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related