1. OCALA: An Architecture for Supporting Legacy Applications over Overlays Dilip Joseph 1, Jayanth Kannan 1, Ayumu Kubota 2, Karthik Lakshminarayanan 1, Ion Stoica 1, Klaus Wehrle 3 1 UC Berkeley, 2 KDDI Labs, 3 RWTH Aachen University

2. Motivation Efforts to change Internet : limited success –IP multicast, QoS Overlays provide new features without changing the Internet –Resilient Overlay Networks (RON) : resilience to path failures –Internet Indirection Infrastructure (i3) : mobility, NAT traversal, anycast, multicast But still no widespread deployment –Users unwilling to shift to new application programs –No interoperability between different overlays

3. Goal 1 – Legacy Application Support Enable legacy applications to work over new network architectures and overlays –Applications that work on IP –Unmodified –Users choose the best overlay for a particular application

4. Simultaneous access to different overlays Firefox sshd www.cnn.com IRC ssh i3 RON Internet IRC Host A (San Jose) Host B (India) Host C (China)

5. Goal 2 - Interoperability Enable hosts in different overlays to talk to each other –Interoperability between hosts in different overlays –Interoperability between overlay hosts and pure IP hosts –Combined benefits of different overlays

6. RON Stitching together different overlays Mobility of i3 available for the first hop to the gateway Robustness of RON available for the second hop to the final destination Host A (Berkeley) ssh Host B (India) sshd Gateway (SFO) i3

7. Goal 3 – Factoring out Common Functionality Lower barrier of providing support for legacy applications over new overlays –Concentrate on architecture; not on supporting legacy applications –Factor out common functionality Example: Authentication & encryption –Plug-in overlays into a common framework

8. Contents Introduction  Design  Applications  Implementation  Conclusion

9. Overlay Convergence Architecture for Legacy Applications (OCALA) Overlay Convergence (OC) Layer Overlay ( i3, RON, DOA, HIP …) Overlay ( i3, RON, DOA, HIP …) Legacy Applications (ssh, firefox, explorer, …) Legacy Applications (ssh, firefox, explorer, …) Transport Layer (TCP, UDP, …) Transport Layer (TCP, UDP, …) OC Independent (OC-I) Sublayer OC Dependent (OC-D) Sublayer Interpose an Overlay Convergence Layer between transport layer and overlay networks Application Layer Transport Layer Network Layer Link Layer

10. Expressing which overlay to use DNS-like names to identify machines (or services) ucb.i3 Interpreted by OC-I OC-I uses suffix to invoke corresponding OC-D instance OC-I OC-D Transport Overlay OC-D resolution mechanism –General (e.g., OpenDHT, DNS, address book) –Overlay specific (e.g., hashing names to IDs in i3) Configuration file –Support applications not using DNS names –Store user preferences Interpreted by OC-D OC-D resolves this name to an overlay specific ID/Address

11. Legacy App. Transport Layer Host A (ID A ) OC-I OC-D Setting up a new connection i3 Legacy App. Transport Layer Host B (ucb.i3, ID B ) OC-I OC-D 1 DNSreq(ucb.i3) 2 setup(ucb.i3) Name Res. Service (local addrbook, DNS, OpenDHT…) 3 resolve (ucb.i3) RON i3RON … i3RON … 4 ID B 5 overlay specific setup protocol td AB  ID B td BA  ID A i3 tunnel_d = td AB 6 OCI-Setup (pd AB ) 7 pd AB ↔ IP AB pd AB  td AB “ucb.i3”  pd AB pd AB ↔ IP BA pd AB  td BA DNSresp(IP AB ) 8 1.0.0.0/8

12. Legacy App. Transport Layer Host B (ucb.i3, ID B ) OC-I OC-D i3 Legacy App. Transport Layer Host A (ID A ) OC-I OC-D i3 Data Flow i3 td AB  ID B td BA  ID A pd AB ↔ IP AB pd AB  td AB “ucb.i3”  pd AB pd AB ↔ IP BA pd AB  td BA IP A  IP AB data td AB, pd AB data IP A  IP AB pd AB dataIP A  IP AB ID B pd AB dataIP A  IP AB IP BA  IP B data

13. Simultaneous access to different overlays OC-I i3 Firefox OC-I RON ssh www.cnn.com RON IRC ssh … OC-D i3 RON Internet … OC-I i3 IRC … Host A (San Jose) Host B (India) iitm.ac.in.ron Host C (China) chinairc.i3 IP

14. Stitching together different overlays A sets up tunnel to sfgateway.i3 over i3. B sets up tunnel to iitm.ac.in.ron over RON. OC-I Host A (Berkeley) ssh OC-I Host B (India) iitm.ac.in.ron sshd OC-I Gateway (SFO) sfgateway.i3 i3 OC-D i3 RON i3 RON *.ron  sfgateway.i3

15. Contents Introduction Design  Applications  Implementation  Conclusion

16. Applications New functionality enabled by the overlay Example: i3 enables hosts to force all incoming traffic through off-path middleboxes

17. Demo i3 Webserver dilip-secure.pli3 Remote Client Proxy R Web Browser GET dilip-secure.pli3.ocalaproxy.net GET dilip-secure.pli3 Bro Middlebox (In office) GET dilip-secure.pli3 Internet Communication between non-overlay host and overlay host Web server dilip-secure.pli3 imposes Bro IDS on its path using i3 (At home)

18. Applications Robust connections over RON Access to machines behind NATs using i3 OCALA Secure Connection –Unsecured wireless prone to eavesdropping

20. Applications Robust connections over RON Access to machines behind NATs using i3 OCALA Secure Connection –Unsecured wireless prone to eavesdropping –Use encrypted tunnel to gateway –Similar to Google secure wifi

21. Contents Introduction Design Applications  Implementation  Conclusion

22. Implementation A user-level proxy tun device used to capture packets Linux, Windows XP and Mac OS X – 40k SLOC of C++ OC-D modules –Dynamically loadable libraries –Simple 5 function call interface – less than 200 lines of glue code –i3, RON OC-D modules written internally –Host Identity Protocol (Andrei Gurtov, HIIT, Helsinki) –Delegation Oriented Architecture (Evelyn Eastmond, Daniel Wendel, Lev Popov, MIT) –OverDoSe (Runting Shi, CMU) GUI for configuring OCALA written in Java

23. Overheads and Limitations OC-I headers – 14 bytes Micro-benchmarks –OC-I : 40 microseconds per packet –i3, RON OC-Ds : 20-30 microseconds per packet LAN experiments –90% of the TCP throughput over direct IP Packet rewriting  FTP, SIP will not work

24. Related Work Overlay-specific application support: –RON, i3, HIP Stitching together multiple address spaces: –AVES, TRIAD, UIP OASIS (U. Wash. & U. Mass.) –Provide isolation, but no interoperability …

25. Conclusion Enable evaluation of new architectures with real users and real applications –Simplify legacy application support –Bring benefits of new architectures to real users http://ocala.cs.berkeley.edu

26. Thank you http://ocala.cs.berkeley.edu