Supporting Legacy Applications in i3 Jayanthkumar Kannan, Ayumu Kubota, Karthik Lakshminarayanan, Ion Stoica, Klaus Wherle

Motivation Proliferation of overlay networks that offer new functionality Success of these ventures depends on how easily users can avail of functionality Two approaches 1)port app (or) write new app: eg: vic/vat over mbone, kazaa, overnet 2)allow existing legacy applications to use overlay: eg: RON, HIP. We explore the second approach in the context of i3

Supporting Legacy Apps in i3 Properties of our solution –Makes no change to app/ OS/ DNS/ NATs. –Preserves original IP header while supporting mobility and tunneling through NATs. –Allows users to refer to overlay entities using human readable names Existing work: RON, ROAM, AVES, TRIAD, HIP: none provide all these properties Basic technique: Address Virtualization –Fake one end of the communication to the other

Native Overlay Application Hosts/Services referred by overlay identifiers Apps implement overlay-specific protocol Packets contain source identifier, destination identifier N A N B Native app Overlay Host A (id A ) Host B (id B ) (id B,id A )

Native app L A Proxy N B Address Virtualization Idea: Emulate a native application to the overlay DNS query for name B DNS Reply: Reply with virtual address IP X Maintain mapping IP x  id B (overlay identifier for B) Packets sent by L A to IP x tunneled over overlay name B  id B IP X  id B B  IP X Overlay DNS query:name B DNS reply: IP X id B IP X

Name Resolution Name Resolution: name B  id B Three Alternatives: –Remote Resolution, Global Scope: Using DNS/DHT –Local Resolution, Global Scope: DHT-like hashing –Local Resolution, Local Scope: Address- book We chose address-book solution –Secure –No name allocation issues –PGP-like methods for convenience

LALA Proxy IP A IP VB →id B id B →IP VB IP VA →id A id A →IP VA IP F IP L IP PA Host A LBLB Proxy IP PB IP B Host B IP PB IP VA data dstsrc IP VB IP PA data dstsrc id B IP VB IP PA data IP F IP A IP VB IP PA data id B IP B IP L dstsrcIDdstsrc encapsulation IP header original IP header IP VB IP PA data id B IP L IP B Preserving IP headers Preserving IP headers: IP PA = IP VA,IP PB = IP VB Advantage: Applications like FTP, H323 work. Advantage: Network-layer middle-boxes work

Instantiation in i3 Identifier Allocation: Per communicating pair Public triggers id A,id B used for initial contact Private Triggers: –id AB : trigger inserted by A for receiving from B –id BA : trigger for other direction Allows host-specific policies(eg: DoS attacks) Can reduce number of triggers by anycast

Instantiation in i3 … Data Plane: –Encapsulation at sender –Packets from A  B: IP VB  id BA, id BA  IP VA –Decapsulation at Receiver Control Plane: Sets up these mappings: –Private trigger negotiation –Virtual address allocation Supports all types of NATs –No modification on data plane

Deployment Alternatives Local proxy at both ends Local proxy at client and remote proxy at server (say cnn.com) –remote proxy inserts triggers, performs flow setup on behalf on cnn.com Remote proxy at client and local/remote proxy at server –foo.i3.6to4.jp mapped to foo.i3 –DNS server returns address of waypoint machine which performs flow setup –Similar to AVES

i3-enabled legacy apps i3 Internet CNN.com Remote server proxy mobility i3 proxy Transparent access across Firewall/NAT i3 proxy Remote client proxy Internet Cafe Insert middle-box apps i3 proxy

Deployment Tradeoffs Local ProxyRemote Server Proxy Remote Client Proxy Access ReqdEnd-host DNS server Additional Infrastructure NoneDedicated Machine Waypoint Machines Preserving IP headers YesNo MobilityYesOnly ClientOnly Server NATted hostsYesOnly ClientOnly Server Name Resolution Local Resolution Remote DNS Resolution Allocation Authority

Applications Straightforward usage –Access home machines behind NATs –Anonymization: Relaying through i3 Secure access to machines behind firewalls –Using remote proxy + ssh-like authentication Middle-box apps: i3 allows interposition of any middle-box on path: –Implementation of intrusion detection using Bro –Advantage of preserving IP headers: Bro uses information in IP headers (if client cooperates) –Illustrates how to use legacy middle-box as well

Discussion Extensions: Generalization to other overlays Limitation: Cannot deal with transport layer functionality Implementation: Linux and WinXP versions available at Deployment: Over 3 months on Planetlab

Conclusions: Lessons we learnt Efficiency matters –Supplemented i3 with shortcuts for efficiency Usage is unexpected –At the last retreat, a Romanian professor was using the proxy to browse through port 80 filters! Routing infrastructure helps –Allows optimization for common cases (eg: NATs) Different users have different needs –Allow each user to choose his sweet spot

Local Proxy Configuration foo.i3  ID-foo bar.i3  ID-bar. foo.i3 i3 address book 1. DNS query for foo.i3 5. DNS Answer foo.i3 = i3 client proxy tun0 eth0 Virtual LAN on tun / obtain i3 ID 3. i3 trigger request/ confirmation for ID-foo 4. create a virtual host for foo.i3 with fake IP address send/receive IP packets from/to IP over i3 Hash(“foo.i3”) if not in address book CNN.com Legacy apps Linux/WinXP

Components Local proxy at both ends: IP IP communication over i3 Local proxy at client and i3  IP proxy for IP server (say cnn.com) –i3->IP proxy inserts triggers, performs flow setup on behalf on cnn.com Local proxy at server and IP  i3 proxy for IP client –foo.i3.6to4.jp mapped to foo.i3 –DNS server returns address of IP  i3 proxy which performs flow setup

Transparent Access Through Firewalls/NATs Every host/service can be associated with a globally unique i3 ID –Stitch together multiple IP address spaces Security –Cannot probe by random IP address –i3 IDs can be used as secret keys Can associate different i3 Ids for different services to perform ID-based filtering –ID space = 256 bits, lot harder to probe randomly Known i3-public IDs stored locally in address book –Security problems with DNS-like service.

Service Interposition Use i3 to redirect traffic through a middle-box –No need for middle-box to be on IP data path Applications: –Intrusion Detection Redirect traffic through a Bro server –Firewalls –Spam Filtering Redirect POP/IMAP traffic to spam filters –Enhanced Routing (OverQoS)

Implementation Status Linux and WinXP versions available at Limitations –NAT-unfriendly applications do not work i3 proxy rewrites source/destination IP addresses –Incorrect DNS caching by applications Caching despite zero TTL Future work –Implement middle-box applications (eg: Intrusion detection system, OverQoS) –i3 address book management (PGP-like?)

Demo Setting i3 proxy i3 Internet i3 proxy i3  IP proxy IP  i3 proxy sshd Transparent access across Firewall/NAT mobility support i3 proxy ssh http i3 proxy WinXP PDA Linux Zaurus WinXP Web client

How it works (1) Local & i3  IP proxy foo.i3  ID-foo bar.i3  ID-bar. foo.i3 i3 address book 1. DNS query for foo.i3 5. DNS Answer foo.i3 = i3 client proxy tun0 eth0 Virtual LAN on tun / obtain i3 ID 3. i3 trigger request/ confirmation for ID-foo 4. create a virtual host for foo.i3 with fake IP address send/receive IP packets from/to IP over i3 Hash(“foo.i3”) if not in address book CNN.com i3  IP proxy CNN.com Legacy apps Linux/WinXP

How it works (2) IP  i3 proxy 3. DNS answer DNS query foo.i3.6to4.jp 2. Trigger REQ/CNF :1023  abc.i3:22 tcp :2000  xyz.i3:993 tcp * : *  foo.i3 : * :1234  foo.i3:22 tcp IP packet :1234  :22 tcp 6. Register the flow info 7. i3 packet Prv ID(proxy)  Prv ID(foo.i3) :1234  foo.i3:22 tcp 4. Create a flow entry and start waiting (1 second) IP  i3 proxy Flow information i3 proxy foo.i3 Map *.i3 to real DNS domain e.g. *.i3.cs.berkeley.edu Currently we use *.i3.6to4.jp i3 DNS server IP client

i3 revisited i3 modified to address user concerns Efficiency concerns: Shortcuts: allow packets to circumvent i3 Fragmented address space concerns (NATs): –Modified control protocol to accommodate all types of NATs –No overhead on data plane