OCALA: An Architecture for Supporting Legacy Applications over Overlays Dilip Antony Joseph 1, Jayanth Kannan 1, Ayumu Kubota 2, Karthik Lakshminarayanan 1, Ion Stoica 1, Klaus Wehrle 3 1 UC Berkeley, 2 KDDI Labs, 3 University of Tübingen

Motivation Efforts to change Internet infrastructure not successful –Mobile IP, IP multicast, Intserv Overlays provide new features without changing the Internet –RON : resilience to path failures –i3 : mobility, NAT traversal, anycast, multicast –OverQOS : quality of service But still no widespread deployment Inertia in shifting to a new application Enable popular applications (Firefox, IE, samba, ssh) to benefit from overlay

Legacy Applications on Overlays Approach 1 : rewrite/port apps for each new overlay –time-consuming, tedious, impossible for closed source apps Approach 2 : enable support for legacy applications on multiple overlays

Goals Transparency –Legacy apps unaware of overlay Inter-operability –Hosts in different overlays should be able to talk to each other Expose Overlay Functionality –User control over which overlay to use, what overlay specific properties to use Factor out common requirements –Security, compression

Overlay Convergence Architecture for Legacy Applications (OCALA) Overlay Convergence (OC) Layer Overlay (DOA, DTN, HIP, i3, RON, …) Overlay (DOA, DTN, HIP, i3, RON, …) 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.

Simultaneous access to multiple overlays OC-I i3 Firefox OC-I RON ssh RON IRC ssh … OC-D i3 RON Internet … OC-I i3 IRC … Host A Host B Host C IP

Naming DNS-like names to identify machines (or services) berkeley.pl.i3 berkeley Interpreted by OC-I OC-I uses suffix to invoke corresponding OC-D instance Overlay type Overlay instance.pl.i3 Overlay specific name OC-I OC-D Transport Overlay OC-D resolution mechanism –Overlay specific (e.g., hashing names to IDs in i3) –General (e.g., OpenDHT, DNS, address book) –Identity mapping: OC-D names can be just flat IDs Configuration file to store user preferences Interpreted by OC-D OC-D resolves this name to an overlay specific ID/Addr (e..g, i3 ID, HIT, EID, IP addr)

Bridging Overlays Application at host A issues a DNS request for foo.ron_bar.i3 A sets up tunnel to bar.i3 (B) over i3. B sets up tunnel to foo.ron (C) over RON. Path from A to C consisting of the two tunnels. OC-I Host A Appl. OC-I Host C (foo.ron) Appl. OC-I Host B (bar.i3) i3 OC-D i3RON i3 RON tunnel path

Legacy Server Gateways Server need not run OCALA locally Special OC-D module called Legacy Server IP (LSIP) at gateway LSIP behaves like a software NAT box OC-I Appl. OC-I OV LSIP Legacy gateway Overlay (OV) Internet Overlay client OV Legacy server ( *.gov  OV … Configuration file

Legacy Client Gateways Clients need not run OCALA locally Gateway has special Legacy Client IP (LCIP) module OC-I Appl. OC-I LCIP OV Legacy gateway Overlay (OV) Internet Legacy Client OV Overlay server (foo.ov) DNSreq(foo.ov.ocalaproxy.net)

Legacy Client Gateway Demo Home machine behind NAT running OCALA. Legacy Client Gateway running OCALA. No modification to NAT. Client (your web browser) does not run OCALA.

Design

Setting up a new connection Legacy App. Transport Layer OC-I Layer OC Layer 1 DNSreq(foo.ov) Name Res. Service (local addrbook, DNS, OpenDHT…) Host A Host B (foo.ov, ID B ) Overlay (DTN, i3, RON) i3RON … 2 setup(foo.ov) 3 resolve(foo.ov) 4 ID B 5 overlay specific setup protocol DNSresp(oc_handle = IP AB ) 8 tunnel_d = td AB 6 1.x.x.x OCI-Setup (pd AB ) 7

Data Flow Overlay (DTN, i3, RON) pd AB ↔ IP AB pd AB  td AB td AB  ID B Legacy App. Transport Layer IP AB datapd AB data IP AB td AB, pd AB dataIP AB ID B pd AB ↔ IP BA td BA  ID A Legacy App. Transport Layer IP BA datapd AB data IP AB Host A (ID A )Host B (foo.ov, ID B ) OC-I OC-D OC-I “foo.ov”  pd AB pd AB  td BA

Overlay Dependent Layer API exposed by OC-D to OC-I layer –Setup (tunnel_info) –Close (tunnel_d) –Send (tunnel_d, pkt) Callbacks from OC-D to OC-I –SetupDone (tunnel_d) –Recv(pkt) i3, RON modules implemented

Applications

Simultaneous access to multiple overlays Overlay composition –Allows user to merge functionality of various overlays –Eg: Wireless internet access using i3 over the wireless hop and RON over the wide area. Applications enabled by new overlays –Receiver imposed middleboxes –NAT traversal

Receiver Imposed Middleboxes OC-I i3 Appl. OC-I i3 Appl. OC-I i3 foo.i3 i3 Host A Bro Receiver (foo.i3) enforces all traffic to pass through a middlebox using overlay functionality (e.g., i3) Demonstration of receiver imposed Bro Intrusion Detection System during poster session Sets up connection to foo.i3

NAT Traversal Application Using i3 servers as a relaying point Allows direct communication between NATed hosts Demo during poster session NAT Box i3

Implementation Implemented as a proxy –tun device used to capture packets Works on Linux and Windows XP/2000 (using cygwin) Implemented RON and i3 OC-D modules. –200 lines of glue code in case of RON Security –Authentication and Encryption using an ssl-like protocol extended to accommodate middleboxes

Limitations Applications sending IP addresses in packet payload may fail –Example: ftp, SIP Increase in packet size due to new headers Legacy applications cannot leverage all overlay features –Example: multicast

Conclusion Overlays are a means to overcome the “Internet Impasse”. OCALA enables legacy applications to benefit from the new features offered by new network architectures. OCALA enables interoperability between different network architectures. Generic proxy implementation.

Thank you More information and proxy download at

Sender Imposed Middleboxes OC-I i3 Appl. OC-I i3 Appl. foo.i3 i3 Host A Sender wishes to force traffic to go through a transcoder not directly on the path. OC-I i3 mytranscoder.i3 Transcoder Sender wishes to communicate with foo.i3. Sets up connection to foo.i3 Sets up connection to foo.i3_mytranscoder.i3

Transparent use of Overlays Make legacy apps oblivious to overlays  preserve standard IP interface OC needs to decide which overlay to use –IP address and port number: E.g., forward all packets to port 80 over RON Advantage: works with all applications Disadvantage: hard to remember and configure –DNS name: E.g., forward all packets sent to berkeley.ron over RON Advantages: human readable, flexible Disadvantage: some applications don’t use DNS names

????

Goal 1: Achieving Transparency Make legacy apps oblivious to overlays –Preserve standard IP interface Deciding which overlay to use –IP address and port number : E.g., forward all packets sent to port 80 over RON –DNS name: E.g., forward all packets sent to berkeley.ron over RON Human readable Easy to encode user preferences

Goal 3: Customizing Overlay Functionality Overlays have customizable parameters –Example: OverQoS – maximum acceptable latency, RON – which routing metric (loss, throughput) to use, i3 – enable shortcut Encode preferences in DNS name –Example: berkeley.mindelay.ron –Example: berkeley.maxbwdth.ron –Max 255 characters –Long names are inconvenient Use regular expressions in configuration files

Customizing Overlay Functionality OC-I i3 Firefox OC-I RON ssh RON ftp ssh … OC-D i3 RON Internet … Host A Host B IP berkeley.mindelay.ron ftp berkeley.maxbwdth.ron

Goal 4: Common functionality Functionality required by multiple overlays implemented in the OC-I layer Example: Security –Similar to SSL –Modifications for supporting middleboxes

Overlay Convergence Architecture for Legacy Applications Overlay Convergence (OC) Layer Overlay (DOA, DTN, HIP, i3, RON, …) Overlay (DOA, DTN, HIP, i3, RON, …) 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.

Overlay Dependent Layer API exposed by OC-D to OC-I layer –Setup (tunnel_info) –Close (tunnel_d) –Send (tunnel_d, pkt) Callbacks from OC-D to OC-I –SetupDone (tunnel_d) –Recv(pkt) i3, RON modules implemented

i3 Middlebox Demo OC-I i3 Firefox OC-I i3 apache OC-I i3 Middlebox M Hello.i3 i3 Client BRO

i3 Web Server R hello.i3 id M,id R id hello Middlebox M BRO IDS IP M id M IP R id R Client Web Browser id hello data id hello data id hello data id hello data id hello data i3 Middlebox Demo

Home NAT Box NAT Traversal Demo i3 Client IP R id R data id R data Receiver R

Interfacing middleboxes OC-I i3 Appl. OC-I i3 Appl. OC-I i3 Host M (mbox.i3) Host C (foo.i3) i3 Host A Middlebox Middleboxes cleanly fit into the OC architecture.

Evaluation Micro-benchmarks –~20 μs overhead each for tun, OC-D and OC-I layers –DNS lookup latency First time : 169 μs From cache: 15 μs LAN experiments –Throughput close to that of pure IP. –Latency less than double that of pure IP. Wide Area experiments –Throughput close to that of pure IP. –No increase in latency.

Example Configuration File All traffic going to URLs containing “berkeley” or ending with “.gov” should first go through a firewall over i3 and then to the destination over RON. <Security protocol = "custom SSL" mode = "endhostonly" /> <Compression algo = "zlib" level = "5" /> <Hop overlayId = "PlanetLab.i3" HopEndPointName = “firewall1.berkeley.edu.i3" > <Hop overlayId = "PlanetLab.i3" HopEndPointName = “RON_i3_Gateway.berkeley.edu.i3" /> <Hop overlayId = "ron.PlanetLab" />

Micro-benchmarks Per-packet overhead while sending data μsμs i3RON No EncryptionEncryptionNo EncryptionEncryption OC-I OC-D20 28 tun Per-packet overhead while receiving data μsμs i3RON No EncryptionEncryptionNo EncryptionEncryption OC-I OC-D Tun DNS lookup overhead –First time = 169 microseconds –From cache = 15 microseconds

LAN Experiments 2 proxies on the same LAN millisecondsi3i3-shortcutRONIP No-Encryption Encryption NA kbpsi3i3-shortcutRONIP No-Encryption Encryption NA Latency Throughput

Wide Area Experiments Proxies running at 3 different locations. RON and i3-with-shortcut have latency close to pure IP.

Wide Area Experiments (contd.) RON and i3-with-shortcut throughput >= 75% of throughput of pure IP Anomalous behavior of packets sent to A