i3 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 (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

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)

id R

trigger

send(id, data)send(R, data)

istoica@cs.berkeley.edu

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

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

SenderReceiver

(R1)id R1

send(id,data) send(R1, data)

istoica@cs.berkeley.edu

Mobility

• Host just needs to update its trigger as moves from one subnet to another

Sender

Receiver(R2)

id R2

send(id,data)

send(R2, data)

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

Sender Receiver (R1)id R1

send(id,data) send(R1, data)

Receiver (R2)

id R2

send(R2, data)

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

Sender

Receiver (R1)p|s1 R1send(p|a,data)

Receiver (R2)p|s2 R2

p|s3 R3

Receiver (R3)

send(R1,data)

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

Sender(MPEG)

Receiver R(JPEG)

id_MPEG/JPEG S_MPEG/JPEGid R

send((id_MPEG/JPEG,id), data)

S_MPEG/JPEG

send(id, data) send(R, data)

istoica@cs.berkeley.edu

What We’ve Done Since Summer?

• Performance improvements– Routing efficiency– Robustness

• Security

istoica@cs.berkeley.edu

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

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

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

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

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

idpublic SServer

(S)Host (A)

send(idprivateA,data)

idprivateA S

idprivateB Ssend(idprivateB,data)

Host (B)

istoica@cs.berkeley.edu

Attack on Private Trigger

• Defense: just remove trigger under attack!

idpublic SServer

(S)Attacker (A)

send(idprivateA,data)

idprivateA S

idprivateB Ssend(idprivateB,data)

Host (B)

istoica@cs.berkeley.edu

Attack on Private Trigger

• Defense: just remove trigger under attack– Offending traffic stopped in the network, before

arriving at server’s inbound connection

idpublic SServer

(S)Attacker (A)

send(idprivateA,data)

idprivateB Ssend(idprivateB,data)

Host (B)

istoica@cs.berkeley.edu

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

Server (S)Attacker (A)

idprivateB Ssend(idprivateB,data)

Host (B)

idpublic2 S

idpublicn S

…

istoica@cs.berkeley.edu

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

Server (S)Attacker (A)

idprivateB Ssend(idprivateB,data)

Host (B)

idpublic2 S

idpublicn S

…

istoica@cs.berkeley.edu

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

idpublic1 F

Server (S)Attacker (A)

idprivateB Ssend(idprivateB,data)

Host (B)

idpublic2 F

idpublicn S

…

Fake server

(F)

istoica@cs.berkeley.edu

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 QoS

istoica@cs.berkeley.edu

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

Service Composition (cont’d)

• Receiver can also specify the operations to be performed on data

Receiver R(JPEG)

id_MPEG/JPEG S_MPEG/JPEG

id (id_MPEG/JPEG, R)

send(id, data)

S_MPEG/JPEG

Sender(MPEG)

send((id_MPEG/JPEG, R), data)

send(R, data)

istoica@cs.berkeley.edu

Collaborators

• Students:– Daniel Adkins– Karthik Lakshminarayanan– Ananth Rajagopala-Rao– Sonesh Surana– Shelley Zhuang

• Postdocs:– Kevin Lai

• Faculty:– Randy Katz– Scott Shenker