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 idR trigger iddata Receiver (R) iddata R

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 aggregation Identity 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 aggregation Identity 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 LALA LBLB id BA A 1 Host A (IP B )Host B 3 1 (id BA,data) cache=IP B 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 PrivKey foo Receiver R (Foo) W W W Sender S Publish Master Public Key (MPK M ) Request private key for Foo. Obtain MPK M PubKey Foo = PK(MPK M, Foo) Send PrivKey Foo message PubKey Foo

Identity Based Resolution: IBE Application to i3 Name allocation –FCFS policy based allocation (see poster!) –Use symmetric key exchange to secure against Eavesdropping Man-in-the-middle attack Trigger insertion Name resolution

Trigger Insertion PrivKey Foo i3 Host H (Foo) ID Foo = H (PubKey Foo ) PubKey Foo = PK(MPK M, Foo) ID Foo H Foo nonce PubKey foo Decrypt nonce with PrivKey Foo ID Foo H Foo nonce ID Foo H Insert trigger

Name Resolution i3 PrivKey Foo Send data encrypted with PubKey Foo to trigger ID Foo Decrypt sata using PrivKey Foo Sender S ID Foo = H (PubKey Foo ) PubKey Foo = PK(MPK M, Foo) data PubKey Foo ID Foo 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: IP X id B Host A (id A ) Host B (id B, Foo) LALA Legacy process DNS query: Foo IP X Foo  IP X IP X  id B

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 A server B i3 middle-box id M M id BA B id AB A (id M :id BA, data) (id BA, data) (id M :id AB, data) (id AB, data)

Plans For Next Six Months Release new i3 version (next few weeks) –Make it widely available –Check 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 for COPS Generalized proxy Other Applications… 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) Routing service 1 Client A Client D Client 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 for updatehttp://i3.cs.berkeley.edu 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)