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

NA N

B

Native app Native app

Overlay

Host A ( idA) Host B ( id

B)

(idB,idA)

Native app

LA

ProxyN

B

Address Virtualization

• Idea: Emulate a native application to the overlay

• DNS query for nameB

• DNS Reply: Reply with virtual address IPX

• Maintain mapping IPx idB (overlay identifier for B)

• Packets sent by LA to IPx tunneled over overlay

nameB id

B

IPX id

B

idB

IPX

Overlay

DNS query: nameB

DNS reply: IPX

idB

IPX

Name Resolution

• Name Resolution: nameB idB

• 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

LA

Proxy

IPA

IPVB→idB

idB→IPVB

IPVA→idA

idA→IPVA

IPF

IPL

IPPA

Host A

LB

Proxy

IPPB

IPB

Host B

IPPB IPVA data

dst src

IPVB IPPA data

dst src

idB IPVB IPPA dataIPF IPA

IPVB IPPA dataidBIPB IPL

dst src ID dst src

encapsulation IP header

original IP header

IPVB IPPA dataidBIPLIPB

Preserving IP headers

• Preserving IP headers: IPPA = IPVA,IPPB = IPVB

• Advantage: Applications like FTP, H323 work.• Advantage: Network-layer middle-boxes work

Instantiation in i3• Identifier Allocation: Per communicating pair

• Public triggers idA ,idB used for initial contact

• Private Triggers: – idAB : trigger inserted by A for receiving from B– idBA : 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 AB: IPVBidBA, idBA IPVA

– 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 acrossFirewall/NAT

i3 proxy

i3 proxy

i3 proxy

Remote client proxy

Internet Cafe

Insert middle-box appsi3 proxy

Deployment Tradeoffs

Local Proxy Remote Server

Proxy

Remote Client Proxy

Access Reqd End-host End-host DNS server

Additional

Infrastructure

None Dedicated

Machine

Waypoint

Machines

Preserving IP headers

Yes No No

Mobility Yes Only Client Only Server

NATted hosts Yes Only Client Only 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 http://i3.cs.berkeley.edu/

• 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 Configurationfoo.i3 ID-foobar.i3 ID-bar . . .

foo.i3

i3 address book

1. D

NS

qu

ery

for

foo.

i3

5. D

NS

An

swer

foo

.i3 =

10.

1.2.

3

i3 client proxy

tun0

eth0

Virtual LAN on tun010.0.0.0/8

10.0.0.1

2. obtain i3 ID

3. i3 trigger request/confirmation for ID-foo

4. create a virtual host for foo.i3with fake IP address 10.1.2.3.4

6 send/receive IP packetsfrom/to 10.1.2.3.4

7. IP over i3

Hash(“foo.i3”)if not in address book

10.1.2.3

CNN.com

10.3.2.1

10.0.0.1

Legacy apps

Legacy apps

Legacy apps

Linux/WinXP

Components

• Local proxy at both ends: IP <-> IP communication over i3

• Local proxy at client and i3IP 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 IPi3 proxy for IP client– foo.i3.6to4.jp mapped to foo.i3– DNS server returns address of IPi3 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

http://i3.cs.berkeley.edu/

• 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

Interneti3 proxy

i3 IPproxy

IPi3 proxy

sshd

Transparent access across Firewall/NAT

mobilitysupport

i3 proxy

i3 proxy

ssh

http

i3 proxy

WinXP

PDALinux Zaurus

WinXP

WinXP

WinXP

Web client

How it works (1)Local & i3IP proxyfoo.i3 ID-foo

bar.i3 ID-bar . . .

foo.i3

i3 address book

1. D

NS

qu

ery

for

foo.

i3

5. D

NS

An

swer

foo

.i3 =

10.

1.2.

3

i3 client proxy

tun0

eth0

Virtual LAN on tun010.0.0.0/8

10.0.0.1

2. obtain i3 ID

3. i3 trigger request/confirmation for ID-foo

4. create a virtual host for foo.i3with fake IP address 10.1.2.3.4

6 send/receive IP packetsfrom/to 10.1.2.3.4

7. IP over i3

Hash(“foo.i3”)if not in address book

CNN.com

i3 IP proxy

10.1.2.3

CNN.com

10.3.2.1

10.0.0.1

Legacy apps

Legacy apps

Legacy apps

Linux/WinXP

How it works (2)IPi3 proxy

3. DNS answer128.32.34.59

1. DNS queryfoo.i3.6to4.jp

2. Trigger REQ/CNF

11.22.33.44:1023 abc.i3:22 tcp22.33.44.55:2000 xyz.i3:993 tcp

* : * foo.i3 : *

33.44.55.66:1234 foo.i3:22 tcp

33.44.55.66

5. IP packet33.44.55.66:1234 128.32.34.59:22 tcp

6. Register the flow info

7. i3 packet

Prv ID(proxy) Prv ID(foo.i3)

33.44.55.66:1234 foo.i3:22 tcp

4. Create a flow entry and start waiting (1 second)

IPi3 proxy

Flow information

i3 proxy

foo.i3

Map *.i3 to real DNS domaine.g. *.i3.cs.berkeley.eduCurrently we use *.i3.6to4.jp

128.32.34.59

i3

DNS server

IP client

i3 revisited

LA

Proxy

LB

Proxy

idBA A1

1

Host A (IPB)Host B

cache=IPB:Pproxy 2

3

• 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