Middlebox: Difference between revisions

Edit links
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
Citation bot (talk | contribs)
Bots
4,905,501 edits
Alter: template type. Add: newspaper, s2cid, doi, year. | Use this bot. Report bugs. | Suggested by Abductive | #UCB_webform 2882/3850
AnimMouse (talk | contribs)
55 edits
No edit summary
 
(10 intermediate revisions by 9 users not shown)
Line 1: Line 1:
{{Short description|Intermediary box on the data path between a source host and destination host}}
{{Short description|Intermediary box on the data path between a source host and destination host}}
A '''middlebox''' is a [[computer networking]] device that transforms, inspects, filters, and manipulates traffic for purposes other than [[packet forwarding]].<ref name=mboxtaxonomy /> Examples of middleboxes include [[firewall (networking)|firewalls]], [[network address translation|network address translators]] (NATs), [[load balancer]]s, and [[deep packet inspection]] (DPI) boxes.<ref name="dublin">{{cite book |author1=Shan Huang |author2=Steve Uhlig |author3=Félix Cuadrado |title = 2017 Network Traffic Measurement and Analysis Conference (TMA)|date=2017 |pages=1–9 |doi=10.23919/TMA.2017.8002906 |chapter=Middleboxes in the Internet: A HTTP perspective |isbn=978-3-901882-95-1 |s2cid=34925433 |chapter-url=https://www.semanticscholar.org/paper/d66532ddd9e5f71e083ea2425bded5f90d5bf8d5 }}</ref>
A '''middlebox''' is a [[computer networking]] device that transforms, inspects, filters, and manipulates traffic for purposes other than [[packet forwarding]].<ref name=mboxtaxonomy /> Examples of middleboxes include [[firewall (networking)|firewalls]], [[network address translation|network address translators]] (NATs), [[load balancer]]s, and [[deep packet inspection]] (DPI) devices.<ref name="dublin">{{cite book |author1=Shan Huang |author2=Steve Uhlig |author3=Félix Cuadrado |title = 2017 Network Traffic Measurement and Analysis Conference (TMA)|date=2017 |pages=1–9 |doi=10.23919/TMA.2017.8002906 |chapter=Middleboxes in the Internet: A HTTP perspective |isbn=978-3-901882-95-1 |s2cid=34925433 }}</ref>


[[University of California, Los Angeles|UCLA]] computer science professor [[Lixia Zhang]] coined the term ''middlebox'' in 1999.<ref name="mboxtaxonomy"/><ref name="postel">{{citation|url=http://newsroom.ucla.edu/releases/lixia-zhang-named-to-jonathan-228215|title=Lixia Zhang named to UCLA's Jonathan B. Postel Chair in Computer Science|first=Wileen Wong|last=Kromhout|date=February 2, 2012|journal=UCLA Newsroom|accessdate=2015-06-14|archive-url=https://web.archive.org/web/20190425202848/http://newsroom.ucla.edu/releases/lixia-zhang-named-to-jonathan-228215|archive-date=April 25, 2019|url-status=dead}}</ref>
[[University of California, Los Angeles|UCLA]] computer science professor [[Lixia Zhang]] coined the term ''middlebox'' in 1999.<ref name="mboxtaxonomy"/><ref name="postel">{{citation|url=http://newsroom.ucla.edu/releases/lixia-zhang-named-to-jonathan-228215|title=Lixia Zhang named to UCLA's Jonathan B. Postel Chair in Computer Science|first=Wileen Wong|last=Kromhout|date=February 2, 2012|journal=UCLA Newsroom|accessdate=2015-06-14|archive-url=https://web.archive.org/web/20190425202848/http://newsroom.ucla.edu/releases/lixia-zhang-named-to-jonathan-228215|archive-date=April 25, 2019|url-status=dead}}</ref>


== Usage ==
== Usage ==
Middleboxes are widely deployed across both private and public networks. Dedicated middlebox hardware is widely deployed in enterprise networks to improve network [[network security|security]] and performance, however, even home network routers often have integrated firewall, NAT, or other middlebox functionality.<ref name=ciscohomefirewall /> One 2017 study counting more than 1,000 deployments in [[Autonomous system (Internet)|autonomous systems]], in both directions of traffic flows, and across a wide range networks, including mobile operators and data center networks.<ref name="dublin"/>
Middleboxes are widely deployed across both private and public networks. Dedicated middlebox hardware is widely deployed in enterprise networks to improve network [[network security|security]] and performance; however, even home network routers often have integrated firewall, NAT, or other middlebox functionality.<ref name=ciscohomefirewall /> One 2017 study counted more than 1,000 deployments in [[Autonomous system (Internet)|autonomous systems]], in both directions of traffic flows, and across a wide range networks, including mobile operators and data center networks.<ref name="dublin"/>


=== Examples ===
=== Examples ===
The following are examples of commonly deployed middleboxes:
The following are examples of commonly-deployed middleboxes:


* [[Firewall (computing)|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 certain [[Port (computer networking)|port numbers]], disallow any traffic to certain [[subnetwork|subnets]] etc.)"<ref name=mboxtaxonomy /> Other types of firewalls may use more complex rulesets, including those that inspect traffic at the session or application layer.<ref name=appfirewall />
* [[Firewall (computing)|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 certain [[Port (computer networking)|port numbers]], disallow any traffic to certain [[subnetwork|subnets]] etc.)"<ref name=mboxtaxonomy /> Other types of firewalls may use more complex rulesets, including those that inspect traffic at the session or application layer.<ref name=appfirewall />
* [[Intrusion detection system]]s (IDSs) monitor traffic and collect data for [[online algorithm|offline 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.<ref name=ids />
* [[Intrusion detection system]]s (IDSs) monitor traffic and collect data for [[online algorithm|offline 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.<ref name=ids />
* [[Network address translation|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 single [[IP address]]: hosts "behind" the NAT are assigned a [[IP address#IPv4 private addresses|private IP address]] and their packets destined to the public Internet traverse a NAT, which replaces their internal private address with a shared public address.<ref name=nat /> These are widely used by cellular network providers to manage scarce resources.<ref name="cells">{{cite journal |author1=Zhaoguang Wang, Zhiyun Qian, Qiang Xu, Z. Morley Mao, Ming Zhang |title=An Untold Story of Middleboxes in Cellular Networks |journal=ACM SIGCOMM Computer Communication Review |date=August 2011 |volume=41 |issue=4 |pages=374–385 |doi=10.1145/2043164.2018479 |url=https://web.eecs.umich.edu/~zmao/Papers/netpiculet.pdf |publisher=Association for Computing Machinery}}</ref>
* [[Network address translation|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 single [[IP address]]: hosts "behind" the NAT are assigned a [[IP address#IPv4 private addresses|private IP address]] and their packets destined to the public Internet traverse a NAT, which replaces their internal private address with a shared public address.<ref name=nat /> These are widely used by cellular network providers to manage scarce resources.<ref name="cells">{{cite journal |author1=Zhaoguang Wang, Zhiyun Qian, Qiang Xu, [[Z. Morley Mao]], Ming Zhang |title=An Untold Story of Middleboxes in Cellular Networks |journal=ACM SIGCOMM Computer Communication Review |date=August 2011 |volume=41 |issue=4 |pages=374–385 |doi=10.1145/2043164.2018479 |url=https://web.eecs.umich.edu/~zmao/Papers/netpiculet.pdf |publisher=Association for Computing Machinery}}</ref>
* [[WAN optimization|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.<ref name=wanopt />
* [[WAN optimization|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.<ref name=wanopt />
* [[Load balancing (computing)|Load balancers]] provide one point of entry to a service, but forward traffic flows to one or more hosts that actually provide the service.
* [[Load balancing (computing)|Load balancers]] provide one point of entry to a service, but forward traffic flows to one or more hosts that actually provide the service.
Line 18: Line 18:


== Criticism and challenges ==
== Criticism and challenges ==
Middleboxes have generated technical challenges for application development and have incurred "scorn" and "dismay" in the network architecture community<ref name="harmful">{{cite journal |author1=Michael Walfish, Jeremy Stribling, Maxwell Krohn,Hari Balakrishnan, Robert Morris, and Scott Shenker |title=Middleboxes No Longer Considered Harmful |journal=6th Symposium on Operating Systems Design and Implementation |date=2004 |pages=215–230 |url=https://www.usenix.org/legacy/event/osdi04/tech/full_papers/walfish/walfish.pdf |publisher=USENIX Association}}</ref> for violating the [[end-to-end principle]] of computer system design.<ref name=e2eviolate />
Middleboxes have generated technical challenges for application development and have incurred "scorn" and "dismay" in the network architecture community<ref name="harmful">{{cite journal |author1=Michael Walfish, Jeremy Stribling, Maxwell Krohn, Hari Balakrishnan, Robert Morris, and Scott Shenker |title=Middleboxes No Longer Considered Harmful |journal=6th Symposium on Operating Systems Design and Implementation |date=2004 |pages=215–230 |url=https://www.usenix.org/legacy/event/osdi04/tech/full_papers/walfish/walfish.pdf |publisher=USENIX Association}}</ref> for violating the [[end-to-end principle]] of computer system design.<ref name=e2eviolate />


=== Application interference ===
=== Application interference ===
Line 25: Line 25:
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 particular [[Port (computer networking)|port]], 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.<ref name=stun /><ref name=natpmp /><ref name=pcp />
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 particular [[Port (computer networking)|port]], 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.<ref name=stun /><ref name=natpmp /><ref name=pcp />


Additionally, because middlebox deployments by cell operators such as [[AT&T]] and [[T-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 "aggressive [[Timeout (computing)|timeout]] value to quickly recycle the resources held by inactive [[Transmission Control Protocol|TCP]] connections in the firewall, unexpectedly causing frequent disruptions to long-lived and occasionally idle connections maintained by applications such as [[Push email|push-based email]] and [[instant messaging]]".<ref name="cells"/>
Additionally, because middlebox deployments by cell operators such as [[AT&T]] and [[T-Mobile US|T-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 "aggressive [[Timeout (computing)|timeout]] value to quickly recycle the resources held by inactive [[Transmission Control Protocol|TCP]] connections in the firewall, unexpectedly causing frequent disruptions to long-lived and occasionally idle connections maintained by applications such as [[Push email|push-based email]] and [[instant messaging]]".<ref name="cells"/>


Other common middlebox-induced application challenges include [[Proxy server|web proxies]] serving "stale" or out-of-date content,<ref name=staleproxy /> and firewalls rejecting traffic on desired ports.<ref name=firewallblock />
Other common middlebox-induced application challenges include [[Proxy server|web proxies]] serving "stale" or out-of-date content,<ref name=staleproxy /> and firewalls rejecting traffic on desired ports.<ref name=firewallblock />


=== Internet extensibility and design ===
=== Internet extensibility and design ===
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.<ref name=nrg/> Specifically, because middleboxes make hosts in private address realms unable to "pass handles allowing other hosts to communicate with them" has hindered the spread of newer protocols like the [[Session Initiation Protocol]] (SIP) as well as various peer-to-peer systems.<ref name="harmful"/><ref>{{cite journal |author1=Bryan Ford |author2=Pyda Srisuresh |author3=Dan Kegel |title=Peer-to-Peer Communication Across Network Address Translators |journal=2005 USENIX Annual Technical Conference |date=2005 |pages=179–192 |url=https://www.usenix.org/legacy/event/usenix05/tech/general/full_papers/ford/ford.pdf |publisher=USENIX Association|bibcode=2006cs........3074F |arxiv=cs/0603074 }}</ref> This progressive reduction in flexibility has been described as [[protocol ossification]].<ref>{{Cite journal|last1=Papastergiou|first1=Giorgos|last2=Fairhurst|first2=Gorry|last3=Ros|first3=David|last4=Brunstrom|first4=Anna|last5=Grinnemo|first5=Karl-Johan|last6=Hurtig|first6=Per|last7=Khademi|first7=Naeem|last8=Tuxen|first8=Michael|last9=Welzl|first9=Michael|last10=Damjanovic|first10=Dragana|last11=Mangiante|first11=Simone|date=2017|title=De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives|url=https://ieeexplore.ieee.org/document/7738442|journal=IEEE Communications Surveys & Tutorials|volume=19|issue=1|pages=619–639|doi=10.1109/COMST.2016.2626780|issn=1553-877X|archive-date=2017|url-status=live|archive-url=https://aura.abdn.ac.uk/bitstream/handle/2164/8317/De_ossifying_the_internet_transport_layer.pdf|hdl=2164/8317|s2cid=1846371|hdl-access=free}}</ref><ref>{{Cite web|url=https://lwn.net/Articles/745590/|title=QUIC as a solution to protocol ossification|website=lwn.net|access-date=2020-03-14|first=Jonathan|last=Corbet|date=January 29, 2018}}</ref>
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.<ref name=nrg/> 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 the [[Session Initiation Protocol]] (SIP) as well as various peer-to-peer systems.<ref name="harmful"/><ref>{{cite journal |author1=Bryan Ford |author2=Pyda Srisuresh |author3=Dan Kegel |title=Peer-to-Peer Communication Across Network Address Translators |journal=2005 USENIX Annual Technical Conference |date=2005 |pages=179–192 |url=https://www.usenix.org/legacy/event/usenix05/tech/general/full_papers/ford/ford.pdf |publisher=USENIX Association|bibcode=2006cs........3074F |arxiv=cs/0603074 }}</ref> This progressive reduction in flexibility has been described as [[protocol ossification]].<ref>{{Cite journal|last1=Papastergiou|first1=Giorgos|last2=Fairhurst|first2=Gorry|last3=Ros|first3=David|last4=Brunstrom|first4=Anna|last5=Grinnemo|first5=Karl-Johan|last6=Hurtig|first6=Per|last7=Khademi|first7=Naeem|last8=Tuxen|first8=Michael|last9=Welzl|first9=Michael|last10=Damjanovic|first10=Dragana|last11=Mangiante|first11=Simone|date=2017|title=De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives|url=https://ieeexplore.ieee.org/document/7738442|journal=IEEE Communications Surveys & Tutorials|volume=19|issue=1|pages=619–639|doi=10.1109/COMST.2016.2626780|issn=1553-877X|archive-date=2021-09-22|url-status=live|archive-url=https://web.archive.org/web/20210922191041/https://aura.abdn.ac.uk/bitstream/handle/2164/8317/De_ossifying_the_internet_transport_layer.pdf|hdl=2164/8317|s2cid=1846371|hdl-access=free}}</ref><ref>{{Cite web|url=https://lwn.net/Articles/745590/|title=QUIC as a solution to protocol ossification|website=lwn.net|access-date=2020-03-14|first=Jonathan|last=Corbet|date=January 29, 2018}}</ref>


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 as [[Load balancing (computing)|load balancers]], proxies, or other forms of NAT, with backend traffic routed over [[IPv4]] or IPv6.
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 as [[Load balancing (computing)|load balancers]], proxies, or other forms of NAT, with backend traffic routed over [[IPv4]] or [[IPv6]].


== See also ==
== See also ==

* [[End-to-end connectivity]]
* [[End-to-end connectivity]]
* [[Interactive Connectivity Establishment]] (ICE)
* [[Interactive Connectivity Establishment]] (ICE)
Line 44: Line 45:
{{Reflist|30em|refs=<ref name=ciscohomefirewall>{{cite web|last=Ido Dubrawsky and Wes Noonan|title=Broadband Routers and Firewalls|url=http://www.ciscopress.com/articles/article.asp?p=598649&seqNum=5|publisher=CISCO Press|accessdate=15 July 2012}}</ref>
{{Reflist|30em|refs=<ref name=ciscohomefirewall>{{cite web|last=Ido Dubrawsky and Wes Noonan|title=Broadband Routers and Firewalls|url=http://www.ciscopress.com/articles/article.asp?p=598649&seqNum=5|publisher=CISCO Press|accessdate=15 July 2012}}</ref>


<ref name=mboxtaxonomy>{{cite journal|author=Brian Carpenter |title=Middleboxes: Taxonomy and Issues|year=2002 |doi=10.17487/RFC3234 |url= https://tools.ietf.org/html/rfc3234|rfc=3234|author-link=Brian Carpenter (Internet engineer)}}</ref>
<ref name=mboxtaxonomy>{{cite journal|author=Brian Carpenter |title=Middleboxes: Taxonomy and Issues|newspaper=Ietf Datatracker |year=2002 |doi=10.17487/RFC3234 |url= https://tools.ietf.org/html/rfc3234|rfc=3234|author-link=Brian Carpenter (Internet engineer)}}</ref>


<ref name=appfirewall>{{cite web|last=Magalhaes|first=Ricky|title=The Difference Between Application and Session Layer Firewalls|url=http://www.windowsecurity.com/articles/difference-between-application-session-layer-firewalls.html|accessdate=17 July 2012}}</ref>
<ref name=appfirewall>{{cite web|last=Magalhaes|first=Ricky|title=The Difference Between Application and Session Layer Firewalls|url=http://www.windowsecurity.com/articles/difference-between-application-session-layer-firewalls.html|accessdate=17 July 2012}}</ref>
Line 50: Line 51:
<ref name=ids>{{cite web|title=Understanding Intrusion Detection Systems|url=http://www.sans.org/reading_room/whitepapers/detection/understanding-intrusion-detection-systems_337|accessdate=17 July 2012}}</ref>
<ref name=ids>{{cite web|title=Understanding Intrusion Detection Systems|url=http://www.sans.org/reading_room/whitepapers/detection/understanding-intrusion-detection-systems_337|accessdate=17 July 2012}}</ref>


<ref name=nat>{{cite journal|last=K. Egevang and P. Francis|title=The IP Network Address Translator (NAT)|year=2001 |doi=10.17487/RFC3022 |url = https://tools.ietf.org/html/rfc3022|rfc=1631}}</ref>
<ref name=nat>{{cite journal|last=K. Egevang and P. Francis|title=The IP Network Address Translator (NAT)|newspaper=Ietf Datatracker |year=2001 |doi=10.17487/RFC3022 |url = https://tools.ietf.org/html/rfc3022|rfc=1631}}</ref>


<ref name=wanopt>{{cite web|last=Poe|first=Robert|title=What Is WAN Optimization, and How Can It Help You?|url=http://www.comparebusinessproducts.com/briefs/what-wan-optimization-and-how-can-it-help-you|accessdate=17 July 2012}}</ref>
<ref name=wanopt>{{cite web|last=Poe|first=Robert|title=What Is WAN Optimization, and How Can It Help You?|url=http://www.comparebusinessproducts.com/briefs/what-wan-optimization-and-how-can-it-help-you|accessdate=17 July 2012}}</ref>


<ref name=stun>{{cite journal|last=J. Rosenberg|url = https://tools.ietf.org/html/rfc5389 |title=Session Traversal Utilities for NAT (STUN)|year = 2008 |doi = 10.17487/RFC5389 |rfc=5389|s2cid = 6777753 |display-authors=etal}}</ref>
<ref name=stun>{{cite journal|last=J. Rosenberg|url = https://tools.ietf.org/html/rfc5389 |title=Session Traversal Utilities for NAT (STUN)|newspaper = Ietf Datatracker |year = 2008 |doi = 10.17487/RFC5389 |rfc=5389|s2cid = 6777753 |display-authors=etal|doi-access = free }}</ref>


<ref name=e2eviolate>{{cite journal|last=Walfish|title=Middleboxes no longer considered harmful|journal=OSDI|year=2004|url=http://static.usenix.org/event/osdi04/tech/full_papers/walfish/walfish.pdf|accessdate=17 July 2012|display-authors=etal}}</ref>
<ref name=e2eviolate>{{cite journal|last=Walfish|title=Middleboxes no longer considered harmful|journal=OSDI|year=2004|url=http://static.usenix.org/event/osdi04/tech/full_papers/walfish/walfish.pdf|accessdate=17 July 2012|display-authors=etal}}</ref>

Latest revision as of 14:20, 19 April 2024

A middlebox is a computer networking device that transforms, inspects, filters, and manipulates traffic for purposes other than packet forwarding.[1] Examples of middleboxes include firewalls, network address translators (NATs), load balancers, and deep packet inspection (DPI) devices.[2]

UCLA computer science professor Lixia Zhang coined the term middlebox in 1999.[1][3]

Usage[edit]

Middleboxes are widely deployed across both private and public networks. Dedicated middlebox hardware is widely deployed in enterprise networks to improve network security 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 in autonomous systems, in both directions of traffic flows, and across a wide range networks, including mobile operators and data center networks.[2]

Examples[edit]

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 certain port numbers, disallow any traffic to certain subnets 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 for offline 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 single IP address: hosts "behind" the NAT are assigned a private 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.

Criticism and challenges[edit]

Middleboxes have generated technical challenges for application development and have incurred "scorn" and "dismay" in the network architecture community[10] for violating the end-to-end principle of computer system design.[11]

Application interference[edit]

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 particular port, 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 as AT&T and T-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 "aggressive timeout value to quickly recycle the resources held by inactive TCP connections in the firewall, unexpectedly causing frequent disruptions to long-lived and occasionally idle connections maintained by applications such as push-based email and instant messaging".[8]

Other common middlebox-induced application challenges include web proxies serving "stale" or out-of-date content,[15] and firewalls rejecting traffic on desired ports.[16]

Internet extensibility and design[edit]

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 the Session Initiation Protocol (SIP) as well as various peer-to-peer systems.[10][18] This progressive reduction in flexibility has been described as protocol 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 as load balancers, proxies, or other forms of NAT, with backend traffic routed over IPv4 or IPv6.

See also[edit]

References[edit]

  1. ^ a b c Brian Carpenter (2002). "Middleboxes: Taxonomy and Issues". Ietf Datatracker. doi:10.17487/RFC3234. RFC 3234.
  2. ^ a b Shan Huang; Steve Uhlig; Félix Cuadrado (2017). "Middleboxes in the Internet: A HTTP perspective". 2017 Network Traffic Measurement and Analysis Conference (TMA). pp. 1–9. doi:10.23919/TMA.2017.8002906. ISBN 978-3-901882-95-1. S2CID 34925433.
  3. ^ Kromhout, Wileen Wong (February 2, 2012), "Lixia Zhang named to UCLA's Jonathan B. Postel Chair in Computer Science", UCLA Newsroom, archived from the original on April 25, 2019, retrieved 2015-06-14
  4. ^ Ido Dubrawsky and Wes Noonan. "Broadband Routers and Firewalls". CISCO Press. Retrieved 15 July 2012.
  5. ^ Magalhaes, Ricky. "The Difference Between Application and Session Layer Firewalls". Retrieved 17 July 2012.
  6. ^ "Understanding Intrusion Detection Systems". Retrieved 17 July 2012.
  7. ^ K. Egevang and P. Francis (2001). "The IP Network Address Translator (NAT)". Ietf Datatracker. doi:10.17487/RFC3022. RFC 1631.
  8. ^ a b Zhaoguang Wang, Zhiyun Qian, Qiang Xu, Z. Morley Mao, Ming Zhang (August 2011). "An Untold Story of Middleboxes in Cellular Networks" (PDF). ACM SIGCOMM Computer Communication Review. 41 (4). Association for Computing Machinery: 374–385. doi:10.1145/2043164.2018479.{{cite journal}}: CS1 maint: multiple names: authors list (link)
  9. ^ Poe, Robert. "What Is WAN Optimization, and How Can It Help You?". Retrieved 17 July 2012.
  10. ^ a b Michael 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)
  11. ^ Walfish; et al. (2004). "Middleboxes no longer considered harmful" (PDF). OSDI. Retrieved 17 July 2012.
  12. ^ J. Rosenberg; et al. (2008). "Session Traversal Utilities for NAT (STUN)". Ietf Datatracker. doi:10.17487/RFC5389. RFC 5389. S2CID 6777753.
  13. ^ "NAT-PMP". Ietf Datatracker. Retrieved 17 July 2012.
  14. ^ "Port Control Protocol Working Group". Retrieved 17 July 2012.
  15. ^ "BlueCoat Knowledge Base: Proxy is displaying stale content". Retrieved 17 July 2012.
  16. ^ "Using FaceTime and iMessage behind a firewall". Retrieved 17 July 2012.
  17. ^ Honda; et al. (2011). "Is it still possible to extend TCP?" (PDF). Internet Measurement Conference.
  18. ^ Bryan Ford; Pyda Srisuresh; Dan Kegel (2005). "Peer-to-Peer Communication Across Network Address Translators" (PDF). 2005 USENIX Annual Technical Conference. USENIX Association: 179–192. arXiv:cs/0603074. Bibcode:2006cs........3074F.
  19. ^ Papastergiou, Giorgos; Fairhurst, Gorry; Ros, David; Brunstrom, Anna; Grinnemo, Karl-Johan; Hurtig, Per; Khademi, Naeem; Tuxen, Michael; Welzl, Michael; Damjanovic, Dragana; Mangiante, Simone (2017). "De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives". IEEE Communications Surveys & Tutorials. 19 (1): 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. ISSN 1553-877X. S2CID 1846371. Archived (PDF) from the original on 2021-09-22.
  20. ^ Corbet, Jonathan (January 29, 2018). "QUIC as a solution to protocol ossification". lwn.net. Retrieved 2020-03-14.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Middlebox&oldid=1219733499"