Application Scenarios

Here we describe a few useful applications of i3 and the OCALA proxy. These applications require no changes to the legacy applications, operating systems, NATs or firewalls.

Application Scenarios

Connecting to home machines

Most users today have problems connecting to their broadband-connected home machines from their workplace for two reasons:

Changing IP address: Most ISPs change the IP address allocated to the machine periodically, some more frequently than others, and this is a hassle to most users trying to run some service on their host.
NAT: A significant fraction of home routers also serve as NATs for security reasons. In such a case, since the address allocated to the host is essentially a locally valid address, it is not valid externally. Also, enabling an incoming connection through the NAT, requires special NAT configuration.

The first problem has to do with mobility, while the second problem has to with combining disparate address spaces. The solution using the i3 implementation is simple. The client proxy can be run on the home host which can insert public triggers under a dns name, say john.home.i3, in the Planetlab i3 infrastructure. Also, the remote machine also needs to run the client proxy. Once this done, all access on the remote machine to john.home.i3 will be redirected to the home machine. For details of how the client proxy works see here.

Secure Intranet Access

For security reasons, many organizations today resort to the draconian measure of setting up a firewall that filters outgoing connections and does not allow any incoming connections. Such measures make it hard for users to connect to their work machines from elsewhere. The security administration is not to blame here: there is no other feasible flexible alternative. The i3 implementation can be used for this scenario. A server proxy runs inside the organization and thus has unrestricted to all the intranet machines. This server proxy is set up to authenticate users connecting from home. This authentication requires a simple key management system. The firewall is configured to allow incoming access to the server proxy. This method offers a secure way of allowing Intranet access.

The following figures illustrate how such application is supported by i3. Consider a company, Acme, that wants to give access to its employees to the services and the resources on the intranet. To achieve this, Acme sets-up a machine S that runs the (see i3 server proxy module. The server proxy maintains a trigger (id, S) where it can be contacted by remote clients. Now, consider a remote client C that wants to access host H, with the DNS name host.acme.org, inside the firewall. Let (idC, C) be a trigger inserted by client C. Then the following sequence of steps take place:

Client C sends a DNS request for host.acme.org. The i3 proxy running at C intercepts this request and checks the configuration file i3-proxy.xml (see here for details) to see whether the request needs to be redirected, and if yes, to what i3 identifier. In this case, the configuration file indicates that all DNS requests for *.acme.org needs to be redirected to identifier id, so the proxy encapsulates the DNS requests and forwards it to S via trigger (id, S) (see step 1 in Figure (a)).
Upon receiving the DNS request, the server proxy forwards it to the local DNS server (step 2, Figure (a)). When the server proxy receives the reply back (step 3, Figure (a)), it allocates an identifier idH for the host, and inserts the corresponding trigger (idH, S) in i3 (step 5, Figure (b)). At the same time the server proxy stores the mapping idH->h (step 4, Figure (b)). This mapping is used to forward all packets with identifier idH to host H. Finally, the server proxy sends identifier idH to client C via the client's trigger (step 6, Figure (b)). Once it gets this identifier, the client can use it to communicates with host H.

Note that the functionality provided by the setting in the figure above is similar to the functionality provided by a Virtual Private Network (VPN). However, our solution has two advantages over VPNs:

In a VPN, once a client connects to an intranet, it will get an IP address on that intranet. But this means that if the client is infected, the client can potentially infect all machines on the intranet. To avoid this problem, many of the existing VPN solutions use firewalls to restrict the access of the remote clients, which can defeat the original propose of the VPN. In contrast, our solution makes it hard for an infected client to infect other machines on the intranet, since a virus or worm cannot use address scanning. This is because, as discussed here, the client proxy returns to the application a fake IP address that has only local meaning; this address has no relation with the real IP address of the destination. Furthermore any attempt of address scanning in the range used to allocate fake IP addresses can be easily detected as the client proxy knows exactly the fake addresses that are in use.
A client can access multiple intranets at the same time. This is not possible in existing VPN solutions since a client can acquire only one IP address at a time.

Middle-box Applications

There are several interesting middle-box applications today: intrusion detection systems (like Bro), spam filtering (an application-level middle-box) etc. They however require access to the edge router of an organization etc, which is not always feasible. To make the deployment of middle-boxes more convenient, the routing flexibility of i3 can be used. The client proxy can be configured to redirect traffic through, say, a intrusion detection system, which would then monitor traffic. The key point to note here is that intrusion detection system can be running on any machine, in fact, it can even be running on different machines at different times. An implementation of the client proxy which allows re-direction through an intrusion detection system is in the works. This implementation will allow the user to interpose any middle-box to monitor the traffic of willing users (who run the client proxy).