i 3 Status Ion Stoica UC Berkeley Jan

i 3 Status Ion Stoica UC Berkeley Jan 13, 2003 istoica@cs. berkeley. edu

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

Our Solution: Internet Indirection Infrastructure (i 3) • 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 i 3 node istoica@cs. berkeley. edu

i 3 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 send(R, data) send(id, data) Sender trigger id R istoica@cs. berkeley. edu Receiver (R)

Service Model • API – send. Packet(p); – insert. Trigger(t); – remove. Trigger(t) // optional • Best-effort service model (like IP) • Triggers are periodically refreshed by endhosts • Reliability, congestion control, and flowcontrol implemented at end-hosts istoica@cs. berkeley. edu

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

Mobility • Host just needs to update its trigger as it moves from one subnet to another send(id, data) Sender send(R 1, data) id R 1 istoica@cs. berkeley. edu Receiver (R 1)

Mobility • Host just needs to update its trigger as moves from one subnet to another send(id, data) send(R 2, data) Sender id R 2 Receiver (R 2) 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 send(id, data) Sender send(R 1, data) id R 1 Receiver (R 1) id R 2 send(R 2, data) Receiver (R 2) 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 istoica@cs. berkeley. edu

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(R 1, data) Receiver (R 1) send(p|a, data) Sender p|s 1 R 1 p|s 2 R 2 p|s 3 Receiver (R 2) Receiver (R 3) 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 S_MPEG/JPEG send((id_MPEG/JPEG, id), data) Sender (MPEG) send(R, data) send(id, data) S_MPEG/JPEG id_MPEG/JPEG istoica@cs. berkeley. edu id R Receiver R (JPEG)

What We’ve Done Since Summer? • Performance improvements – Routing efficiency – Robustness • Security istoica@cs. berkeley. edu

Routing Efficiency • Recall that i 3 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 – 90 th percentile latency < 500 ms – 90 th percentile relative delay penalty (RDP) < 2 • Note: in i 3 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

Robustness • Use cooperative algorithms to reduce time to detect a node failure – Same message overhead as a simple keepalive 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

Security • Show that i 3’s flexibility can improve (not hurt) end-host security • Redesign i 3 to make it secure without compromising its flexibility and performance (see Dan’s talk tomorrow) istoica@cs. berkeley. edu

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

Why? • End-hosts are in the best position to detect when they are under attack – E. g. , flash-crowd vs. Do. S, 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 – i 3 gives end-host this flexibility istoica@cs. berkeley. edu

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 send(idprivate. A, data) Host (A) idpublic S idprivate. A S send(idprivate. B, data) idprivate. B S Host (B) istoica@cs. berkeley. edu Server (S)

Attack on Private Trigger • Defense: just remove trigger under attack! send(idprivate. A, data) Attacker (A) idpublic S idprivate. A S send(idprivate. B, data) idprivate. B S Host (B) istoica@cs. berkeley. edu Server (S)

Attack on Private Trigger • Defense: just remove trigger under attack – Offending traffic stopped in the network, before arriving at server’s inbound connection send(idprivate. A, data) idpublic S Attacker (A) send(idprivate. B, data) idprivate. B S Host (B) istoica@cs. berkeley. edu Server (S)

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 idpublic 1 S idpublic 2 S … Attacker (A) idpublicn S send(idprivate. B, data) Host (B) idprivate. B S istoica@cs. berkeley. edu Server (S)

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 idpublic 1 S idpublic 2 S … Attacker (A) idpublicn S send(idprivate. B, data) Host (B) idprivate. B S istoica@cs. berkeley. edu Server (S)

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

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 idpublic 1 F idpublic 2 F … Attacker (A) idpublicn S send(idprivate. B, data) Host (B) idprivate. B S istoica@cs. berkeley. edu Fake server (F) Server (S)

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

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

Future Work • More applications – So far: mobility, multicast – Next: light-weight name resolution, modular protocols, … • Resource management and Qo. S istoica@cs. berkeley. edu

Increasing Routing Efficiency • i 3 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

Service Composition (cont’d) • Receiver can also specify the operations to be performed on data S_MPEG/JPEG send(R, data) send(id, data) Sender (MPEG) S_MPEG/JPEG id_MPEG/JPEG send((id_MPEG/JPEG, R), data) id (id_MPEG/JPEG, R) istoica@cs. berkeley. edu Receiver R (JPEG)

Collaborators • Students: – – – • Faculty: Daniel Adkins Karthik Lakshminarayanan Ananth Rajagopala-Rao Sonesh Surana Shelley Zhuang – Randy Katz – Scott Shenker • Postdocs: – Kevin Lai istoica@cs. berkeley. edu