RFC 3234

Middleboxes: Taxonomy and Issues 🦋

Okay bestie, let's get the vibes straight first 💅. This is RFC 3234, and it was written by B. Carpenter (IBM Zurich Research Laboratory) and S. Brim for the Network Working Group. It's filed as Informational, so it's sharing knowledge rather than setting a standard 🧚. The date is February 2002. The header doesn't list any RFCs that it obsoletes or updates, so it's not replacing or changing anything else 🌸.

Status of this Memo

So this memo is here to inform the Internet community 🎀. It does not specify an Internet standard of any kind, so please don't treat it like one 🙈. Distribution of this memo is unlimited, so share away 💜.

Copyright Notice

Copyright (C) The Internet Society (2002). All Rights Reserved. ✨

Abstract

This doc is part of an IETF discussion about "middleboxes" 🎀. A middlebox is any intermediary box that does functions beyond the normal, standard stuff an IP router does, sitting on the data path between a source host and a destination host. The document builds a catalogue (a taxonomy) of middleboxes, cites earlier and current IETF work on them, and tries to spot some early conclusions. It doesn't claim to be definitive though 🫶.

Table of Contents

   1. Introduction and Goals.........................................  3
   1.1. Terminology..................................................  3
   1.2. The Hourglass Model, Past and Future.........................  3
   1.4. Goals of this Document.......................................  4
   2. A catalogue of middleboxes.....................................  5
   2.1 NAT...........................................................  6
   2.2 NAT-PT........................................................  7
   2.3 SOCKS gateway.................................................  7
   2.4 IP Tunnel Endpoints...........................................  8
   2.5. Packet classifiers, markers and schedulers...................  8
   2.6 Transport relay...............................................  9
   2.7. TCP performance enhancing proxies............................ 10
   2.8. Load balancers that divert/munge packets..................... 10
   2.9. IP Firewalls................................................. 11
   2.10. Application Firewalls....................................... 11
   2.11. Application-level gateways.................................. 12
   2.12. Gatekeepers/ session control boxes.......................... 12
   2.13. Transcoders................................................. 12
   2.14. Proxies..................................................... 13
   2.15. Caches...................................................... 14
   2.16. Modified DNS servers........................................ 14
   2.17. Content and applications distribution boxes................. 15
   2.18. Load balancers that divert/munge URLs....................... 16
   2.19. Application-level interceptors.............................. 16
   2.20. Application-level multicast................................. 16
   2.21. Involuntary packet redirection.............................. 16
   2.22. Anonymisers................................................. 17
   2.23. Not included................................................ 17
   2.24. Summary of facets........................................... 17
   3. Ongoing work in the IETF and elsewhere......................... 18
   4. Comments and Issues............................................ 19
   4.1. The end to end principle under challenge..................... 19
   4.2. Failure handling............................................. 20
   4.3. Failures at multiple layers.................................. 21
   4.4. Multihop application protocols............................... 21
   4.5. Common features.............................................. 22
   5. Security Considerations........................................ 22
   6. Acknowledgements............................................... 23
   7. References..................................................... 23
   Authors' Addresses................................................ 26
   Acknowledgement................................................... 26
   Full Copyright Statement.......................................... 27

1. Introduction and Goals ✨

1.1. Terminology

The word "middlebox" was coined by Lixia Zhang 🌸 as a graphic way to describe a recent phenomenon on the Internet. A middlebox is any intermediary device doing functions other than the normal, standard functions of an IP router on the datagram path between a source host and a destination host.

In some discussions, especially ones focused on HTTP traffic, people say "intermediary". For this document we prefer the more graphic phrase. Of course, a middlebox can be virtual, i.e., an embedded function of some other box. It should not be interpreted as necessarily referring to a separate physical box. It may be a device that terminates one IP packet flow and originates another, or a device that transforms or diverts an IP packet flow in some way, or a combination. In any case, it is never the ultimate end-system of an applications session 💅.

Normal, standard IP routing functions (i.e., the route discovery and selection functions described in [RFC 1812], and their equivalent for IPv6) are not considered middlebox functions. A standard IP router is basically transparent to IP packets 🦋. Other functions happening within the IP layer may be considered middlebox functions, but functions below the IP layer are excluded from the definition.

There's some discrepancy in how people use the word "routing" 🙈. Some folks use it in the narrow, traditional sense of path selection based on IP address, i.e., the decision-making action of an IP router. Others use it for higher layer decision-making (based perhaps on a URL or other applications layer string). In either case it implies a choice of outbound direction, not just forwarding a packet in the only direction available. In this document, the traditional sense is always qualified as "IP routing." 🎀

1.2. The Hourglass Model, Past and Future

The classical description of Internet architecture is based around the hourglass model [HOURG] and the end-to-end principle [Clark88, Saltzer]. The hourglass model shows the protocol architecture as a narrow-necked hourglass, with all upper layers riding over a single IP protocol, which itself rides over a variety of hardware layers ⏳.

The end-to-end principle says that some functions (such as security and reliability) can only be implemented completely and correctly end-to-end, with the help of the end points. It also notes that providing an incomplete version of such functions inside the network can sometimes be useful as a performance enhancement, but it's not a substitute for the end-to-end implementation of the function 🫶. The references above, and [RFC 1958], go into more detail.

In this architecture, the only boxes in the neck of the hourglass are IP routers, and their only function is to determine routes and forward packets (while also updating fields necessary for the forwarding process). That's why they aren't classed as middleboxes 💖.

Today, we see deviations from this model, caused by numerous middleboxes getting inserted into the network and doing functions other than IP forwarding 👀. Viewed one way, these boxes challenge the transparency of the network layer [RFC 2775]. Viewed another way, they challenge the hourglass model: although the IP layer doesn't go away, middleboxes dilute its significance as the single necessary feature of all communications sessions. Instead of concentrating diversity and function at the end systems, they spread diversity and function throughout the network 🌈.

This is a matter of concern for several reasons:

• New middleboxes challenge old protocols. Protocols designed without consideration of middleboxes may fail, predictably or unpredictably, in the presence of middleboxes 😭.
• Middleboxes introduce new failure modes. Rerouting of IP packets around crashed routers is no longer the only case to consider. The fate of sessions involving crashed middleboxes must also be considered 💀.
• Configuration is no longer limited to the two ends of a session. Middleboxes may also require configuration and management 🍓.
• Diagnosis of failures and misconfigurations is more complex. 🔥

1.4. Goals of this Document

The principle goal of this document is to describe and analyse the current impact of middleboxes on the architecture of the Internet and its applications. From this, we attempt to identify some general conclusions ✨.

Goals that might follow on from this work are:

• to identify harmful and harmless practices,
• to suggest architectural guidelines for application protocol and middlebox design,
• to identify requirements and dependencies for common functions in the middlebox environment,
• to derive a system design for standardisation of these functions,
• to identify additional work that should be done in the IETF and IRTF.

An implied goal is to identify any necessary updates to the Architectural Principles of the Internet [RFC 1958] 👑.

The document first sets up a catalogue of middleboxes, and cites previous or current IETF work concerning middleboxes, before moving on to discussion and conclusions 🧚.

---

2. A catalogue of middleboxes 🎀

okay so this is the main event bestie 💅 the catalogue of middleboxes! there's no obvious way to sort them into a neat family tree, because middleboxes have lots of different facets, and you could slice them up in a bunch of different ways at once ✨

DISCLAIMER: these facets, lots of the distinctions between middlebox types, and the choice to include or leave out a particular type are kinda subjective 🙈 not everyone who commented on the drafts agrees with these classifications and descriptions. the catalogue is not claimed to be mathematically complete and consistent, and in some places the choices were purely arbitrary or there's still some ambiguity. so this doc makes no claim to be definitive 💜

the facets we're looking at are:

1. Protocol layer. does the box act at the IP layer, the transport layer, the upper layers, or a mix? 🧚
2. Explicit versus implicit. is the middlebox function a deliberate design feature of the protocol(s) in use, like an SMTP relay? or is it an add-on the protocol design didn't foresee, probably trying to be invisible, like a network address translator? 👀
3. Single hop versus multi-hop. can there be only one box on the path, or can there be several? 🛤️
4. In-line versus call-out. the middlebox function might run in-line on the datapath, or it might involve a call-out to an ancillary box 📞
5. Functional versus optimising. does the box do a function the application session can't run without, or is the function only an optimisation? ⭐
6. Routing versus processing. does the box just pick which way to send a session's packets, or does it actually process them somehow (like changing them or creating a side-effect)? 🔥
7. Soft state versus hard state. if the box loses its state information, does the session keep running in a degraded mode while it rebuilds the state it needs (soft state), or does it just fail (hard state)? 💀
8. Failover versus restart. if a hard state box fails, does the session get redirected to an alternative box that has a copy of the state information, or is it forced to abort and restart? 🌸

one classification is deliberately left out: "good" versus "evil" 🙅‍♀️ analysis shows some middlebox types come with a whole host of complications and disadvantages, but there's no useful point in just deprecating them. they were invented for compelling reasons, and it's really instructive to understand those reasons 🫶

the box types below are in an arbitrary order, although neighbouring entries might have some affinity. at the end of each entry there's an attempt to characterise it using the facets above. don't read those characterisations as rigid, because in lots of cases they're a gross simplification 😭

Note: many types of middlebox may need to perform IP packet fragmentation and re-assembly. this is only mentioned in certain cases 🍓

2.1 NAT

Network Address Translator 🦋 a function, often built into a router, that dynamically assigns a globally unique address to a host that doesn't have one, without that host knowing. so the right address field in every packet to and from that host gets translated on the fly ✨ NAT doesn't play nice with application protocols that depend on IP addresses, so in practice a NAT is always paired with an ALG (Application Level Gateway, see below). it also touches the transport layer to the extent of fixing up checksums 🔧

NATs have been extensively analysed in the IETF:

[RFC 2663, RFC 2993,
RFC 3022, RFC 3027, etc.]

the experimental RSIP proposal complements NAT with a dynamic tunnel mechanism that puts a stateful RSIP server in place of the NAT:

[RSIP]

{1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
processing, 7 hard, 8 restart}

2.2 NAT-PT

NAT with Protocol Translator 🌈 a function, normally built into a router, that does NAT between an IPv6 host and an IPv4 network, and also translates the entire IP header between IPv6 and IPv4 formats 💖

NAT-PT itself depends on the Stateless IP/ICMP Translation Algorithm (SIIT) mechanism for its protocol translation function:

[RFC 2765]

in practice, SIIT and NAT-PT will both need an associated ALG and will need to touch transport checksums. because UDP checksums are allowed to be absent in IPv4, translating fragmented unchecksummed UDP from IPv4 to IPv6 is hopeless 😩 NAT-PT and SIIT also have other potential fragmentation and MTU problems, especially with endpoints that don't do path MTU discovery (or when they transit other middleboxes that break path MTU discovery). ICMP translation has some intractable difficulties too 💀

NAT-PT is a Proposed Standard from the NGTRANS WG:

[RFC 2766]

the Dual Stack Transition Mechanism adds a second related middlebox, the DSTM server:

[DSTM]

{1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
processing, 7 hard, 8 restart}

2.3 SOCKS gateway

SOCKSv5 is a stateful mechanism for authenticated firewall traversal, and it's giving security checkpoint 🛂 the client host has to talk to the SOCKS server in the firewall first before it can get through:

[RFC 1928]

the SOCKS server, not the client, decides the source IP address and port number used outside the firewall 👑 the client's stack has to be "SOCKSified" to account for this, and address-sensitive applications can get confused, kinda like with NAT. the good news is SOCKS gateways don't need ALGs ✨

SOCKS is maintained by the AFT (Authenticated Firewall Traversal) WG 🧁

{1 multi-layer, 2 explicit, 3 multihop, 4 in-line, 5 functional, 6
routing, 7 hard, 8 restart}

2.4 IP Tunnel Endpoints

tunnel endpoints, including virtual private network endpoints, use basic IP services to set up tunnels with their peer tunnel endpoints, which could be anywhere on the Internet 🦋 tunnels create entirely new "virtual" networks and network interfaces on top of the Internet infrastructure, which opens up a bunch of new services. tunnel endpoints base their forwarding decisions at least partly on their own policies, and only partly if at all on info visible to the surrounding routers 🌸

to the extent they deliver packets intact to their destinations, tunnel endpoints seem to follow the end-to-end principle in the outer Internet. but the destination might be completely different from what a router near the tunnel entrance expects 👀 also, the per-hop treatment a tunneled packet gets (for example, in terms of QoS) might not be what it would've gotten if the packet had traveled untunneled:

[RFC2983]

tunnels also cause difficulties with MTU size (they reduce it) and with ICMP replies (they may lack the diagnostic info they need) 😭

when a tunnel fails for some reason, the user session might abort, or an alternative IP route might turn out to be available, or in some cases the tunnel gets re-established automatically 🔁

{1 multi-layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
processing, 7 hard, 8 restart or failover}

2.5. Packet classifiers, markers and schedulers

packet classifiers sort the packets flowing through them according to policy, and either pick them out for special treatment or mark them, especially for differentiated services:

[Clark95, RFC 2475]

they can change the sequence of packet flow through subsequent hops, since they control how traffic conditioners behave 🎀

schedulers or traffic conditioners (in routers, hosts, or specialist boxes inserted into the data path) can change the time sequence of packet flow, the order packets get sent in, and which packets get dropped ⏱️ this can seriously affect end-to-end performance. but it doesn't fundamentally change the unreliable datagram model of the Internet 💅

when a classifier or traffic conditioner fails, the user session might see anything from complete loss of connectivity (all packets dropped), through best-effort service (all packets given default QOS), all the way up to automatic restoration of the original service level 🌈

{1 multi-layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising, 6
processing, 7 soft, 8 failover or restart}

2.6 Transport relay

transport relays are basically the transport layer version of an ALG 🧚 another (less common) name for them is a TLG. like ALGs, they get used for a variety of purposes, some well established and meeting needs that nothing else meets 💜 early examples ran on MIT's ITS and TOPS-20 PDP-10s on the ARPANET and let Chaosnet-only hosts make outgoing connections from Chaosnet onto TCP/IP. later there were some uses of TCP-TP4 relays 🕰️ a transport relay between IPv6-only and IPv4-only hosts is one of the tools of IPv6 transition:

[TRANS64]

TLGs are sometimes used with simple packet filtering firewalls to enforce restrictions on which hosts can talk to the outside world, or to kludge around weird IP routing configs 🙃 they're also sometimes used to gateway between two instances of the same transport protocol with significantly different connection characteristics. that's the sense in which a TLG might also be called a TCP or transport spoofer 🫣 in that role, a TLG might shade into being an optimising rather than a functional middlebox. it's distinguished from Transport Proxies (the next section) by the fact that it only makes its optimisations by creating back-to-back connections, not by modifying or re-timing TCP messages ✨

terminating one TCP connection and starting another mid-path means the TCP checksum doesn't cover the sender's data end-to-end 😱 data corruptions or modifications can be introduced when the data gets transferred from the first connection to the second. some TCP relays are split relays and have even more potential for lost data integrity, because there may be more than two TCP connections and multiple nodes and network paths involved. in all cases, the sender has less than the expected assurance of data integrity that the TCP reliable byte stream service normally gives. and this problem isn't unique to middleboxes, because checksum offloading TCP implementations within the sender can cause it too, for example 🙈

in some of these cases, other session layer mechanisms like SSH or HTTPS would detect any loss of data integrity at the TCP level, which leads not to retransmission like with TCP, but to session failure 💔 however, there's no general session mechanism to add application data integrity, so you can't detect or mitigate a possible lack of TCP data integrity that way 🥲

{1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 functional
(mainly), 6 routing, 7 hard, 8 restart}

2.7. TCP performance enhancing proxies ✨

Okay bestie, "TCP spoofer" 🕵️‍♀️ is a term people toss around for middleboxes that change the timing or action of TCP while a connection is live, all to make things faster 🚀. A more accurate name is TCP performance enhancing proxy (PEP) 💅. Most TCP PEPs are proprietary, and we've mostly learned about them when they cause interoperability errors with standard TCP 😭. Same energy as TLGs: a TCP PEP can actually be the right answer for a problem nothing else solves 🫶. For example, it can re-space ACKs that got bunched together by a link with bursty service, so you don't get those undesireable data segment bursts 🌊. The PILC (Performance Implications of Link Characteristics) working group analyzed the types of TCP PEPs and where they're useful [PILCPEP]. Just know that TCP PEPs can introduce not only TCP errors, but also unintended changes in TCP adaptive behavior 🙈.

{1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising,
6 routing, 7 hard, 8 restart}

2.8. Load balancers that divert/munge packets. 🎀

There's a whole variety of techniques that divert packets away from their intended IP destination, or make that destination ambiguous 🌀. The usual motivation is balancing load across servers, or even splitting applications across servers with IP routing based on the destination port number 🧩. Except for rare one-shot UDP protocols, these techniques are inevitably stateful, because all packets from the same application session need to land on the same physical server 🎯. (A sophisticated solution would also be able to handle failover, which is giving main character reliability 👑.)

Right now these techniques are proprietary, so they can only be applied in closely managed environments 🔒.

{1 multi-layer, 2 implicit, 3 single hop, 4 in-line, 5 optimising, 6
routing, 7 hard, 8 restart}

2.9. IP Firewalls 🧱

The simplest firewall is a router that screens and rejects packets based purely on fields in the IP and Transport headers (for example, disallowing incoming traffic to certain port numbers, or disallowing any traffic to certain subnets) 🙅‍♀️.

Firewalls haven't been the subject of standardisation, but some analysis has been done [RFC 2979] 📚.

Even a pure IP firewall doesn't alter the packets flowing through it. But by rejecting some of them, it can cause connectivity problems that are very hard for a user to understand and diagnose 😵‍💫.

"Stateless" firewalls typically allow all IP fragments through, since fragments don't contain enough upper-layer header information to make a filtering decision 🤷‍♀️. Lots of "stateful" firewalls therefore reassemble IP fragments (and re-fragment if necessary) so they don't leak fragments, especially fragments that could exploit bugs in the reassembly implementations of end receivers 🐛.

{1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
routing, 7 hard, 8 restart}

2.10. Application Firewalls 💻

Application-level firewalls act as a protocol end point and relay (for example, an SMTP client/server or a Web proxy agent) 🫧. They may:

1. implement a "safe" subset of the protocol,
2. perform extensive protocol validity checks,
3. use an implementation methodology designed to minimize the likelihood of bugs,
4. run in an insulated, "safe" environment, or
5. use some combination of these techniques in tandem.

Firewalls haven't been standardised, but some analysis has been done [RFC 2979]. The issue of firewall traversal using HTTP has also been discussed [HTTPSUB] 🌐.

{1 Application layer, 2 implicit, 3 multihop, 4 in-line, 5
functional, 6 processing, 7 hard, 8 restart}

2.11. Application-level gateways 🌉

These come in lots of shapes and forms ✨. NATs need ALGs for certain address-dependent protocols such as FTP. These don't change the semantics of the application protocol, they just do mechanical substitution of fields 🔧. At the other end of the scale, still using FTP as the example, gateways have been built between FTP and other file transfer protocols, like the OSI and DECnet (R) equivalents 🗂️. Either way, these gateways need to keep state for the sessions they handle, and if that state gets lost, the session will normally break irrevocably 💔.

Some ALGs also cause fragmentation problems. In this case the problem is arguably the result of a deliberate layer violation, like messing with the application data stream of an FTP control connection by twiddling TCP segments on the fly 🙃.

{1 Application layer, 2 implicit or explicit, 3 multihop, 4 in-line,
5 functional, 6 processing, 7 hard, 8 restart}

2.12. Gatekeepers/ session control boxes 🚪

Especially with the rise of IP Telephony, the need to create and manage sessions other than TCP connections has come up 📞. In a multimedia environment that has to handle name lookup, authentication, authorization, accounting, firewall traversal, and sometimes media conversion, having a third-party box establish and control the session looks like the inevitable solution 🧚. Examples include H.323 gatekeepers [H323], SIP servers [RFC 2543], and MEGACO controllers [RFC 3015] 💜.

{1 Application layer, 2 explicit, 3 multihop, 4 in-line or call-out,
5 functional, 6 processing, 7 hard, 8 restart?}

2.13. Transcoders 🎶

Transcoders are boxes that do some type of on-the-fly conversion of application level data 🔄. Examples include transcoding existing web pages for display on hand-held wireless devices, and transcoding between audio formats so digital mobile phones can talk to voice-over-IP services 📱. In lots of cases the end-systems can't do this transcoding themselves, and for voice in particular it has to happen in strict real time with extremely rapid failure recovery ⏱️.

Not all media translators are mandatory 🙌. They might just be an optimisation. For example, with multicast, if all the low-bandwidth receivers sit in one "corner" of the network, it would be inefficient for the sender to generate two streams, or to send both streams all the way across the network if the "thin" one is only needed far away from the sender 🌍. Generally, media translators are only useful if the two end systems don't have overlapping codecs, or if the overlapping set isn't a good network match 🎧.

{1 Application layer, 2 explicit or implicit, 3 single hop, 4 in-
line, 5 functional, 6 processing, 7 hard?, 8 restart or failover}

2.14. Proxies 🪞

HTTP1.1 [RFC 2616] defines a Web proxy like this:

"An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering."

A Web proxy may be paired with a firewall when the firewall doesn't allow outgoing HTTP packets 🔥. But HTTP makes using a proxy "voluntary", which means the client has to be configured to use the proxy ⚙️.

HTTP proxies do in fact terminate an IP packet flow and recreate another one 🔁. They still count as "middlebox" under the definition in Section 1.1, though, because the actual application sessions traverse them 🦋.

SIP proxies [RFC 2543] raise some interesting issues too, since they can "bend" the media pipe to also act as media translators 🎭. (A proxy can modify the session description so that media no longer travels end-to-end, and goes to a designated intermediate box instead.)

{1 Application layer, 2 explicit (HTTP) or implicit (interception), 3
multihop, 4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}.

Note: Some so-called Web proxies are implemented as "interception" devices that intercept HTTP packets and re-issue them with their own source address. Like NAT and SOCKs, this can disturb address-sensitive applications. Unfortunately, some vendors have caused confusion by mis-describing these as "transparent" proxies. Interception devices are anything but transparent. See [WREC] for a full discussion. 🙅‍♀️

2.15. Caches 🍓

Caches are of course used in many shapes and forms across the Internet, and they're in principle distinct from proxies 🧠. Here we mainly mean content caches, which are meant to optimise user response times ⚡. HTTP makes provision for proxies to act as caches, by providing both expiration and re-validation mechanisms for cached content 🗓️. These mechanisms can be used to guarantee that specific content is not cached, which is a requirement for transient content, particularly in transactional applications 🛒. HTTP caching is well described in Section 13 of [RFC 2616], and in the HTTP case, caches and proxies are inextricably mixed 💞.

To improve optimisation, caching isn't only done between the origin server and the proxy cache directly serving the user. If there's a network of caches, the nearest copy of the required content may be in a peer cache 🤝. For this, an inter-cache protocol is required. At present, the most widely deployed solution is Internet Cache Protocol (ICP) [RFC 2186], although there have been alternative proposals such as [RFC 2756] 🌈.

It can be argued that caches terminate the application sessions and shouldn't be counted as middleboxes (any more than we count SMTP relays) 🤔. However, we've arbitrarily chosen to include them, since they do in practice re-issue the client's HTTP request on a cache miss, and they aren't the ultimate source of the application data 🫶.

{1 Application layer, 2 explicit (if HTTP proxy caches), 3 multihop,
4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}

2.16. Modified DNS servers 🧚‍♀️

DNS servers can play games 🎲. As long as they appear to deliver a syntactically correct response to every query, they can fiddle with the semantics 🙈. For example, names can be made into "anycast" names by arranging for them to resolve to different IP addresses in different parts of the network 🗺️. Or load can be shared among members of a server farm by having the local DNS server return the address of different servers in turn 🔁. In a NAT environment, it's not uncommon for the FQDN-to-address mapping to be quite different outside and inside the NAT (a.k.a. "two-faced DNS") 👀.

Modified DNS servers aren't intermediaries in the application data flow of interest. They're included here because they mean that independent sessions that look like they involve a single host actually involve multiple hosts, which can have subtle effects 😳. State created in host A.FOR.EXAMPLE by one session may turn out not to be there when a second session, apparently to the same host, is started, because the DNS server has directed the second session somewhere else 👻.

If such a DNS server fails, users may fail over to an alternate DNS server that doesn't know the same tricks, with unpredictable results 💀.

{1 Application layer, 2 implicit, 3 multihop, 4 in-line (on DNS query
path), 5 functional or optimising, 6 processing, 7 soft, 8 failover}

2.17. Content and applications distribution boxes

okay so the next level up from caching is content distribution and application distribution 🌸 the idea is that content (like static web stuff or streaming multimedia 📺) gets replicated ahead of time to lots of widely distributed servers ✨ and even interactive or straight-up transactional apps can be remotely replicated, along with some of their associated data 💻 this is a super recent model, so tbh it can't be said there's an industry standard practice yet 🥺 [WREC] talks about some of the issues, and several new IETF activities have been proposed in this area 🦋

content distribution solutions love to play with URLs in one way or another 🔗 and they often involve a whole system of middleboxes 🧚 like using HTTP redirects to send a request for WWW.EXAMPLE.COM off to WWW.EXAMPLE.NET, where the latter name may be an "anycast" name as mentioned above, and will actually resolve in DNS to the nearest instance of a content distribution box 💅

as with caches, it's an arbitrary choice to include these devices 🤷‍♀️ on the grounds that although they terminate the client session, they are not the ultimate origin of the application's data 💜

{1 Application layer, 2 implicit or explicit, 3 multihop, 4 in-line or call-out, 5 optimising, 6 routing or processing, 7 soft, 8 restart?}

2.18. Load balancers that divert/munge URLs

the URL redirect trick is giving DNS tricks energy 🎀 it can be used to balance load among a pool of servers, which is basically a local version of a content distribution network 🌈 or, alternatively, an HTTP proxy can rewrite HTTP requests to point them at one particular member of a pool of servers 🍓

these devices count as middleboxes because they divert an application's session in an arbitrary way 🙈

{1 Application layer, 2 explicit, 3 single hop, 4 in-line, 5 functional, 6 routing, 7 soft, 8 restart}

2.19. Application-level interceptors

some forms of pseudo-proxy intercept HTTP packets and deliver them to a local proxy server instead of forwarding them to the intended destination 😳 so the destination IP address in the packet gets ignored, which is wild 💀 it's hard to say whether this is a functional box (basically a non-standard proxy) or an optimising box (a way of forcing the user to use a cache) 🤔 and like any non-standard proxy, it has undefined consequences when it comes to dynamic or non-cacheable content 🫠

{1 Application layer, 2 implicit, 3 single hop, 4 in-line, 5 functional or optimising, 6 routing, 7 hard, 8 restart}

2.20. Application-level multicast

some (mainly proprietary) applications, including some approaches to instant messaging, use an application-level mechanism to replicate packets to multiple destinations 📨✨

an example is given in [CHU] 📖

{1 Application layer, 2 explicit, 3 multihop, 4 in-line, 5 functional, 6 routing, 7 hard, 8 restart}

2.21. Involuntary packet redirection

okay this one is a whole mood 😤 there appear to be a few instances of boxes that redirect packets for functional reasons, based on application-level content or other information above the network layer 👀 for example, more than one "high speed Internet" service offered in hotel rooms intercepts initial HTTP requests and diverts them to an HTTP server that demands payment before it opens up access to the Internet 💸 these boxes usually also perform NAT functions too 🙃

{1 multi-layer, 2 implicit, 3 single hop, 4 call-out, 5 functional, 6 routing, 7 hard, 8 restart}

2.22. Anonymisers

anonymiser boxes can be implemented in various ways that hide the IP address of the data sender or receiver 🥷 the implementation may be distinct, but in practice this is very similar to a NAT plus ALG 🎭

{1 multi-layer, 2 implicit or explicit, 3 multihop, 4 in-line, 5 functional, 6 processing, 7 hard, 8 restart}

2.23. Not included

some candidates suggested for the list above got excluded, and here's why 📝 in general, they don't fundamentally change the architectural model of packet delivery from source to destination 🛣️

• bridges and switches that snoop ARP, IGMP etc. These are below the IP layer, but they use a layer violation to emulate network layer functions. They don't change IP layer functions.
• wiretaps and snoopers in general. If they're working correctly, they have no impact on traffic, so they don't require analysis 🕵️‍♀️
• Mobile IP home agents are intended to assist packet delivery to the originally desired destination, so they're excluded on the same grounds as standard routers 🧭
• relays in interplanetary networks. Although these would certainly appear to be middleboxes, they aren't currently deployed 🪐

2.24. Summary of facets

okay the big tally time 📊 by tabulating the rough classifications above, we can see that out of the 22 classes of middlebox described:

• 17 are application or multi-layer
• 16 are implicit (and others are explicit OR implicit)
• 17 are multi-hop
• 21 are in-line; call-out is rare
• 18 are functional; pure optimisation is rare
• routing & processing are evenly split
• 16 have hard state
• 21 must restart session on failure

so we can deduce that current types of middlebox are predominantly application layer devices, not designed as part of the relevant protocol 🙀 they perform required functions, maintain hard state, and abort user sessions when they crash 💥 honestly? this is a profound challenge to the end-to-end hourglass model 🥹👑

3. Ongoing work in the IETF and elsewhere

apart from the work cited in the references above, current or planned work in the IETF includes 📚

MIDCOM is a working group focused on the architectural framework and the requirements for the protocol between a requesting device and a middlebox, and the architectural framework for the interface between a middlebox and a policy entity [MIDFRAME, MIDARCH] 🎀 this may interact with session control issues [SIPFIRE] 📞

work is also proceeding outside the MIDCOM group on middlebox discovery [MIDDISC] 🔍

WEBI (Web Intermediaries) is a working group that addresses specific issues in the world wide web infrastructure (as identified by the WREC working group) by providing generic mechanisms that are useful in several application domains, like proxies and content delivery surrogates 🌐 the specific mechanisms will be Intermediary Discovery and Description and a Resource Update Protocol ✨

intermediaries are also a big focus in the development of XML Protocol by the World-Wide Web Consortium, who have published an interesting analysis [XMLPI] 🧠

OPES (Open Pluggable Extension Services) is a proposed working group whose output will enable the construction of services executed on application data by participating transit intermediaries 🧩 caching is the most basic intermediary service, one that requires a basic understanding of application semantics by the cache server 🫶

CDI (Content Distribution Internetworking) is a potential working group for allowing cooperation between different Content Distribution Networks and cache clusters [CDNP] 🤝

RSERPOOL (Reliable Server Pooling) is a working group that will define architecture and requirements for management and access to server pools 🏊‍♀️ that includes requirements from a variety of applications, building blocks and interfaces, different styles of pooling, security requirements, and performance requirements such as failover times and coping with heterogeneous latencies ⏱️

4. Comments and Issues

okay the big question 🧐 a review of the list in Section 2 suggests that middleboxes fit into one or more of three broad categories:

1. mechanisms to connect dissimilar networks to enable cross-protocol interoperability 🔌
2. mechanisms to separate similar networks into zones, especially security zones 🔐
3. performance enhancement 🚀

as observed in [RFC 2775], the rise of middleboxes puts into question the general applicability of the end-to-end principle [RFC 1958] 😭 middleboxes introduce dependencies and hidden points of failure that violate the fate-sharing aspect of the end-to-end principle 💔 so can we define architectural principles that guarantee robustness in the presence of middleboxes? 🥺🙏

4.1. The end to end principle under challenge

okay this section is the drama 🎭 many forms of middlebox are explicitly addressed at the IP level, and terminate a transport connection (or act as a final destination for UDP packets) in a normal way 💅 although they're potential single points of failure, they don't otherwise interfere with the end to end principle [RFC 1958] (this statement does not apply to transport relays or TCP spoofers, because they do not terminate a transport connection at the expected destination in the normal way 🙅‍♀️)

however, there's a general feeling that middleboxes which divert an IP packet from its intended destination, or substantively modify its content on the fly, are fundamentally different from those that correctly terminate a transport connection and carry out their manipulations at the application level 😤 such diversion or modification violates the basic architectural assumption that packets flow from source to destination essentially unchanged (except for time-to-live and QOS-related fields) 🛑 the effects of such changes on transport and applications are unpredictable in the general case 👻

much of the analysis that applies to NAT [RFC 2993, RFC 3027] will also apply to RSIP, NAT-PT, DSTM, SOCKS, and involuntary packet redirectors 🔁 interception proxies, anonymisers, and some types of load balancer can also have subtle effects on address-sensitive applications, when they cause packets to be delivered to or from a different address 🫣 and transport relays and TCP spoofers may deceive applications by delivering an unreliable service on a TCP socket 🥴

we conclude that: although the rise of middleboxes has a negative impact on the end to end principle at the packet level, it does not nullify it as a useful or desirable principle of application protocol design. however, future application protocols should be designed in recognition of the likely presence of network address translation, packet diversion, and packet level firewalls along the data path. 🌟💖

4.2. Failure handling 🫶

okay so, if a middlebox crashes mid-session, the goal is for it to be inconvenient and not catastrophic 💀. There seem to be three ways to get there:

• Soft state mechanisms. The session keeps going without the box, probably slower, until the session state gets rebuilt automatically in an alternative box (or the original one, once it's restarted). So the state optimises the user session but isn't essential. A true caching mechanism is a good example, since its temporary failure only reduces performance.
• Rapid failover mechanisms. The session gets promptly redirected to a hot spare box that already has a copy of the necessary session state. ⚡
• Rapid restart mechanisms. The two ends of the session quickly detect the failure and restart it themselves via a spare box, without being externally redirected. Enough session state is kept at each end to recover from the glitch. 🦋

It seems likely that "optimising" middleboxes are good candidates for the soft state approach and for non-real-time data streams, since the box failing isn't catastrophic for the user. (Configured HTTP proxies used as caches are an awkward case, because their failure causes client failure. 😭) On the other hand, "functional" middleboxes have to be present for the session to continue, so they're candidates for rapid failover or rapid restart mechanisms. We conclude that:

Middlebox design should include a clear mechanism for dealing with failure.

---

4.3. Failures at multiple layers 🧩

Things get messy when middlebox functions live at different layers, like this setup where B and C aren't in the same physical box:

   Apps layer:     A ------------------------> C ------> D

   Lower layer:    A -----> B -------------------------> D

When all is well, i.e., there's an IP path from A to B to C to D and both B and C are working, this can look pretty workable. But the failure modes are brutal 😤. For example, if there's a network failure between C and D, how is B instructed to divert the session to a backup box for C?. Since C and B function at different protocol layers, there's no expectation that they'll have coordinated failure recovery mechanisms. Unless this gets fixed in some general way, we conclude that

Middlebox failure recovery mechanisms cannot currently assume they will get any help from other layers, and must have their own means of dealing with failures in other layers.

In the long term future, we should be able to state clearly for each middlebox function what it expects from its environment, and make recommendations about which middlebox functions should be bound together if deployed. 🔮

---

4.4. Multihop application protocols 🐝

Let's also notice that protocols like SMTP, UUCP, and NNTP have always worked hop-by-hop, i.e., via multiple middleboxes. Nobody considers this an issue or a problem. Trouble starts when you insert a middlebox into an application protocol stream that wasn't designed for it. We conclude that:

New application protocol designs should include explicit mechanisms for the insertion of middleboxes, and should consider the facets identified in Section 2 above as part of the design.

A specific challenge is how to make interactive or real-time applications ride smoothly over middleboxes. This will put particular stress on the failure handling aspects. 🎢

---

4.5. Common features 🌟

Since the IP layer (the neck of the hourglass) isn't alone in its role supporting end-to-end connectivity anymore, it would be desirable to define requirements and features that are common to middlebox intermediaries. Then it'd be possible to implement middleboxes, and especially the protocols that talk to them, fully from the stance of supporting the end-to-end principle. Conceptually, this would extend the neck of the hourglass upwards to include a set of common features available to all (or many) applications. For middleboxes and multihop protocols, this would require common features addressing at least:

• Middlebox discovery and monitoring
• Middlebox configuration and control
• Call-out
• Routing preferences
• Failover and restart handling
• Security, including mutual authentication

As far as possible, the solutions in these areas being developed in the IETF and W3C should be general enough to cover all types of middlebox. If not, the work will be done several times. 🔁

---

5. Security Considerations 🔐

Security risks are specific to each type of middlebox, so there isn't much to say in general. Of course, adding extra boxes in the communication path creates extra points of attack, reduces or eliminates the ability to perform end to end encryption, and complicates trust models and key distribution models. So every middlebox design needs particular attention to security analysis. A few general points:

1. The interference with end-to-end packet transmission by many types of middlebox is a crippling impediment to generalised use of IPSEC in its present form, and also invalidates transport layer security in many scenarios. 💀
2. Middleboxes require us to move definitively from a two-way to an N-way approach to trust relationships and key sharing.
3. The management and configuration mechanisms of middleboxes are a tempting point of attack, and must be strongly defended. 🚨

These points suggest that we need a whole new approach to security solutions, as the middlebox paradigm ends up being deployed in lots of different technologies. That's if only to avoid each new technology designing a end-to-end security solution appropriate to its particular impact on the data stream. It's giving chaos, bestie 😭

Additionally, content caches and content distribution mechanisms raise the issue of access control for content that is subject to copyright or other rights. Distributed authentication, authorisation and accounting are required. 🎟️

---

6. Acknowledgements 🙏

Steve Bellovin, Jon Crowcroft, Steve Deering, Patrik Faltstrom, Henning Schulzrinne, and Lixia Zhang all gave valuable feedback on early versions of this document. Rob Austein and Allison Mankin drafted the text on transport relays and TCP spoofers, and Rob Austein made other substantial contributions. Participants in the MIDTAX BOF at the 50th IETF and on the MIDTAX mailing list, including Harald Alverstrand, Stanislav Shalunov, Michael Smirnov, Jeff Parker, Sandy Murphy, David Martin, Phil Neumiller, Eric Travis, Ed Bowen, Sally Floyd, Ian Cooper, Mike Fisk and Eric Fleischman gave invaluable input. Mark Nottingham brought the W3C work to our attention. Melinda Shore suggested using a facet-based categorization. Patrik Faltstrom inspired section 4.3. 🌈💖

7. References 📚

okay bestie, the reading list is here 🫶 every paper, RFC, and draft this whole doc leaned on, with the exact details so nobody gets lost. "Work in Progress" means it was still a draft when this was written 🌸

• [RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
• [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", March 1996.
• [RFC 1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
• [RFC 2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), version 2", RFC 2186, September 1997.
• [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
• [RFC 2543] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
• [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
• [RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
• [RFC 2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol (HTCP/0.0)", RFC 2756, January 2000.
• [RFC 2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
• [RFC 2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
• [RFC 2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
• [RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
• [RFC 2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
• [RFC 3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol 1.0", RFC 3015, November 2000.
• [RFC 3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
• [RFC 3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
• [CHU] Y. Chu, S. Rao, and H. Zhang, A Case for End System Multicast, SIGMETRICS, June 2000. http://citeseer.nj.nec.com/chu00case.html
• [CLARK88] The Design Philosophy of the DARPA Internet Protocols, D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988, pages 106-114 (reprinted in ACM CCR Vol 25, Number 1, January 1995, pages 102-111).
• [CLARK95] "Adding Service Discrimination to the Internet", D.D. Clark, Proceedings of the 23rd Annual Telecommunications Policy Research Conference (TPRC), Solomons, MD, October 1995.
• [CDNP] M. Day, et al., "A Model for Content Internetworking (CDI)", Work in Progress.
• [DSTM] J. Bound, L. Toutain, F. Dupont, O. Medina, H. Afifi, A. Durand, "Dual Stack Transition Mechanism (DSTM)", Work in Progress.
• [H323] ITU-T Recommendation H.323: "Packet Based Multimedia Communication Systems".
• [HOURG] "Realizing the Information Future: The Internet and Beyond", Computer Science and Telecommunications Board, National Research Council, Washington, D.C., National Academy Press, 1994. However, the "hourglass" metaphor was first used by John Aschenbrenner in 1979, with reference to the ISO Open Systems Interconnection model.
• [HTTPSUB] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
• [MIDARCH] E. Lear, "A Middlebox Architectural Framework", Work in Progress.
• [MIDDISC] E. Lear, "Requirements for Discovering Middleboxes", Work in Progress.
• [MIDFRAME] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, "Middlebox Communication: Framework and Requirements", Work in Progress.
• [PILCPEP] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
• [RSIP] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
• [SALTZER] End-To-End Arguments in System Design, J.H. Saltzer, D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288.
• [SIPFIRE] S. Moyer, D. Marples, S. Tsang, J. Katz, P. Gurung, T. Cheng, A. Dutta, H. Schulzrinne, A. Roychowdhury, "Framework Draft for Networked Appliances Using the Session Initiation Protocol", Work in Progress.
• [SOCKS6] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
• [TRANS64] "Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication", Work in Progress.
• [WREC] Cooper, I, Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.
• [XMLPI] Intermediaries and XML Protocol, Mark Nottingham, Work in Progress at http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0045.html

---

Authors' Addresses 🎀

meet the two authors, the people who wrote all of this 💜

Brian E. Carpenter
IBM Zurich Research Laboratory
Saeumerstrasse 4 / Postfach
8803 Rueschlikon
Switzerland

EMail: brian@hursley.ibm.com


Scott W. Brim
146 Honness Lane
Ithaca, NY 14850
USA

EMail: sbrim@cisco.com

---

Full Copyright Statement ⭐

Copyright (C) The Internet Society (2002). All Rights Reserved.

okay so here's the legal stuff 💅 you're allowed to copy this document and share it with others, and you can make derivative works that comment on or explain it or help with implementing it. you can publish and distribute those too, in whole or in part, with no restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative work.

the one catch: this document itself can't be modified in any way. that includes removing the copyright notice or the references to the Internet Society or other Internet organizations. the exceptions are developing Internet standards (in which case the Internet Standards process copyright procedures must be followed) or translating it into languages other than English 🌈

the permissions above are perpetual, meaning the Internet Society or its successors or assigns won't revoke them ✨

and the disclaimer, which is serious and not very cute 🙈

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

---

Acknowledgement 🌸

the last bit: funding for the RFC Editor function is currently provided by the Internet Society. thank you to the people keeping the lights on for all these documents 🫶