OCALA: An Architecture for Supporting Legacy Applications over Overlays

1
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
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
Host B (India)
Host C (China)
sshd
Host A (San Jose)
IRC
Firefox
IRC
ssh
RON
i3
Internet
www.cnn.com
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
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)
Host B (India)
Gateway (SFO)
ssh
sshd
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)
Interpose an Overlay Convergence Layer between
transport layer and overlay networks
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

Transport
OC-I
OC-D

• Interpreted by OC-D
• OC-D resolves this name
• to an overlay specific
• ID/Address

• 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

Overlay
11
Setting up a new connection
1.0.0.0/8
i3
12
Data Flow
ucb.i3 ? pdAB
pdAB ? IPBA
pdAB ? IPAB pdAB ? tdAB
pdAB ? tdBA
tdAB ?IDB
tdBA?IDA
i3
13
Simultaneous access to different overlays
Host B (India) iitm.ac.in.ron
Host C (China) chinairc.i3
ssh
Host A (San Jose)
IRC
OC-I
Firefox
IRC
ssh
OC-I

RON

OC-I
i3

OC-D
i3
RON
IP
RON
i3
Internet
www.cnn.com
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.

Host B (India) iitm.ac.in.ron
Host A (Berkeley)
Gateway (SFO) sfgateway.i3
ssh
sshd
.ron ? sfgateway.i3
OC-I
OC-I
OC-I
OC-D
i3
RON
i3
RON
i3
RON
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

• Communication between non-overlay host and
  overlay host
• Web server dilip-secure.pli3 imposes Bro IDS on
  its path using i3

GET dilip-secure.pli3.ocalaproxy.net
i3
GET dilip-secure.pli3
GET dilip-secure.pli3
Internet
(At home)
18
Applications

• Robust connections over RON
• Access to machines behind NATs using i3
• OCALA Secure Connection
• Unsecured wireless prone to eavesdropping

19
(No Transcript)
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