i3 Update

Ion Stoica and many others…UC Berkeley

January 10, 2005

Goal

• Provide seamless network support for basic communication abstractions– Multicast– Anycast– Mobility– Service composition

Key Observation

• Virtually all previous proposals use indirection, e.g., – Physical indirection point mobile IP– Logical indirection point IP multicast

“Any problem in computer science can be solved by adding a layer of indirection”

Our Solution

• Use an overlay network to implement this layer– Incrementally deployable; don’t need to change IP

Build an efficient indirection layer

on top of IP

IP

TCP/UDP

Application

Indir.layer

Internet Indirection Infrastructure (i3)

• 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

id Rtrigger

iddata

Receiver (R)

iddata

Rdata

Status

• First (limited) release: May, 2004– Run as a service on PlanetLab (check

i3.cs.berkeley.edu)• Currently used by several research

groups in academia and industry:– Helsinki Institute for Information Technology

(HIIT)– KDDI Labs– Purdue University– UIUC – University of Tüebingen– University of Waterloo– …

User Feedback: The Good News

• Tremendously flexible– Provide a global and flexible identifier

space• IDs can identify virtually anything, end-hosts,

services, sessions, humans, devices, etc..

– Allow hosts to explicitly route packets through intermediate “processing points”

– Abstract away the behavior of hosts (e.g., mask mobility) from each other

User Feedback: The Bad News

• Efficiency– Many users didn’t want all their packets relayed through

i3– High overhead for maintaining per-host triggers– Select nearby remote proxies

• Usability– Address book (name resolution), a pain to use– API, far too complex and confusing

• Proxy for legacy applications

– Very useful, but…– … requests for using it for other overlays

• Transparency– Didn’t work (well) for firewalls that blocked UDP traffic

What We’ve Done About It?

• Efficiency– Many users didn’t want all their packets relayed through

i3– High overhead for maintaining per-host trigger– Select nearby remote proxies

• Usability– Addressbook (name resolution), a pain to use– API, far too complex and confusing

• Proxy for legacy applications– Very useful, but…– … requests for using it for other overlays

• Transparency– Didn’t work (well) for firewalls that blocked UDP traffic

Shortcuts

Trigger aggregatio

nIdentity based

resolution>50 calls ~15 calls

Generalize proxy design

Use TCP as underlying transport if needed

What We’ve Done About It?

• Efficiency– Many users didn’t want all their packets relayed through i3– High overhead for maintaining per-host trigger– Select nearby remote proxies

• Usability– Addressbook (name resolution), a pain to use– API, far too complex and confusing

• Proxy for legacy applications– Very useful, but…– … requests for using it for other overlays

• Transparency– Didn’t work (well) for firewalls that blocked UDP traffic

Shortcuts

Trigger aggregatio

nIdentity based

resolution>50 calls ~15 calls

Generalize proxy design

Use TCP as underlying transport if needed

Shortcuts: Problem

• Each packet is traversing an i3 server no matter whether the user wants/needs to or not

Shortcuts: Solution

• Associate an “allow-caching” bit with both packets and triggers

• If both the packet and trigger have the bit set sender can cache receiver’s address

LA LBidBA A1

Host A (IPB)Host B

3

1(idBA,data)

cache=IPB 2

Shortcuts: Discussion

• Shortcuts are allowed only if both the sender and receiver agree

• Indirection still needed for– Simultaneous mobility– Anonymity– Firewalls & some types of NATs– …

• i3 becomes a lookup infrastructure

Shortcuts & NATs

• Allow shortcuts as long as the receiver is not behind a symmetric NAT– NATs which allocate port number per

destination basis

Name Resolution Problem

• Local resolution (current solution)– Maintain a local address book– Secure, but inconvenient

• Global resolution (e.g., DNS, OpenDHT)– Requires name allocation authority– Requires infrastructure for resolution– As secure as the resolution infrastructure

• Limited by Zooko’s paradox– Decentralization, Security, Human readability:

Pick two

Current Proposal: Identity Based Resolution

• Uses Boneh-Franklin Identity Based Encryption (IBE)

• Requires authority and infrastructure for name allocation only

• Secure, convenient, low bandwidth consumption

IBE: Basic Scheme

Private Key Generator (M)

Decrypt message using PrivKeyfoo

Receiver R (Foo)

W W W

Sender S

Publish Master Public Key (MPKM)

Request private key for Foo.

Obtain MPKM

PubKeyFoo = PK(MPKM, Foo)

SendPrivKeyFoo

message

PubKeyFoo

Identity Based Resolution: IBE Application to i3

• Name allocation– FCFS policy

• E-mail based allocation (see poster!)

– Use symmetric key exchange to secure against

• Eavesdropping• Man-in-the-middle attack

• Trigger insertion• Name resolution

Trigger Insertion

PrivKeyFoo

i3

Host H(Foo)

IDFoo = H (PubKeyFoo)

PubKeyFoo = PK(MPKM, Foo) IDFoo H Foo

nonce

PubKeyfoo

Decrypt nonce with PrivKeyFoo

IDFoo H Foo nonce

IDFoo H

Insert trigger

Name Resolution

i3PrivKeyFoo

Send data encrypted with PubKeyFoo to trigger IDFoo

Decrypt sata using PrivKeyFoo

Sender S

IDFoo = H (PubKeyFoo)

PubKeyFoo = PK(MPKM, Foo)

data

PubKeyFoo

IDFoo H

Host H (Foo)

Identity Name Resolution: Discussion

• Pros– Local Name Resolution– Human readable and secure– Low overhead master server contacted

only at name allocation time– Secure from eavesdropping by i3 servers

• Cons– Requires centralized authority

• Hierarchical IBE has been proposed

– Must trust master server(s) – Key revocation is difficult

Proxy: Basic Design

Proxy Overlay(i3)

DNS reply: IPX idB

Host A (idA)

Host B (idB, Foo)

LA

Legacyprocess

DNS query: Foo

IPX

FooIPX

IPX idB

Proxy: Redesign

• Before– i3 centric design– Multithreaded

• Now– Modular design: can be used for other

overlays or ID-based networks• Resolution (name virtual IP address), packet

capture and translation are overlay independent

– Single-threaded: easier to port to handheld and cell phone OSes

Ongoing Projects

• Declarative routing (Boon Loo Thau)– Use i3 as a forwarding infrastructure

• Anonymity infrastructure (Jayanth Kannan)

• Load-aware location-aware server selection (Animesh Nandi, Rice University)

• Virtual LANs (U. of Tüebingen)• …

Platform for COPS Architecture

• COPS = “Check”+“Observe”+“Protect” Systems– See Randy’s talk this evening

• Create logical topologies to include processing elements (located at arbitrary locations) on data path

M

client Aserver B

i3

middle-box

idM MidBA B

idAB A

(idM:idBA, data)(idBA, data)

(idM:idAB, data)(idAB, data)

Plans For Next Six Months

• Release new i3 version (next few weeks)– Make it widely available– Check http://i3.cs.berkeley.edu for update

• Provide proxy support for other overlays– Network virtualization project

• Release a compelling application– Access to web servers behind NATs (?)

• Shape incoming traffic; provide anonymity

• Other applications– Anonymity, declarative queries, …

Moving Beyond i3

Platform forCOPS

Generalized proxy

OtherApplications…

i3

Routing as a Service

• Goal: develop network architectures that– Allow end-hosts to pick their own routes– Allow third-parties to easily add new

routing protocols• Ideal model:

– Oracles that have complete knowledge about network

– Hosts query paths from oracles• Path query can replace today’s DNS query

– Hosts forward packets along these paths

Routing as a Service (cont’d)

Routingservice 1

Client A

Client DClient B

Network measurements

Query/reply routing info.

Setup routes

Client C

Routing service 2

Service Composition

• Goal: allow third-parties and end-hosts to easily insert new functionality on data path– E.g., firewalls, NATs, caching, transcoding,

spam filtering, intrusion detection, etc..

• Why i3? – Make middle-boxes part of the architecture– Allow end-hosts/third-parties to explicitly

route through middle-boxes

Service Composition: Research Questions

• How to locate and compose services?

• How to distribute state across hosts and middle-boxes?

• How to transparently recover when a middle-box fails? How is the state recovered?

Conclusions

• i3: tremendously flexible infrastructure– Allow end-hosts to control routing and

replication points in the infrastructure – Abstract away the behavior of hosts

(e.g., mask mobility) form each other– Provide a global and flexible identifier

space• IDs can identify virtually anything, end-hosts,

services, sessions, humans, devices, etc..

Enable Many Applications

• Access to machines behind NATs• Transparent access to

services/machines behind firewalls– Like VPNs but more secure and flexible

• Protection against DoS attacks• Anycast• Transparent switching between two

interfaces • …

What We’ve Done Since Summer?

• Redesign some aspects of i3 based on user feedback– New version will be released in a few

weeks – Check http://i3.cs.berkeley.edu for

update

• Ultimate goal: – Increase the usability– Make i3 as an enabling technology for

future research projects

Ongoing & Future Projects

• Generalized proxy• Routing as a service• Service composition architecture

Collaborators

• Students:– Daniel Adkins– Jayanth Kannan– Karthik

Lakshminarayanan– Shelley Zhuang– Sonesh Surana

• Postdocs:– Klaus Wehrle (U.

Karlsruhe)

• Faculty:– Randy Katz– Scott Shenker– Klaus Wehrle (U.

of Tüebingen)

• Visitors:– Ayumu Kubota

(KDD Japan)