Middleboxes are widely deployed across both private and public networks. Dedicated middlebox hardware is widely deployed in enterprise networks to improve networksecurity and performance; however, even home network routers often have integrated firewall, NAT, or other middlebox functionality.[4] One 2017 study counted more than 1,000 deployments inautonomous systems, in both directions of traffic flows, and across a wide range networks, including mobile operators and data center networks.[2]
The following are examples of commonly-deployed middleboxes:
Firewalls filter traffic based on a set of predefined security rules defined by a network administrator. IP firewalls reject packets "based purely on fields in the IP and transport headers (e.g., disallow incoming traffic to certainport numbers, disallow any traffic to certainsubnets etc.)"[1] Other types of firewalls may use more complex rulesets, including those that inspect traffic at the session or application layer.[5]
Intrusion detection systems (IDSs) monitor traffic and collect data foroffline analysis for security anomalies. Unlike firewalls, IDSs do not filter packets in real time, as they are capable of more complex inspection and must decide whether to accept or reject each packet as it arrives.[6]
Network address translators (NATs) replace the source and/or destination IP addresses of packets that traverse them. Typically, NATs are deployed to allow multiple end hosts to share a singleIP address: hosts "behind" the NAT are assigned aprivate IP address and their packets destined to the public Internet traverse a NAT, which replaces their internal private address with a shared public address.[7] These are widely used by cellular network providers to manage scarce resources.[8]
WAN optimizers improve bandwidth consumption and perceived latency between endpoints. Typically deployed in large enterprises, WAN optimizers are deployed near both sending and receiving endpoints of communication; the devices then coordinate to cache and compress traffic that traverses the Internet.[9]
Load balancers provide one point of entry to a service, but forward traffic flows to one or more hosts that actually provide the service.
Cellular networks use middleboxes to ensure scarce network resources are used efficiently as well as to protect client devices.
Middleboxes have generated technical challenges for application development and have incurred "scorn" and "dismay" in the network architecture community[10] for violating theend-to-end principle of computer system design.[11]
Some middleboxes interfere with application functionality, restricting or preventing end host applications from performing properly.
In particular, network address translators (NATs) present a challenge in that NAT devices divide traffic destined to a public IP address across several receivers. When connections between a host on the Internet and a host behind the NAT are initiated by the host behind the NAT, the NAT learns that traffic for that connection belongs to the local host. Thus, when traffic coming from the Internet is destined to the public (shared) address on a particularport, the NAT can direct the traffic to the appropriate host. However, connections initiated by a host on the Internet do not present the NAT any opportunity to "learn" which internal host the connection belongs to. Moreover, the internal host itself may not even know its own public IP address to announce to potential clients what address to connect to. To resolve this issue, several new protocols have been proposed.[12][13][14]
Additionally, because middlebox deployments by cell operators such asAT&T andT-Mobile are opaque, application developers are often "unaware of the middlebox policies enforced by operators", while operators lack full knowledge about application behavior and requirements. For example, one carrier set an "aggressivetimeout value to quickly recycle the resources held by inactiveTCP connections in the firewall, unexpectedly causing frequent disruptions to long-lived and occasionally idle connections maintained by applications such aspush-based email andinstant messaging".[8]
Other common middlebox-induced application challenges includeweb proxies serving "stale" or out-of-date content,[15] and firewalls rejecting traffic on desired ports.[16]
One criticism of middleboxes is they can limit the choice of transport protocols, thus limiting application or service designs. Middleboxes may filter or drop traffic that does not conform to expected behaviors, so new or uncommon protocols or protocol extensions may be filtered out.[17] Specifically, because middleboxes make hosts in private address realms unable to "pass handles allowing other hosts to communicate with them", they have hindered the spread of newer protocols like theSession Initiation Protocol (SIP) as well as various peer-to-peer systems.[10][18] This progressive reduction in flexibility has been described asprotocol ossification.[19][20]
Conversely, some middleboxes can assist in protocol deployment by providing a translation between new and old protocols. For example,IPv6 can be deployed on public endpoints such asload balancers, proxies, or other forms of NAT, with backend traffic routed overIPv4 orIPv6.
^abMichael Walfish, Jeremy Stribling, Maxwell Krohn, Hari Balakrishnan, Robert Morris, and Scott Shenker (2004)."Middleboxes No Longer Considered Harmful"(PDF).6th Symposium on Operating Systems Design and Implementation. USENIX Association:215–230.{{cite journal}}: CS1 maint: multiple names: authors list (link)
