OCALA: An Architecture for Supporting Legacy Applications

over Overlays

Dilip Antony Joseph1, Jayanth Kannan1, Ayumu Kubota2, Karthik Lakshminarayanan1, Ion

Stoica1, Klaus Wehrle3

1UC Berkeley, 2KDDI Labs, 3University 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) LayerOverlay 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-IOC-I

i3

FirefoxFirefox

OC-IOC-I

RON

sshssh

www.cnn.comRON

IRCIRC sshssh

…

OC

-D

i3RON

Internet

…OC-IOC-I

i3

IRCIRC

…

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

i3 RONi3 RON

RON

tunnel 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(www.nasa.gov)

*.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

http://flute.i3.6to4.jp:8080/

• 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 LayerOC-I Layer

OC LayerOC Layer

1 DNSreq(foo.ov)

Name Res. Service (local addrbook,

DNS, OpenDHT…)

Host A

Host B (foo.ov, IDB)

Overlay(DTN, i3, RON)

i3 RON …

2 setup(foo.ov)

3 resolve(foo.ov)

4 IDB5 overlay specific

setup protocol

DNSresp(oc_handle = IPAB)8

tunnel_d = tdAB6

1.x.x.x

OCI-Setup (pdAB)7

Data Flow

Overlay(DTN, i3, RON)

pdAB ↔ IPAB

pdAB tdAB

tdAB IDB

Legacy App.

Transport Layer

IPAB data

pdAB dataIPABtdAB,

pdAB dataIPABIDB

pdAB ↔ IPBA

tdBAIDA

Legacy App.

Transport Layer

IPBA data

pdAB dataIPAB

Host A (IDA) Host B (foo.ov, IDB)

OC-I

OC-D OC-D

OC-I“foo.ov” pdAB

pdAB tdBA

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

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-IOC-I

i3

Appl.Appl.

OC-IOC-I

i3

Appl. Appl.

OC-IOC-I

i3

foo.i3

i3

Host A

Bro 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 http://i3.cs.berkeley.edu

Sender Imposed Middleboxes

OC-IOC-I

i3

Appl.Appl.

OC-IOC-I

i3

Appl. Appl.

foo.i3

i3

Host A

• Sender wishes to force traffic to go through a transcoder not directly on the path.

OC-IOC-I

i3

mytranscoder.i3

Transcoder 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 64.236.24.8 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 64.236.24.8 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-IOC-I

i3

FirefoxFirefox

OC-IOC-I

RON

sshssh

RON

ftpftp sshssh

…

OC

-D

i3RON

Internet

…

Host A

Host B

IP

berkeley.mindelay.ron

ftpftp

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) LayerOverlay 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-IOC-I

i3

FirefoxFirefox

OC-IOC-I

i3

apacheapache

OC-IOC-I

i3

Middlebox M Hello.i3

i3

Client

BRO BRO

i3

Web Server Rhello.i3

idM,id

R

idhello

Middlebox MBRO IDS

IPMidM

IPRidR

ClientWeb Browser

idhellodata

idhellodata

idhellodata

idhellodata

idhellodata

i3 Middlebox Demo

Home NAT Box

NAT Traversal Demo

i3

Client

IPRidR

idRdata

idRdata

Receiver R

Interfacing middleboxes

OC-IOC-I

i3

Appl.Appl.

OC-IOC-I

i3

Appl. Appl.

OC-IOC-I

i3

Host M (mbox.i3) Host C (foo.i3)

i3

Host A

Middlebox 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 FileAll 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.

<PathInfo > <Match urlPattern = "*berkeley*" /> <Match urlPattern = "*.gov" /> <Security protocol = "custom SSL" mode = "endhostonly" />

<Compression algo = "zlib" level = "5" />

<Hop overlayId = "PlanetLab.i3" HopEndPointName = “firewall1.berkeley.edu.i3"

><Property name = “shortcut” value = “enabled” />

</Hop><Hop

overlayId = "PlanetLab.i3" HopEndPointName = “RON_i3_Gateway.berkeley.edu.i3"

/><Hop

overlayId = "ron.PlanetLab" />

</PathInfo>

Micro-benchmarksPer-packet overhead while sending data

μs i3 RONNo Encryption Encryption No Encryption Encryption

OC-I 19 93 18 91

OC-D 20 20 28 28

tun 24 25 24 24

Per-packet overhead while receiving dataμs i3 RON

No Encryption Encryption No Encryption Encryption

OC-I 8 84 6 82

OC-D 44 43 36 35

Tun 16 20 15 16

• DNS lookup overhead– First time = 169 microseconds– From cache = 15 microseconds

LAN Experiments• 2 proxies on the same LAN

milliseconds i3 i3-shortcut RON IP

No-Encryption 1.42 0.788 0.762 0.488

Encryption 1.74 1.13 1.06 NA

kbps i3 i3-shortcut RON IP

No-Encryption 9589 10504 10022 11749

Encryption 5415 5615 5445 NA

Latency

Throughput

Wide Area Experiments

0

20

40

60

80

100

120

140

A --> B B --> A A --> C C --> A B --> C C --> B

Lat

ency

(m

s)

i3 i3-shortcut RON IP

• Proxies running at 3 different locations.• RON and i3-with-shortcut have latency close

to pure IP.

Wide Area Experiments (contd.)

0

5000

10000

15000

20000

25000

30000

35000

A --> B B --> A A --> C C --> A B --> C C --> B

Th

rou

gh

pu

t (k

bp

s)

i3 i3-shortcut RON IP

• RON and i3-with-shortcut throughput >= 75% of throughput of pure IP

• Anomalous behavior of packets sent to A