i3 update ion stoica and many others… uc berkeley january 10, 2005
Post on 20-Dec-2015
215 views
TRANSCRIPT
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, …
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