OCALA: An Architecture for Supporting Legacy Applications

over Overlays

Dilip Joseph1, Jayanth Kannan1,

Ayumu Kubota2, Karthik Lakshminarayanan1, Ion Stoica1, Klaus Wehrle3

1UC Berkeley, 2KDDI Labs, 3RWTH Aachen University

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

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

Simultaneous access to different overlays

FirefoxFirefox

sshdsshd

www.cnn.com

IRCIRC sshssh

i3RON

Internet

IRCIRCHost A (San Jose)

Host B (India)

Host C (China)

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

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

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

Contents

Introduction

Design

Applications

Implementation

Conclusion

Overlay Convergence Architecture for Legacy Applications (OCALA)

Overlay Convergence (OC) LayerOverlay 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

Interpose an Overlay Convergence Layer between transport layer and overlay networks

Application LayerApplication Layer

Transport LayerTransport Layer

Network LayerNetwork Layer

Link LayerLink Layer

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

Legacy App.

Transport Layer

Host A (IDA)

OC-I

OC-D

Setting up a new connection

i3

Legacy App.

Transport Layer

Host B (ucb.i3, IDB)

OC-I

OC-D

1 DNSreq(ucb.i3)

2 setup(ucb.i3)

Name Res. Service (local addrbook,

DNS, OpenDHT…)

3 resolve(ucb.i3)

RONi3 RON … i3 RON …

4 IDB

5 overlay specificsetup protocol

tdAB IDB tdBAIDA

i3 i3

tunnel_d = tdAB6

OCI-Setup (pdAB)7pdAB ↔ IPAB

pdAB tdAB

“ucb.i3” pdAB pdAB ↔ IPBA

pdAB tdBA

DNSresp(IPAB)8

1.0.0.0/8

Legacy App.

Transport Layer

Host B (ucb.i3, IDB)

OC-I

OC-Di3

Legacy App.

Transport Layer

Host A (IDA)

OC-I

OC-Di3

Data Flow

i3

tdAB IDB tdBAIDA

pdAB ↔ IPAB

pdAB tdAB

“ucb.i3” pdAB pdAB ↔ IPBA

pdAB tdBA

IPAIPAB data

tdAB, pdAB dataIPAIPAB

pdAB dataIPAIPABIDB

pdAB dataIPAIPAB

IPBA IPB data

Simultaneous access to different overlays

OC-IOC-I

i3

FirefoxFirefox

OC-IOC-I

RON

sshssh

www.cnn.com

RON

IRCIRC sshssh

…

OC

-D

i3RON

Internet

…OC-IOC-I

i3

IRCIRC

…

Host A (San Jose)

Host B (India)iitm.ac.in.ron

Host C (China)chinairc.i3

IP

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

RONi3 RON

*.ron sfgateway.i3

Contents

Introduction

Design

Applications

Implementation

Conclusion

Applications

• New functionality enabled by the overlay

• Example: i3 enables hosts to force all incoming traffic through off-path middleboxes

Demo

i3

Webserverdilip-secure.pli3

Remote Client ProxyR

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)

Applications

• Robust connections over RON

• Access to machines behind NATs using i3

• OCALA Secure Connection– Unsecured wireless prone to eavesdropping

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

Contents

Introduction

Design

Applications

Implementation

Conclusion

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

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

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

• …

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

Thank you

http://ocala.cs.berkeley.edu