Usage areas

Port redirection

The basic usage scenario for Barefoot is port redirection, also known as port forwarding and port bouncing. A typical example would be running the Barefoot server on a single machine available from the Internet, forwarding data and connections received by Barefoot to multiple internal machines/servers.

Barefoot would forward traffic for a set of application services, like HTTP (TCP) or DNS (TCP or UDP), to other internal machines running these application services. These other machines, running the various application servers would typically not be available or visible from the Internet.

Disregarding the overhead of having data flow through the Barefoot server at layer 4 of the protocol stack, rather than being wire-speed routed at layer 3, this configuration can have several benefits:

• Because the internal server addresses are not visible to external machines, it is easy to move the traffic for any service to a different machine by only changing the Barefoot configuration file. The application service (e.g., HTTP) is separated from the machine the application server (e.g., Apache httpd) is running on.

  E.g., if today HTTP service is forwarded by Barefoot to the internal machine 10.1.1.1, simply changing 10.1.1.1 to e.g., 10.1.1.2 in the Barefoot configuration file will change the redirection to use the machine 10.1.1.2 instead.

• Because clients do not communicate directly with the actual application servers, there is somewhat less need to worry about the security of the particular TCP/IP implementation of these machines; only the machines running the Barefoot server are directly exposed to the Internet, hopefully with a robust TCP/IP stack.

  This reduces the chance that services running on platforms with TCP/IP vulnerabilities will be exploited, as no TCP/IP communication will exist between clients and servers, only between clients and Barefoot.

• For TCP, separate TCP connections are used between the clients and Barefoot, and between Barefoot and the application server. This can be beneficial in some usage scenarios, including reducing latency.
• Firewall configuration can be made simpler and safer by not having to correctly permit TCP/IP (ICMP included) access between various internal servers and the Internet.

Feature supplementation

Another benefit of using Barefoot is that the features available in Barefoot can supplement the features available in the application servers.

An application server typically has a single purpose. In the case of a HTTP server this purpose is sending and receiving data from HTTP clients.

Outside this purpose, there are other, more general, features than can be useful in virtually any application server. Features such as e.g., access control, detailed logging, or resource control might be desired, but not supported by the particular application server. If Barefoot is used to forward data to the application server, Barefoot can however layer the desired features on top of the service provided by the application server, without any need to modify the application service.

If a wide range of different services, usually using a wide range of different application servers, are provided, it is not likely that all these features will be supported by all the different servers. Even if they are, the configuration and usage is likely to be different for each server.

Barefoot provides an alternative to having this implemented and configured separately for each server. The Barefoot configuration file can be used to implement access control, resource management, and traffic logging for multiple services in a single configuration file using the same syntax regardless of what application server the traffic is forwarded to. Typical examples include:

• Denying traffic from specific networks or IP-addresses.
• Redirecting traffic from different domains or networks to different internal servers.
• Providing extensive logging and accounting of the network traffic.
• Storing the data transmitted from certain networks or IP-addresses, or going to specific services.
• Limiting the bandwidth available for a specific service, or for clients coming from a specific address. [requires the bandwidth module]
• Limiting the number of sessions using a specific service, or limiting the number of sessions coming from a specific network. [requires the session module]