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
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
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).
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
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,
) 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.
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.
- 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.
- 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).
- Consider the impact of "firewall-friendly" configurations for applications. A common method to simplify the implementation of a security policy for a particular application is to channel all communication through a single device on fixed UDP or TCP ports (proxy, ALG), which can introduce a performance bottleneck.
Network Address Translators (NAT)
- 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
- 21 Jun 2005