Terminology

A middlebox is a device that has the ability to actively or passively participate in a communication in which it does not act as an end-system. Typically, such a device is located on the path between the network nodes that act as end-systems where it has access to all or part of the datagrams that are being exchanged.

If the middlebox modifies the data that traverses it (this includes discarding packets), it is called active, otherwise it is called passive.

Visibility

An important characteristic of a middlebox is whether it respects the end-to-end principle. Truly passive middleboxes do this by definition, active ones typically don't. The latter can be roughly classified in terms of how visible they are to the end-systems. Examples for various levels of visibility include

Very visible

A HTTP proxy according to RFC2616. It terminates the transport layer connection and has well-defined semantics. The proxy must be explicitly configured on the client. Application Level Gateways (ALG) also have this property.

Partially visible

A Firewall that signals dropped packets back to the source with ICMP. This breaks end-to-end communication but allows one party (but not the other) to discover the middlebox.

Not visible

An Intrusion detection system that performs TCP-splitting to be able to match signatures across TCP segments. Both end-systems believe that they are talking directly to each other, when the middlebox is in fact spoofing both sides with semi-independent TCP sessions. The presence of the middlebox can only be detected by comparing packet traces from both end-systems.

Middleboxes that do not operate at a well-defined location in the protocol stack usually need to be invisible to perform their function. For example, any device that wants to look into the payload of a TCP stream without terminating it explicitly must implement at least part of the TCP protocol machinery, interfering with that of the end-systems.

Middleboxes that do work at a well-defined location in the protocol stack are sometimes nevertheless implemented in an invisible fashion to either deliberately hide their presence, to avoid the need for explicit configuration of end-systems, or to prevent end-systems from circumventing the service (e.g. an ISP that forces all traffic on port 80 to pass through their HTTP proxy).

Impact

Bottleneck

Most middleboxes use CPU-based architectures, often built from off-the-shelf hardware. Placed on a high-capacity link, they can introduce a bottleneck when they are unable to process traffic at line-rate.

Disruption of end-to-end performance tuning

Successful TCP end-system tuning heavily depends on the negotiation of options during session setup (e.g. MSS, window scaling, timestamp, SACK) and advertisement of the receive window size throughout the session. It is crucial that these parameters are exchanged between the end-systems and are not modified in transit. Middleboxes performing TCP-splitting may not pass all of these parameters on to the other side, but negotiate their own values with both sides. The reasons for doing this include the lack of support of a particular option, the lack of resources (e.g. memory for large socket buffers) or local policy.

Debugging

In general, the less visible a middlebox is, the more difficult it gets to debug a problem, because the presence of the device is more likely to be unknown to the people who perform the investigation on one of the end-systems. It is often difficult or even impossible to discover invisible middleboxes unless one has access to another host located on the other side of the middlebox. Cascading of middleboxes makes this even more difficult.

Recommendations

General

• Avoid invisible middleboxes.

• Chose a configuration that minimizes interference with end-to-end properties.

• Document the placement and configuration of middleboxes in a public place.

Specific

Firewalls

• Permit traceroute. A crucial step in the debugging of performance problems is the discovery of the end-to-end path through the network. The various traceroute utilities available on most systems provide this information in a simple and effective manner. The traditional UDP-based traceroute uses UDP packets with ports in the range 33434 - 34199 as well as the ICMP messages time exceeded in transit (type 11, coed 0) and port unreachable (type 3, code 3).

• Permit ICMP. ICMP provides a number of services relevant for performance issues.
  • Simple end-to-end reachability test with the ping utility. ICMP echo request (type 8, code 0), echo reply (type 0, code 0)
  • Discovery of changes in the path MTU. ICMP fragmentation needed and don't fragment bit set (type 3, code 4).

• Do not discard TCP packets with options or flags unknown to the firewall, in particular explicit congestion notification (ECN) and selective acknowledgements (SACK).

• Consider the impact of "firewall-friendly" configurations for applications. A common method to simplify the implementation of a security policy for a particualr application is to channel all communication through a single device on fixed UDP or TCP ports (proxy, ALG), which can introduce a performance bottleneck.

Traffic Shapers

Load-Balancers

Network Address Translators (NAT)

Proxies

References

• Hypertext Transfer Protocol -- HTTP/1.1 (RFC 2616), R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999
• Middleboxes: Taxonomy and Issues (RFC 3234), B. Carpenter, S. Brim, February 2002

-- AlexGall - 21 Jun 2005