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

2. Motivation インターネットインフラストラクチャの改変は成功して いない –Mobile IP, IP multicast, Intserv オーバレイネットワークはインターネットを改変せずに 新しい機能を提供できる –RON : resilience to path failures –i3 : mobility, NAT traversal, anycast, multicast –OverQOS : quality of service しかし普及している実装はない 少しずつ普及させたい そのために、一般的なアプリケーションをオーバレイ ネットワークで利用できればよい (Firefox, IE, samba, ssh)

3. Legacy Applications on Overlays Approach 1 : アプリケーションの再実装 – 時間がかかる、面倒である、クローズドソー スだと不可能である Approach 2 : そのままアプリケーションが 実行可能なオーバレイネットワークの作 成

4. Goals 透過性 –Legacy apps unaware of overlay 相互運用性 –Hosts in different overlays should be able to talk to each other 個々のオーバレイの機能を利用可能 –User control over which overlay to use, what overlay specific properties to use 一般的な要求事項の抽出 –Security, compression

5. 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 Transport Layer とオーバレイの間に Overlay Convergence Layer が割り込む.

6. 複数のオーバレイネットワークへ の 同時アクセス 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 Host B Host C IP

7. Naming DNS のような名前の割り当て 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 解決アルゴリズム – オーバレイ特有 (e.g., hashing names to IDs in i3) – 一般的な手法 (e.g., OpenDHT, DNS, address book) –ID マッピング : OC-D で利用されているフラットな ID を用いる Interpreted by OC-D OC-D resolves this name to an overlay specific ID/Addr (e..g, i3 ID, HIT, EID, IP addr)

8. Bridging Overlays ホスト A のアプリケーションが foo.ron_bar.i3 への DNS リクエストをだす A は bar.i3 (B) over i3 へのトンネル作成 B は RON を解した foo.ron (C) へのトンネルを作成 パスの構築完了 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

9. Legacy Server Gateways サーバーは OCALA をローカルで動作させる必要はない Legacy Server IP (LSIP) と呼ばれる Special OC-D モ ジュールを用いる LSIP は NAT のような働きをする OC-I Appl. OC-I OV LSIP Legacy gateway Overlay (OV) Internet Overlay client OV Legacy server (www.nasa.gov) *.gov  OV … Configuration file

10. Legacy Client Gateways 同様にクライアントも OCALA をローカルで動か す必要はない ゲートウェイに Legacy Client IP (LCIP) モ ジュール OC-I Appl. OC-I LCIP OV Legacy gateway Overlay (OV) Internet Legacy Client OV Overlay server (foo.ov) DNSreq(foo.ov.ocalaproxy.net)

11. Design

12. 新規接続の確立 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

13. データの流れ 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

14. Overlay Dependent Layer OC-D が OC-I に提供する API –Setup (tunnel_info) –Close (tunnel_d) –Send (tunnel_d, pkt) OC-D によって呼ばれる OC-I のコールバッ ク関数 –SetupDone (tunnel_d) –Recv(pkt) i3, RON モジュールを実装

15. Applications

16. 複数のオーバレイネットワークへの同時アクセ ス オーバレイの構成 – 複数のオーバレイをユーザは選択して利用できる –Eg: ワイヤレス通信は i3 経由で、ワイドエリア通信は RON 経由で Applications enabled by new overlays –Receiver imposed middleboxes –NAT traversal

17. Receiver Imposed Middleboxes OC-I i3 Appl. OC-I i3 Appl. OC-I i3 foo.i3 i3 Host A Bro 受信者 (foo.i3) はすべてのトラフィックをオーバレイの機 能を用いてミドルボックスを経由して通信するようにする (e.g., i3) Sets up connection to foo.i3

18. NAT Traversal Application I3 サーバを中継に利用する NAT 下同士のノードの直接通信を実現 NAT Box i3

19. 実装 プロキシとして実装 –tun device used to capture packets Linux and Windows XP/2000 (using cygwin) 上で実装 RON and i3 OC-D モジュールを実装 セキュリティ –SSL のような認証および暗号化

20. 制限 パケットの中に IP アドレスを含むものは失 敗する –Example: ftp, SIP OCALA 専用ヘッダによってオーバヘッド が発生する 従来のアプリケーションは、オーバレイ の新しい機能を利用できない –Example: multicast

21. まとめ オーバレイは “Internet の行き詰まり ” を打 破する OCALA は従来のアプリケーションを、新 しいオーバレイネットワーク上で、新し い機能を用いて動作可能にする OCALA は異なるオーバレイネットワーク の相互運用を可能にする. 一般的なプロキシとして実装

22. Thank you More information and proxy download at http://i3.cs.berkeley.edu

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

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

25. ????

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

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

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

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

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

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

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

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

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

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

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

37. 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" />

38. Micro-benchmarks Per-packet overhead while sending data μsμs i3RON No EncryptionEncryptionNo EncryptionEncryption OC-I19931891 OC-D20 28 tun242524 Per-packet overhead while receiving data μsμs i3RON No EncryptionEncryptionNo EncryptionEncryption OC-I884682 OC-D44433635 Tun16201516 DNS lookup overhead –First time = 169 microseconds –From cache = 15 microseconds

39. LAN Experiments 2 proxies on the same LAN millisecondsi3i3-shortcutRONIP No-Encryption1.420.7880.7620.488 Encryption1.741.131.06NA kbpsi3i3-shortcutRONIP No-Encryption9589105041002211749 Encryption541556155445NA Latency Throughput

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

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