RFC 3303
Middlebox communication architecture and framework
Middlebox communication architecture and framework 🦋
okay bestie, this is RFC 3303 💖 It's called "Middlebox communication architecture and framework," and it's Informational, so it's sharing info, not setting a standard 💅 It came out in August 2002. Five people wrote it: P. Srisuresh from Kuokoa Networks, J. Kuthan from Fraunhofer Institute FOKUS, J. Rosenberg from dynamicsoft, A. Molitor from Aravox Technologies, and A. Rayhan from Ryerson University 🌸 It doesn't say it obsoletes or updates any other RFC, so it's totally its own thing ✨
Status of this Memo 📜
This memo gives info to the Internet community. It doesn't specify an Internet standard of any kind. Distribution of this memo is unlimited 🫶
Copyright Notice 🔒
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract 🌈
okay so the main goal of this doc is to describe the underlying framework of middlebox communications (MIDCOM) 🎀 The whole point is to let complex applications get through middleboxes smoothly, with the help of a trusted third party. This document and a companion document on MIDCOM requirements ([REQMTS]) were made as a precursor to rechartering the MIDCOM working group 💜
There are a bunch of intermediate devices on the Internet today that need application intelligence to do their job. Datagrams from real-time streaming apps like SIP and H.323, and peer-to-peer apps like Napster and NetMeeting, can't be identified just by looking at packet headers 🙈 Middleboxes doing Firewall and Network Address Translator services usually have application intelligence built right into the device so they can work 😭 This document specifies an architecture and framework where trusted third parties can be delegated to help middleboxes do their thing, without needing to embed application intelligence. That way a middlebox can keep providing its services while staying application agnostic 👑
1. Introduction ✨
okay, intermediate devices that need application intelligence are the subject of this doc 💅 These devices are called middleboxes throughout the document. A lot of them enforce application-specific policy functions like packet filtering, VPN (Virtual Private Network) tunneling, intrusion detection, security, and so forth 🔥 Network Address Translator service is different, though. It gives routing transparency across address realms (within an IPv4 routing network, or across V4 and V6 routing realms), and it doesn't depend on applications 💖 Application Level Gateways (ALGs) work together with NAT to examine and optionally modify application payload, so that end-to-end application behavior stays the same for lots of applications going through NAT middleboxes 🦋 There could be other kinds of services that need application intelligence embedded in middleboxes to work. But this document's scope is limited to Firewall and NAT services. Still, the MIDCOM framework is designed to be extensible so new services can be deployed ✨
Tight coupling of application intelligence with middleboxes makes them hard to maintain as new applications show up 😩 Built-in application awareness usually means you need to update operating systems for new applications, or newer versions of existing ones. Operators who need support for newer apps can't use third-party software or hardware specific to that app, so they're totally at the mercy of their middlebox vendor for the upgrade 💀 Also, stuffing intelligence for a ton of application protocols into the same middlebox makes it more complex, probably more error-prone, and likely to slow down 🙈
This document describes a framework where application intelligence can be moved out of middleboxes and into external MIDCOM agents 🧚 The premise is to design a MIDCOM protocol that's application independent, so middleboxes can stay focused on services like firewall and NAT 🌸 The framework document includes some explicit and implied requirements for the MIDCOM protocol. But it has to be noted that these requirements are only a subset. A separate requirements document lists the requirements in detail 📝
MIDCOM agents with application intelligence can help middleboxes, through the MIDCOM protocol, to allow applications like FTP, SIP, and H.323 🎀 The communication between a MIDCOM agent and a middlebox won't be noticeable to the end-hosts taking part in the application, unless one of those end-hosts takes on the role of a MIDCOM agent 🫶 Discovery of middleboxes or MIDCOM agents in the path of an application instance is outside the scope of this document. And any communication among middleboxes is also outside its scope 🚫
This document describes the framework where middlebox communication happens, and the various elements that make up the framework. Section 2 describes the terms used in the document. Section 3 defines the architectural framework of a middlebox for communicating with MIDCOM agents. The remaining sections cover the components of the framework, illustrate it using sample flows, and go over operational considerations for the MIDCOM architecture. Section 4 describes the nature of the MIDCOM protocol. Section 5 identifies entities that could potentially host the MIDCOM agent function. Section 6 considers the role of the Policy server and its function with regard to communicating MIDCOM agent authorization policies. Section 7 is an illustration of SIP flows using a MIDCOM framework, where the MIDCOM agent is co-resident on a SIP proxy server. Section 8 addresses operational considerations in deploying a protocol that adheres to the framework described here. Section 9 is an applicability statement, scoping the location of middleboxes. Section 11 outlines security considerations for the middlebox in view of the MIDCOM framework 🔐
2. Terminology 🎀
Below are the definitions for the terms used throughout the document 📖
2.1. Middlebox function/service 💜
A middlebox function or a middlebox service is an operation or method performed by a network intermediary that may require application-specific intelligence for its operation. Policy-based packet filtering (a.k.a. firewall), Network address translation (NAT), Intrusion detection, Load balancing, Policy-based tunneling, and IPsec security are all examples of a middlebox function (or service) 🔥
2.2. Middlebox 🦋
A Middlebox is a network intermediate device that implements one or more of the middlebox services. A NAT middlebox is a middlebox implementing NAT service. A firewall middlebox is a middlebox implementing firewall service 💖
Traditional middleboxes embed application intelligence within the device to support specific application traversal. Middleboxes supporting the MIDCOM protocol will be able to externalize application intelligence into MIDCOM agents 🧚 In reality, some middleboxes may keep embedding application intelligence for certain applications, and depend on the MIDCOM protocol and MIDCOM agents for the rest 🌈
2.3. Firewall 🧱
Firewall is a policy-based packet filtering middlebox function, typically used for restricting access to and from specific devices and applications. The policies are often termed Access Control Lists (ACLs) 🔒
2.4. NAT 🌸
Network Address Translation is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end-hosts 🗺️ Transparent routing here means modifying end-node addresses en route and maintaining state for these updates, so that when a datagram leaves one realm and enters another, datagrams belonging to a session get forwarded to the right end-host in either realm 🎀 Refer to [NAT-TERM] for the definition of transparent routing, the various NAT types, and the associated terms in use. Two types of NAT are the most common. The first is Basic-NAT, where only an IP address (and the related IP and TCP/UDP checksums) of packets is altered. The second is NAPT (Network Address Port Translation), where both an IP address and a transport layer identifier, such as a TCP/UDP port (and the related IP and TCP/UDP checksums), are altered 💅
The term NAT in this document is very similar to the IPv4 NAT described in [NAT-TERM], but it's extended beyond IPv4 networks to include the IPv4-v6 NAT-PT described in [NAT-PT]. While IPv4 NAT [NAT-TERM] translates one IPv4 address into another IPv4 address to provide routing between private V4 and external V4 address realms, IPv4-v6 NAT-PT [NAT-PT] translates an IPv4 address into an IPv6 address, and vice versa, to provide routing between a V6 address realm and an external V4 address realm 🌐
Unless specified otherwise, NAT in this document is a middlebox function referring to both IPv4 NAT and IPv4-v6 NAT-PT 💫
2.5. Proxy 🧚♀️
A proxy is an intermediate relay agent between clients and servers of an application, relaying application messages between the two. Proxies use special protocol mechanisms to communicate with proxy clients and to relay client data to servers, and vice versa. A Proxy terminates sessions with both the client and the server, acting as a server to the end-host client and as a client to the end-host server 🦋
Applications such as FTP, SIP, and RTSP use a control session to establish data sessions. These control and data sessions can take divergent paths. While a proxy can intercept both the control and data sessions, it might intercept only the control session. This is often the case with real-time streaming applications such as SIP and RTSP 🎶
2.6. ALG 🧠
Application Level Gateways (ALGs) are entities that possess the application-specific intelligence and knowledge of an associated middlebox function. An ALG examines application traffic in transit and assists the middlebox in carrying out its function 👀
An ALG may be co-resident with a middlebox or reside externally, communicating through a middlebox communication protocol. It interacts with a middlebox to set up state, access control filters, use middlebox state information, modify application-specific payload, or perform whatever else is necessary to enable the application to run through the middlebox 💜
ALGs are different from proxies. ALGs aren't visible to end-hosts, unlike proxies, which are relay agents terminating sessions with both end-hosts. ALGs don't terminate sessions with either end-host. Instead, ALGs examine, and optionally modify, application payload content to facilitate the flow of application traffic through a middlebox. ALGs are middlebox-centric, in that they assist middleboxes in carrying out their function, whereas proxies act as a focal point for application servers, relaying traffic between application clients and servers 🎀
ALGs are similar to proxies in that both ALGs and proxies facilitate application-specific communication between clients and servers 🫶
2.7. End-Hosts 🎧
okay so end-hosts are the entities that are party to a networked application instance 💖. In this doc, we specifically mean the ones terminating real-time streaming Voice-over-IP apps like SIP and H.323, plus peer-to-peer apps like Napster and NetMeeting 📞
2.8. MIDCOM Agents 🧚
MIDCOM agents are entities performing ALG functions, and they're logically external to a middlebox 🦋. They have application awareness plus knowledge of the middlebox function, and that combo lets them help the application's packets get through the middlebox. One MIDCOM agent may interact with one or more middleboxes 💅
Only "In-Path MIDCOM agents" are considered in this document. In-Path MIDCOM agents sit within the path of the datagrams the agent needs to examine and/or modify to do its MIDCOM job 👀. "Within the path" just means the packets flow through the node hosting the agent. The packets may be addressed to the agent node at the IP layer. Or they might not be addressed to it, but other factors constrain them to flow through it. Honestly, the MIDCOM protocol doesn't care which one it is 🙈 Some examples of In-Path MIDCOM agents are application proxies, gateways, or even end-hosts that are party to the application ✨
Agents not resident on nodes within the path of their relevant application flows are called "Out-of-Path (OOP) MIDCOM agents", and they're out of scope for this doc 🚫
2.9. MIDCOM PDP 👑
MIDCOM Policy Decision Point (PDP) is primarily a Policy Decision Point(PDP), as defined in [POL-TERM], and it also acts as a policy repository, holding MIDCOM related policy profiles so it can make authorization decisions 🍓 According to [POL-TERM], a PDP is "a logical entity that makes policy decisions for itself or for other network elements that request such decisions", and a policy repository is "a specific data store that holds policy rules, their conditions and actions, and related policy data" 📚
A middlebox and a MIDCOM PDP may communicate further if the MIDCOM PDP's policy changes or if a middlebox needs further information 💬 The MIDCOM PDP may, at any time, notify the middlebox to terminate authorization for an agent 🛑
The protocol facilitating the communication between a middlebox and MIDCOM PDP need not be part of the MIDCOM protocol. Section 6 in the document addresses the MIDCOM PDP interface and protocol framework independent of the MIDCOM framework 🧩
Application specific policy data and policy interface between an agent or application endpoint and a MIDCOM PDP is out of bounds for this document 🙅♀️ The MIDCOM PDP issues addressed in the document are focused at an aggregate domain level, as befitting the middlebox. For example, a SIP MIDCOM agent may choose to query a MIDCOM PDP for the administrative (or corporate) domain to find whether a certain user is allowed to make an outgoing call 📲 This type of application specific policy data, as befitting an end user, is out of bounds for the MIDCOM PDP considered in this document. It is within bounds, however, for the MIDCOM PDP to specify the specific end-user applications (or tuples) for which an agent is permitted to be an ALG 🫶
2.10. Middlebox Communication (MIDCOM) protocol 🔌
The protocol between a MIDCOM agent and a middlebox lets the MIDCOM agent invoke services of the middlebox, and lets the middlebox delegate application specific processing to the MIDCOM agent 🤝 The MIDCOM protocol lets the middlebox do its operation with the aid of MIDCOM agents, without resorting to embedding application intelligence. The principal motivation behind architecting this protocol is to enable complex applications through middleboxes, seamlessly using a trusted third party, i.e., a MIDCOM agent 🌈
This is a protocol yet to be devised. 🛠️
2.11. MIDCOM agent registration 📝
A MIDCOM agent registration is the process of provisioning agent profile information with the middlebox or a MIDCOM PDP. It's often a manual operation performed by an operator rather than the agent itself 🧑💻
A MIDCOM agent profile may include:
- agent authorization policy (i.e., session tuples for which the agent is authorized to act as ALG)
- agent-hosting-entity (e.g., Proxy, Gateway, or end-host which hosts the agent)
- agent accessibility profile (including any host level authentication information)
- security profile (for the messages exchanged between the middlebox and the agent) 🔐
2.12. MIDCOM session 🔗
A MIDCOM session is a lasting association between a MIDCOM agent and a middlebox 🌸 The MIDCOM session is not assumed to imply any specific transport layer protocol. Specifically, this should not be construed as referring to a connection-oriented TCP protocol 🙅♀️
2.13. Filter 🧺
A filter is packet matching information that identifies a set of packets to be treated a certain way by a middlebox 🎯 This definition is consistent with [POL-TERM], which defines a filter as "A set of terms and/or criteria used for the purpose of separating or categorizing. This is accomplished via single- or multi-field matching of traffic header and/or payload data" 🗂️
5-Tuple specification of packets in the case of a firewall and 5-tuple specification of a session in the case of a NAT middlebox function are examples of a filter 💜
2.14. Policy action (or) Action 🎬
Policy action (or Action) is a description of the middlebox treatment/service to be applied to a set of packets ✨ This definition is consistent with [POL-TERM], which defines a policy action as "Definition of what is to be done to enforce a policy rule, when the conditions of the rule are met. Policy actions may result in the execution of one or more operations to affect and/or configure network traffic and network resources" ⚡
NAT Address-BIND (or Port-BIND in the case of NAPT) and firewall permit/deny action are examples of an Action 🙌
2.15. Policy rule(s) 📜
The combination of one or more filters and one or more actions is a policy rule. Packets matching a filter are to be treated as specified by the associated action(s) 💅 The Policy rules may also contain auxiliary attributes such as individual rule type, timeout values, creating agent, etc. 🧾
Policy rules are communicated through the MIDCOM protocol 📡
3.0 Architectural framework for middleboxes 🏗️
A middlebox may implement one or more of the middlebox functions selectively on multiple interfaces of the device. There can be a variety of MIDCOM agents interfacing with the middlebox to communicate with one or more of the middlebox functions on an interface. So the middlebox communication protocol must allow for selective communication between a specific MIDCOM agent and one or more middlebox functions on the interface 🎀 The following diagram identifies a possible layering of the service supported by a middlebox and a list of MIDCOM agents that might interact with it 🖼️
+---------------+ +--------------+
| MIDCOM agent | | MIDCOM agent |
| co-resident on| | co-resident |
| Proxy Server | | on Appl. GW |
+---------------+ +--------------+
^ ^
| | +--------+
MIDCOM | | | MIDCOM |
Protocol | | +-| PDP |
| | / +--------+
+-------------+ | | /
| MIDCOM agent| | | /
| co-resident | | | /
| on End-hosts|<-+ | | /
+-------------+ | | | |
v v v v
+-------------------------------------------+
| Middlebox Communication |Policy |
| Protocol (MIDCOM) Interface |Interface |
+----------+--------+-----------+-----------+
Middlebox | | | | |
Functions | Firewall | NAT | VPN | Intrusion |
| | | tunneling | Detection |
+----------+--------+-----------+-----------+
Middlebox | Middlebox function specific policy rule(s)|
Managed | and other attributes |
Resources | |
+-------------------------------------------+Figure 1: MIDCOM agents interfacing with a middlebox
Firewall ACLs, NAT-BINDs, NAT address-maps and Session-state are a few of the middlebox function specific policy rules 🛡️ A session state may include middlebox function specific attributes, such as timeout values, NAT translation parameters (i.e., NAT-BINDS), and so forth. As Session-state may be shared across middlebox functions, a Session-state may be created by a function, and terminated by a different function. For example, a session-state may be created by the firewall function, but terminated by the NAT function, when a session timer expires ⏰
Application specific MIDCOM agents (co-resident on the middlebox or external to the middlebox) would examine the IP datagrams and help identify the application the datagram belongs to, and assist the middlebox in performing functions unique to the application and the middlebox service 🕵️♀️ For example, a MIDCOM agent, assisting a NAT middlebox, might perform payload translations, whereas a MIDCOM agent assisting a firewall middlebox might request the firewall to permit access to application specific, dynamically generated, session traffic 🥹
4. MIDCOM Protocol ✨
okay so the MIDCOM protocol is the thing that lets a MIDCOM agent talk to a middlebox 💅 The agent can invoke the middlebox's services, and the middlebox can hand off application-specific processing to the agent. The whole point is to let agents signal middleboxes so that complex apps using dynamic port-based sessions can get through them seamlessly 🦋
It's giving flexibility, and it's important to note that an agent and a middlebox can literally be on the same physical device 🫶 In that case they might use MIDCOM message formats but send them over a non-IP transport, like IPC messaging (or) they might talk through a well-defined API/DLL (or) the application intelligence is fully embedded in the middlebox service, which is how a lot of stateful inspection firewall and NAT devices work today 🔥
The MIDCOM protocol has three phases: a session setup phase, a run-time session phase, and a session termination phase 🎀
Session setup has to be preceded by registration of the MIDCOM agent with either the middlebox or the MIDCOM PDP 💖 The agent's access and authorization profile can be pre-configured on the middlebox (or) listed on a MIDCOM PDP, and the middlebox is set up to consult it. MIDCOM shall be a client-server protocol, and it's initiated by the agent 🧚
A MIDCOM session can be terminated by either party 💜 It can also be triggered when (a) the middlebox or the agent goes out of service and isn't available for further MIDCOM operations, or (b) the MIDCOM PDP tells the middlebox that a particular MIDCOM agent is no longer authorized 💀
The MIDCOM protocol data exchanged at run-time is mainly governed by the middlebox services the protocol supports. This document considers firewall and NAT middlebox services 🌸 That said, the MIDCOM framework is designed to be extensible, so other services can be deployed too ✨
5.0. MIDCOM Agents 🦋
okay, MIDCOM agents are logical entities that may physically live on nodes outside of a middlebox 🍓 They combine application awareness with knowledge of how the middlebox works. One agent may talk to one or more middleboxes 💅 How middleboxes discover agents (or the other way around) is out of scope for this doc. The real focus is the framework in which a MIDCOM agent talks to a middlebox using the MIDCOM protocol (which is yet to be devised 👀). Specifically, we're only looking at the In-Path agents 🫶
In-Path MIDCOM agents are agents that naturally sit in the message path of the applications they're associated with 🛣️ Bundled session applications, like H.323, SIP, and RTSP, have separate control and data sessions, and those sessions might take different paths 🙈 In those cases, In-Path MIDCOM agents are the ones that end up in the control path. Most of the time, a middlebox will only need one agent for an application in the control path alone 👑 But a middlebox function, or a specific application going through the middlebox, could need more than one MIDCOM agent for the same application, one for each sub-session of the application 🌈
Application Proxies and gateways are a great choice for In-Path MIDCOM agents, because by definition they sit in the path of an application between a client and a server 🔥 On top of hosting the MIDCOM agent function, these natively in-path, application-specific entities can also enforce application-specific choices locally, like dropping messages infected with known viruses, or messages lacking user authentication 🛡️ They can interject both the control and data sessions. For example, an FTP proxy server interjects both the FTP control and Data sessions 🦋
Proxies can also interject just the control session and not the data sessions, which is the case with real-time streaming applications like SIP and RTSP 🎧 Heads up, though: applications don't always go through a proxy, and some applications may not have a proxy server available at all 🥺
SIP proxies and H.323 gatekeepers can host MIDCOM agent functions to control middleboxes that implement firewall and NAT functions 💖 The good thing about using in-path entities instead of creating an entirely new agent is that they already have application intelligence. You just need to enable MIDCOM protocol use and they're an effective MIDCOM agent 🧚 Figure 2 below shows a scenario where in-path MIDCOM agents interface with the middlebox. Let's say the MIDCOM PDP has pre-configured the in-path proxies as trusted MIDCOM agents on the middlebox, and the packet filter implements a 'default-deny' packet filtering policy. The proxies use their application-awareness to control the firewall function and selectively permit a certain number of voice stream sessions dynamically using the MIDCOM protocol 🎀
In the illustration below, the proxies and the MIDCOM PDP are shown inside a private domain. But that doesn't mean they have to stay inside the private boundary 🙅♀️ The proxies can also live outside the domain. The only requirement is that there's a trust relationship with the middlebox 🤝
+-----------+
| MIDCOM |
| PDP |~~~~~~~~~~~~~|
+-----------+ \
\
+--------+ \
| SIP |___ \
________| Proxy | \ Middlebox \
/ +--------+.. | +--------------------+
| : | MIDCOM | | |
| RTSP +---------+ :..|........| MIDCOM | POLICY |
SIP | ____| RTSP |.....|........| PROTOCOL | INTER- |
| / | Proxy |___ | | INTERFACE | FACE |
| | +---------+ \ \ |--------------------|
| | \ \______| |__SIP
| | \________| |__RTSP
| | ---| FIREWALL |--->--
+-----------+ /---| |---<--
+-----------+| Data streams // +--------------------+
+-----------+||---------->----// |
|end-hosts ||-----------<----- .
+-----------+ (RTP, RTSP data, etc.) |
. Outside the
Within a private domain | private domain
Legend: ---- Application data path datagrams
____ Application control path datagrams
.... Middlebox Communication Protocol (MIDCOM)
~~~~ MIDCOM PDP Interface
|
. private domain Boundary
|
Figure 2: In-Path MIDCOM Agents for middlebox Communication5.1. End-hosts as In-Path MIDCOM agents 💻
End-hosts are another flavour of In-Path MIDCOM agent 🍒 Unlike proxies, end-hosts are a direct party to the application and have all the end-to-end application intelligence there is 🧠 They presumably terminate both the control and data paths of an application. Unlike other entities hosting MIDCOM agents, an end-host is able to process secure datagrams 🔐 The catch is manageability, since that means upgrading all the end-hosts running a specific application 😭
6.0. MIDCOM PDP functions 👑
The functional breakdown of the MIDCOM architecture assumes there's a logical entity called the MIDCOM PDP, which is responsible for authorization and related provisioning services for the middlebox, as shown in figure 1 🧚 The MIDCOM PDP is a logical entity that may physically live on the middlebox or on a node outside of it 🏠 The protocol used between the middlebox and the MIDCOM PDP has nothing to do with the MIDCOM protocol, so they're totally separate 🙌
Agents get registered with a MIDCOM PDP for authorization to invoke the middlebox's services 📝 The MIDCOM PDP keeps a list of the agents that are authorized to connect to each middlebox it supports 💜 In the context of the MIDCOM Framework, the MIDCOM PDP doesn't help a middlebox actually implement the services it provides 🙅♀️
The MIDCOM PDP acts in an advisory capacity to a middlebox: it authorizes an agent trying to connect, or terminates that authorization 🫡 Its main job is to communicate agent authorization info, so the security and integrity of the middlebox isn't put at risk 🛡️ Specifically, the MIDCOM PDP should associate a trust level with each agent trying to connect to a middlebox, and provide a security profile 🔥 It should also be capable of handling cases where end-hosts are agents to the middlebox 💅
6.1. Authentication, Integrity and Confidentiality 🔐
Okay bestie, there are two totally different security vibes here: host authenticity and individual message security 💅. Host authentication is about the credentials a MIDCOM agent needs to prove itself to the middlebox, and the middlebox has to prove itself back. When authentication fails, the middlebox must not process signaling requests from that agent. No cap, that's a hard stop 🚫. Two-way authentication should be supported. Sometimes the two-way auth is tied up with setting up keys to protect the traffic after it, and it's often needed to stop active attacks on the MIDCOM protocol and to set up keying material safely 🔥.
Then there's message security. Authentication, data integrity, confidentiality and replay protection may be adapted to secure MIDCOM messages in an untrusted domain 🛡️. Message authentication is the same as data origin authentication, which is basically proof that the sender is who they claim to be ✨. Data integrity means making sure a message hasn't been accidentally, maliciously or otherwise altered or destroyed. Confidentiality is encrypting a message with a key, so only people holding the key can read it 🔒. Replay protection is a form of sequence integrity. If an intruder plays back a recorded sequence of messages, the receiver will simply drop the replay messages into the bit-bucket 🗑️. Some applications might need non-repudiation as an option of the data integrity service. That's typically for billing, service level agreements, payment orders, and receipts for delivery of service 🧾.
IPsec AH ([IPSEC-AH]) offers data-origin authentication, data integrity and protection from message replay 💖. IPsec ESP ([IPSEC-ESP]) gives data-origin authentication to a lesser degree (same as IPsec AH if the MIDCOM transport protocol turns out to be TCP or UDP), plus message confidentiality, data integrity and protection from replay 🦋. Besides the IPsec based protocols, there are other options too. TLS based transport layer security is one, and there are also many application-layer security mechanisms available 🌈. Simple source-address based security is a minimal form of security and should be relied on only in the most trusted environments, where those hosts will not be spoofed 🙈.
The MIDCOM message security shall use existing standards, whenever the existing standards satisfy the requirements 📚. Security shall be specified to minimize the impact on sessions that do not use the security option 🌸. Security should be designed to avoid introducing denial of service attacks, and to minimize the impact of them if they happen 😭. Some security mechanisms and algorithms require substantial processing or storage. In that case, the security protocols should protect themselves, as well as against possible flooding attacks that overwhelm the endpoint (i.e., the middlebox or the agent) with that processing 💀. For connection oriented protocols (such as TCP) using security services, the security protocol should detect premature closure or truncation attacks 👑.
6.2. Registration and deregistration of MIDCOM agents 📋
Before MIDCOM agents can invoke services of the middlebox, a registration process must take place ✨. Registration is a different process from establishing a MIDCOM session, so don't mix them up, bestie 🙅♀️. Registration means provisioning agent profile information with the middlebox or a MIDCOM PDP. Agent registration is often a manual operation performed by an operator rather than by the agent itself 🧑💻. Setting up a MIDCOM session, on the other hand, refers to establishing a MIDCOM transport session and exchanging security credentials between an agent and a middlebox 🤝. The transport session uses the registered information for session establishment.
The profile of a MIDCOM agent includes a few things. First there's the agent authorization policy (i.e., the session tuples for which the agent is authorized to act as an ALG) 🎟️. Then there's the agent-hosting-entity (e.g., a Proxy, Gateway or end-host which hosts the agent) 🏠. Next is the agent accessibility profile, which includes any host level authentication information 🔑. Last but not least is the security profile (i.e., the security requirements for messages exchanged between the middlebox and the agent) 🔐.
The MIDCOM agent profile may be pre-configured on a middlebox 🎀. After that, the agent may choose to initiate a MIDCOM session before any data traffic shows up. For example, the MIDCOM agent authorization policy for a middlebox service may be preconfigured by specifying the agent along with a filter 🧚. In the case of a firewall, the ACL tuple may be altered to reflect the optional Agent presence, and the revised ACL may look something like this:
(<Session-Direction>, <Source-Address>, <Destination-Address>, <IP-Protocol>, <Source-Port>, <Destination-Port>, <Agent>)The reader should note that this is an illustrative example and not necessarily the actual definition of an ACL tuple 📝. The formal description of the ACL is yet to be devised 🚧. Agent accessibility information should also be provisioned. For a MIDCOM agent, accessibility information includes the IP address, trust level, host authentication parameters and message authentication parameters 🗂️. Once a session is established between a middlebox and a MIDCOM agent, that session should be usable with multiple instances of the application(s), as appropriate 🔁. Also, note that all of this could be captured in an agent profile for ease of management 💜.
The technique described above is necessary for the pre-registration of MIDCOM agents with the middlebox 🌷. The middlebox provisioning may remain unchanged if the middlebox learns of the registered agents through a MIDCOM PDP 🙌. Either way, the MIDCOM agent should initiate the session prior to the start of the application ⏰. If the agent session is delayed until after the application has started, the agent might be unable to process the control stream to permit the data sessions 😬. When a middlebox notices an incoming MIDCOM session, and the middlebox has no prior profile of the MIDCOM agent, the middlebox will consult its MIDCOM PDP for authenticity, authorization, and trust guidelines for the session 🔍.
7.0. MIDCOM Framework Illustration using an In-Path agent 🎬
In figure 3 below, we look at SIP applications (Refer [SIP]) to show how the MIDCOM protocol works 📞. The application assumes that a caller, external to a private domain, initiates the call 🌍. The middlebox is assumed to sit at the edge of the private domain 🚪. A SIP phone (SIP User Agent Client/Server) inside the private domain can receive calls from external SIP phones 📱. The caller uses a SIP Proxy, a node located external to the private domain, as its outbound proxy. No interior proxy is assumed for the callee. Lastly, the external SIP proxy node is designated to host the MIDCOM agent function 💅.
Arrows 1 and 8 in the figure below refer to a SIP call setup exchange between the external SIP phone and the SIP proxy 💫. Arrows 4 and 5 refer to a SIP call setup exchange between the SIP proxy and the interior SIP phone, and are assumed to be traversing the middlebox 🔀. Arrows 2, 3, 6 and 7 below, between the SIP proxy and the middlebox, refer to MIDCOM communication 🫶. Na and Nb represent RTP/RTCP media traffic (Refer [RTP]) path in the external network 🎶. Nc and Nd represent media traffic inside the private domain 🎧.
_________
--->| SIP |<-----\
/ | Proxy | \
| |_________| |
1| |^ ^| 4|
| || || |
|8 2||3 7||6 |5
______________ | || || | _____________
| |<-/ _v|____|v___ \->| |
| External | Na | | Nc | SIP Phone |
| SIP phone |>------->| Middlebox |>------>| within |
| |<-------<|___________|<------<| Pvt. domain|
|____________| Nb Nd |____________|
Figure 3: MIDCOM framework illustration with In-Path SIP ProxyAs for the SIP application, we assume the middlebox is pre-configured to accept SIP calls into the private SIP phone 🎀. Specifically, this would imply that the middlebox implementing firewall service is pre-configured to permit SIP calls (destination TCP or UDP port number set to 5060) into the private phone 🚦. Likewise, a middlebox implementing NAPT service would have been pre-configured to provide a port binding, to permit incoming SIP calls to be redirected to the specific private SIP phone 🔀. I.e., the INVITE from the external caller is not made to the private IP address, but to the NAPT external address 📬.
The objective of the MIDCOM agent in the following illustration is merely to permit the RTP/RTCP media stream (Refer [RTP]) through the middlebox, using the MIDCOM protocol architecture outlined in the document 🦋. A SIP session typically establishes two RTP/RTCP media streams: one from the callee to the caller and another from the caller to the callee 🎤. These media sessions are UDP based and use dynamic ports 🌊. The dynamic ports used for the media stream are specified in the SDP section (Refer [SDP]) of the SIP payload message 📄. The MIDCOM agent will parse the SDP section and use the MIDCOM protocol to (a) open pinholes (i.e., permit RTP/RTCP session tuples) in a middlebox implementing firewall service, or (b) create PORT bindings and appropriately modify the SDP content to permit the RTP/RTCP streams through a middlebox implementing NAT service 🪄. The MIDCOM protocol should be sufficiently rich and expressive to support the operations described under the timelines ⭐. The examples do not show the timers maintained by the agent to keep the middlebox policy rule(s) from timing out ⏳.
MIDCOM agent Registration and connectivity between the MIDCOM agent and the middlebox are not shown, so the focus of the MIDCOM transactions stays on enabling the middlebox to let the media stream through 🙈. The MIDCOM PDP is also not shown in the diagram below or on the timelines, for the same reason 🫧.
The following subsections illustrate a typical timeline sequence of operations that transpire with the various elements involved in a SIP telephony application path 🗓️. Each subsection is devoted to a specific instantiation of a middlebox service. NAPT (refer [NAT-TERM], [NAT-TRAD]), firewall, and a combination of both NAPT and firewall are considered 🔥.
7.1. Timeline flow - Middlebox implementing firewall service ✨
Okay so picture this 🎀 a middlebox doing firewall duty, and we're going to assume it's already pre-configured to let SIP calls through (destination TCP or UDP port number 5060) into the private phone. 🛡️ The timeline below shows the steps the MIDCOM agent takes to get the RTP/RTCP media stream through the middlebox. It's giving choreography, bestie 💅
The INVITE from the caller (external) is assumed to carry the SDP payload. Here's the key part 👑 the MIDCOM agent asks the middlebox to open the Private-to-external RTP/RTCP flows before the INVITE gets relayed to the callee. Why? In SIP, the calling party has to be ready to receive media the moment it sends an INVITE with a session description. If the called party (private phone) assumes that and sends "early media" before the 200 OK, the firewall would block those packets without this initial MIDCOM signaling from the agent. Not me pretending the firewall is fine with that 😭
SIP Phone SIP Proxy Middlebox SIP Phone
(External) (MIDCOM agent) (FIREWALL (private)
| | Service) |
| | | |
|----INVITE------>| | |
| | | |
|<---100Trying----| | |
| | | |
| Identify end-2-end | |
| parameters (from Caller's | |
| SDP) for the pri-to-Ext | |
| RTP & RTCP sessions. | |
| (RTP1, RTCP1) | |
| | | |
| |+Permit RTP1, RTCP1 +>| |
| |<+RTP1, RTCP1 OKed++++| |
| | | |
| |--------INVITE---------------------->|
| | | |
| |<-----180 Ringing--------------------|
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify end-2-end | |
| parameters (from callee's | |
| SDP) for the Ext-to-Pri | |
| RTP and RTCP sessions. | |
| (RTP2, RTCP2) | |
| | | |
| |+Permit RTP2, RTCP2 +>| |
| |<+RTP2, RTCP2 OKed++++| |
| | | |
|<---200 OK ------| | |
|-------ACK------>| | |
| |-----------ACK---------------------->|
| | | |
|<===================RTP/RTCP==========================>|
| | | |
|-------BYE------>| | |
| |--------------------------BYE------->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |++Cancel permits to | |
| | RTP1, RTCP1, RTP2, | |
| | and RTCP2 +++++++++>| |
| |<+RTP1, RTP2, RTCP1 & | |
| | RTCP2 cancelled ++++| |
| | | |
|<---200 OK-------| | |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic7.2. Timeline flow - Middlebox implementing NAPT service 🦋
okay so this example is giving NAPT realness 💅 we're assuming the middlebox is a NAPT box that's already set up to redirect SIP calls to one specific private SIP phone app. bestie, that means the INVITE from the outside caller doesn't go straight to the private IP. it goes to the NAPT external address instead 🎀 quick name check: Ea is the external phone's IP address, Ma is the NAPT middlebox's external address, and Pa is the internal SIP phone's private address. SIP calls to the private phone show up as TCP/UDP sessions with the destination address and port set to Ma and 5060, and the middlebox redirects those datagrams to the internal phone. then the timeline shows what the MIDCOM agent has to do to let the RTP/RTCP media stream through the middlebox 🌸
same as the last example (section 7.1), the INVITE from the external caller includes the SDP payload 📞 now the lowkey important part: the MIDCOM agent asks the middlebox to make NAT session descriptors for the private-to-external RTP/RTCP flows before the INVITE gets relayed to the private SIP phone. same reasons as section 7.1, babe 🧚 if the called party (the private phone) sends "early media" before the 200 OK, the NAPT middlebox would've blocked those packets without that initial MIDCOM signaling from the agent 🙈
next, once the proxy gets the 200 OK from the private phone, the agent asks the middlebox to allocate NAT session descriptors for the external-to-private RTP2 and RTCP2 flows. the ports assigned on Ma for RTP2 and RTCP2 have to be contiguous ✨ the RTCP stream doesn't happen with a non-contiguous port, so this is non-negotiable, it's literally giving no flexibility 💀 also, even though every media stream (RTP1, RTCP1, RTP2 and RTCP2) is independent, they're all tied to the single SIP control session while their NAT session descriptors are being created. main character energy for the SIP session 👑 finally, when the agent sends a terminate session bundle command for the SIP session, the middlebox is assumed to delete all the associated media stream sessions automagically 🪄
SIP Phone SIP Proxy Middlebox SIP Phone
(External) (MIDCOM agent) (NAPT (Private)
IP Addr:Ea | Service) IP addr:Pa
| | IP addr:Ma |
| | | |
|----INVITE------>| | |
| | | |
|<---100Trying----| | |
| | | |
| |++ Query Port-BIND | |
| | for (Ma, 5060) +++>| |
| |<+ Port-BIND reply | |
| | for (Ma, 5060) ++++| |
| | | |
| |++ Query NAT Session | |
| | Descriptor for | |
| | Ea-to-Pa SIP flow+>| |
| |<+ Ea-to-Pa SIP flow | |
| | Session Descriptor+| |
| | | |
| Determine the Internal | |
| IP address (Pa) | |
| of the callee. | |
| | | |
| Identify UDP port numbers | |
| on Ea (Eport1, Eport1+1) | |
| for pri-to-ext RTP & RTCP | |
| sessions (RTP1, RTCP1) | |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP1, RTCP1; Set | |
| | parent session to | |
| | SIP-ctrl session ++>| |
| |<+RTP1, RTCP1 session | |
| | descriptors created+| |
| | | |
| | |..redirected..|
| |--------INVITE--------|------------->|
| | | |
| |<-----180Ringing---------------------|
| | | |
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify UDP port numbers | |
| on Pa (Pport2, Pport2+1) | |
| for ext-to-pri RTP & RTCP | |
| sessions (RTP2, RTCP2) | |
| | | |
| |++Create consecutive | |
| | port BINDs on Ma | |
| | for (Pa, Pport2), | |
| | (Pa, Pport2+1) ++++>| |
| |<+Port BINDs created++| |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP2, RTCP2; Set | |
| | parent session to | |
| | SIP-ctrl session ++>| |
| |<+RTP2, RTCP2 session | |
| | descriptors created+| |
| | | |
| Modify the SDP | |
| parameters in "200 OK" | |
| with NAPT PORT-BIND | |
| for the RTP2 port on Ma. | |
| | | |
|<---200 OK ------| | |
| | | |
|-------ACK------>| | |
| | | |
| Modify IP addresses | |
| appropriately in the SIP | |
| header (e.g., To, from, | |
| Via, contact fields) | |
| | |..redirected..|
| |-----------ACK--------|------------->|
| | | |
| | | |
|<===================RTP/RTCP============|=============>|
| | | |
|-------BYE------>| | |
| | | |
| |----------------------|-----BYE----->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |+++Terminate the SIP | |
| | Session bundle +++>| |
| |<++SIP Session bundle | |
| | terminated ++++++++| |
| | | |
|<---200 OK-------| | |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic7.3. Timeline flow - Middlebox implementing NAPT and firewall ✨
okay so this one is the combo meal 🍟 a middlebox doing NAPT and firewall at the same time. We're assuming the NAPT function is set up to translate the IP and TCP headers of the initial SIP session into the private SIP phone, and the firewall is set up to let that initial SIP session through 💅
Here's the tea 🫖 the firewall rules are based on packet fields on the wire (like what you'd see on the external interface of the middlebox). To keep each service behaving properly, NAT-specific MIDCOM operations come before firewall-specific ones on the MIDCOM agent. You'll spot this when the agent handles the "200 OK" from the private SIP phone. First the agent asks the NAT service on the middlebox to set up port-BIND and session-descriptors for the media stream in both directions. After that, it works out the session parameters (the dynamic UDP ports) as seen from the external interface, and then asks the firewall service to permit those sessions through 🦋
SIP Phone SIP Proxy Middlebox SIP Phone
(External) (MIDCOM agent) (NAPT & (Private)
IP Addr:Ea | firewall IP addr:Pa
| | Services) |
| | IP addr:Ma |
| | | |
|----INVITE------>| | |
| | | |
|<---100Trying----| | |
| | | |
| |++ Query Port-BIND | |
| | for (Ma, 5060) +++>| |
| |<+ Port-BIND reply | |
| | for (Ma, 5060) ++++| |
| | | |
| |++ Query NAT Session | |
| | Descriptor for | |
| | Ea-to-Pa SIP flow+>| |
| |<+ Ea-to-Pa SIP flow | |
| | Session Descriptor+| |
| | | |
| Determine the Internal | |
| IP address (Pa) | |
| of the callee. | |
| | | |
| Identify UDP port numbers | |
| on Ea (Eport1, Eport1+1) | |
| for pri-to-ext RTP & RTCP | |
| sessions (RTP1, RTCP1) | |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP1, RTCP1; Set the| |
| | parent session to | |
| | point to SIP flow++>| |
| |<+RTP1, RTCP1 session | |
| | descriptors created+| |
| | | |
| |++Permit RTP1 & RTCP1 | |
| | sessions External to| |
| | middlebox, namely | |
| | Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | sessions ++++++++++>| |
| |<+Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | sessions OKed ++++++| |
| | | |
| | |..redirected..|
| |--------INVITE--------|------------->|
| | | |
| |<-----180Ringing---------------------|
| | | |
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify UDP port numbers | |
| on Pa (Pport2, Pport2+1) | |
| for ext-to-pri RTP & RTCP | |
| sessions (RTP2, RTCP2) | |
| | | |
| |++Create consecutive | |
| | port BINDs on Ma | |
| | for (Pa, Pport2), | |
| | (Pa, Pport2+1) ++++>| |
| |<+Port BINDs created | |
| | on Ma as (Mport2, | |
| | Mport2+1) ++++++++++| |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP2, RTCP2; Set the| |
| | parent session to | |
| | point to SIP flow++>| |
| |<+RTP2, RTCP2 session | |
| | descriptors created+| |
| | | |
| Modify the SDP | |
| parameters in "200 OK" | |
| with NAPT PORT-BIND | |
| for RTP2 port on Ma. | |
| | | |
| |++Permit RTP2 & RTCP2 | |
| | sessions External | |
| | middlebox, namely | |
| | Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2+1 | |
| | sessions ++++++++++>| |
| |<+Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2 | |
| | sessions OKed ++++++| |
| | | |
|<---200 OK ------| | |
| | | |
|-------ACK------>| | |
| | | |
| |-----------ACK--------|------------->|
| | | |
| | | |
|<===================RTP/RTCP============|=============>|
| | | |
|-------BYE------>| | |
| | | |
| |----------------------|-----BYE----->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |+++Terminate the SIP | |
| | Session bundle +++>| |
| |<++SIP Session bundle | |
| | terminated ++++++++| |
| | | |
| |++Cancel permits to | |
| | sessions External | |
| | middlebox, namely | |
| | Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2+1 | |
| | sessions ++++++++++>| |
| |<+Removed permits to | |
| | sessions listed ++++| |
| | | |
|<---200 OK-------| | |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic8.0. Operational considerations 🎀
8.1. Multiple MIDCOM sessions between agents and middlebox 🌸
okay real talk 💅 a middlebox can't be assumed to be a simple little device doing just one middlebox function with a couple of interfaces. Middleboxes love to stack multiple functions into one box 📦 and they can give each interface its own set of functions, with different provisioning for the same function across different interfaces. It's giving multitasker energy 🧚
So a MIDCOM agent ought to be able to have a single MIDCOM session with a middlebox, and use that one MIDCOM interface to talk to the different services on the same middlebox. One session, many services. Iconic 👑
8.2. Asynchronous notification to MIDCOM agents 🔔
Asynchronous notification from the middlebox to a MIDCOM agent can be super useful for things like Session creation, Session termination, MIDCOM protocol failure, middlebox function failure, or any other significant event 😭 On top of that, ICMP error codes can also be useful for telling the agents about transport layer failures, separately from the above.
Periodic notifications of various kinds of data, like statistics updates, would also be a useful feature, and it would be a real win for certain types of agents 📊✨
8.3. Timers on middlebox considered useful ⏰
So when the middlebox is supporting the MIDCOM protocol, it is required to allocate dynamic resources, as specified in policy rule(s), whenever agents ask for them 🫶 Those resources get explicitly released when the application session ends, or when a MIDCOM agent tells the middlebox to release them.
But here's the catch 🙈 the middlebox should still be able to recover dynamically allocated resources even when the agent that was responsible for the allocation is no longer alive. A good way to do that is to give these dynamic resources a lifetime and use a timer to keep track of it 💜
8.4. Middleboxes supporting multiple services 💅
A middlebox could be doing a bunch of jobs (like NAT and firewall) all in the same box 📦. Some of those services might depend on shared resources and need to run in a certain order 🔁. Others might be totally independent, living their best lives on their own 🦋. Generally speaking, the order these functions get applied to datagrams is not within the scope of this document 🙈.
For a middlebox doing NAT and firewall, it's safe to state that the NAT operation on an interface will precede a firewall on the egress and follow a firewall on the ingress ✨. Also, the firewall access control lists, which the firewall uses, are assumed to be based on session parameters, as seen on the interface supporting firewall service 🔥.
8.5. Signaling and Data traffic 📞
The applications MIDCOM is built for are all about having one or more signaling and data traffic sessions together 🎀. The signaling can go out-of-band, over a dedicated stand-alone session 🛤️. Or it can go in-band, right inside a data session 🫶. It's also possible to mix the two, with some signaling stand-alone and some in-band 🌈.
SIP is a classic example of an application with separate signaling and data sessions 📱. A SIP signaling session handles the call setup between a caller and a callee 📞. A MIDCOM agent may need to examine or modify the SIP payload content to administer the middlebox so the media streams (RTP/RTCP based) can get through 🎶. A MIDCOM agent is not required to step in on the data traffic itself 💜.
Signaling and context-specific header information gets sent in-band, within the same data stream, for stuff like HTTP embedded applications, sun-RPC (which embeds a variety of NFS apps), and Oracle transactions (embedding Oracle SQL+, MS ODBC, Peoplesoft) etc. 🗂️
H.323 is an example of an app that sends signaling both in dedicated stand-alone sessions and alongside data 👑. H.225.0 call signaling traverses middleboxes by virtue of static policy, so no MIDCOM control is needed there 🌸. H.225.0 call signaling also negotiates ports for an H.245 TCP stream 🔌. A MIDCOM agent is required to examine or modify the contents of the H.245 so that H.245 can traverse the middlebox 🚪.
H.245 traverses the middlebox and also carries Open Logical Channel information for media data 🎧. So the MIDCOM agent is once again required to examine or modify the payload content so the media traffic can flow 🌊.
The MIDCOM architecture takes into consideration support for applications with independent signaling and data sessions, as well as applications that have signaling and data communicated over the same session 🧚.
In cases where signaling is done on a single stand-alone session, it is desirable to have a MIDCOM agent interpret the signaling stream and program the middlebox (the one that transits the data stream) so the data traffic goes through uninterrupted 🍓. Main character energy for the data stream ✨
9. Applicability Statement 🗺️
Middleboxes can be stationed in a number of topologies 🧭. However, the signaling framework outlined in this document may be limited to only those middleboxes located in a DMZ (De-Militarized Zone) at the edge of a private domain, connecting to the Internet 🏰. Specifically, the assumption is that you have a single middlebox (running NAT or firewall) along the application route 🛣️. Discovering a middlebox along an application route is outside the scope of this document 🔍. It's conceivable to have middleboxes between departments within the same domain, or inside the service provider's domain, and so forth 🏢. However, you need to review each individual scenario and determine the applicability on a case-by-case basis 🧐.
The applicability can also be illustrated like this 🎨. Real-time and streaming apps, like Voice-Over-IP, and peer-to-peer apps, like Napster and Netmeeting, need firewalls and NAT middleboxes to be administered so their media streams can reach hosts inside a private domain 📡. The requirements take the form of establishing a "pin-hole" to permit a TCP/UDP session (whose port parameters are dynamically determined) through a firewall, or retaining an address/port bind in the NAT device to permit sessions to a port 🕳️. Current generation middleboxes meet these requirements using adhoc methods, like embedding application intelligence within a middlebox to identify the dynamic session parameters and administering the middlebox internally as appropriate 🛠️. The objective of the MIDCOM architecture is to create a unified, standard way to exercise this functionality, which currently exists in an ad-hoc fashion in some middleboxes 🤝.
By adopting the MIDCOM architecture, middleboxes will be able to support newer applications they haven't been able to support so far 🆕. MIDCOM architecture does not, and must not in anyway, change the fundamental characteristic of the services supported on the middlebox 🔒.
Organizations typically shield most of their corporate resources (such as end-hosts) from visibility to the external network by using a De-Militarized Zone (DMZ) at the domain edge 🛡️. Only a portion of these hosts are allowed to be accessed by the external world 🚪. The remaining hosts and their names are unique to the private domain 🤫. Hosts visible to the external world, and the authoritative name server that maps their names to network addresses, are often configured within a DMZ (De-Militarized Zone) in front of a firewall 🧱. Hosts and middleboxes within the DMZ are referred to as DMZ nodes 🏷️.
Figure 4 below illustrates the configuration of a private domain with a DMZ at its edge 🗺️. Actual configurations may vary 🎭. Internal hosts are accessed only by users inside the domain 🔐. Middleboxes located in the DMZ may be accessed by agents inside or outside the domain 🌐.
\ | /
+-----------------------+
|Service Provider Router|
+-----------------------+
WAN |
Stub A .........|\|....
|
+---------------+
| NAT middlebox |
+---------------+
|
| DMZ - Network
------------------------------------------------------------
| | | | |
+--+ +--+ +--+ +--+ +-----------+
|__| |__| |__| |__| | Firewall |
/____\ /____\ /____\ /____\ | middlebox |
DMZ-Host1 DMZ-Host2 ... DMZ-Name DMZ-Web +-----------+
Server Server etc. |
|
Internal Hosts (inside the private domain) |
------------------------------------------------------------
| | | |
+--+ +--+ +--+ +--+
|__| |__| |__| |__|
/____\ /____\ /____\ /____\
Int-Host1 Int-Host2 ..... Int-Hostn Int-Name ServerFigure 4: DMZ network configuration of a private domain. 🧜♀️
10. Acknowledgements 🫶
The authors want to thank Christian Huitema, Joon Maeng, Jon Peterson, Mike Fisk, Matt Holdrege, Melinda Shore, Paul Sijben, Philip Mart, Scott Brim and Richard Swale for their valuable critique, advice and input on an earlier rough version of this document 💖. The authors owe special thanks to Eliot Lear for kick-starting the e-mail discussion on use-case scenarios with a SIP application flow diagram through a middlebox 📧. Much thanks to Bob Penfield, Cedric Aoun, Christopher Martin, Eric Fleischman, George Michaelson, Wanqun Bao, and others in the MIDCOM work group for their very detailed feedback on a variety of topics and for adding clarity to the discussion 🌷. Last, but not least, the authors owe much thanks to Mark Duffy, Scott Brim, Melinda Shore and others for their help with terminology definition and for discussing the embedded requirements within the framework document 🎀.
11. Security Considerations 🔒
Okay bestie, security is where things get seriously dramatic 😭. Without MIDCOM protocol support, a middlebox basically needs the data to be in the clear, because it has to be able to inspect and/or modify packet headers and payload. That totally compromises confidentiality in some environments 💀. And when a NAT updates transport headers and rewrites application payload data, it can stop integrity protection from working on some data streams crossing NAT middleboxes. Honestly, that can be a huge threat to the app when the transport domain is untrusted 🚨.
The MIDCOM framework removes the need for a middlebox to inspect or manipulate transport payload ✨. That lets apps protect themselves end-to-end with help from a trusted MIDCOM agent, and it's especially true when the agent lives on the end host. When an agent has the same end-to-end ability as the end host to interpret encrypted and integrity protected data, traffic crossing a middlebox can stay encrypted and integrity protected. The MIDCOM agent can still interpret the data and just tell the middlebox about open holes, install NAT table entries, etc. 🦋 Note, though, that the MIDCOM framework does not help with the problem of NAT breaking IPsec, since in that case the middlebox still modifies IP and transport headers 🙈.
Security between a MIDCOM agent and a middlebox has a number of components: authorization, authentication, integrity and confidentiality. Let's go through them 💅.
Authorization is about whether a particular agent is authorized to signal a middlebox with requests for one or more applications, while following a certain policy profile. Failing the authorization process might mean a resource theft attempt, or it might just be failure due to administrative and/or credential deficiencies. Either way, the middlebox should take the proper measures to audit/log such attempts, and it should consult its designated MIDCOM PDP for the required action if it's configured with one. Alternatively, the middlebox may fall back to a default service deny policy when a MIDCOM agent fails to provide the required credentials. Section 6 discusses the middlebox to MIDCOM PDP interactions in view of policy decisions 📋.
Authentication is about confirming the identity of an originator for all datagrams received from that originator 🪪. Lacking strong credentials for authenticating MIDCOM messages between an agent and a middlebox can seriously jeopardize the fundamental service the middlebox provides 😱. If an agent isn't authenticated, an attacker could spoof the identity of a "legitimate" agent and open holes in the firewall. Another consequence would be that the attacker could manipulate the state on a middlebox, creating a denial-of-service attack by closing needed pinholes or filling up a NAT table. And if the middlebox isn't authenticated to the agent, an attacker could pose as a middlebox and respond to NAT requests in a way that diverts data to the attacker, which is a total nightmare 💀. Failing to submit the required/valid credentials once challenged may indicate a replay attack. In that case, the middlebox needs to take proper action, such as auditing, logging, or consulting its designated MIDCOM PDP to reflect that failure. If the middlebox doesn't protect against replay attacks, a specific pinhole may be reopened or closed by an attacker at will, which can bombard end hosts with unwarranted data or cause denial of service 🌧️.
Integrity is required to make sure a MIDCOM message hasn't been accidentally or maliciously altered or destroyed 🔐. If data integrity isn't enforced in an untrusted environment, an imposter could alter the messages sent by an agent and bring the middlebox to a halt, or cause a denial of service for the application the agent is trying to enable 🫠.
Confidentiality of MIDCOM messages makes sure the signaling data is accessible only to the authorized entities 🤫. When a middlebox agent is deployed in an untrusted environment, a lack of confidentiality allows an intruder to do traffic flow analysis and snoop on the middlebox. The intruder could then cannibalize a less secure MIDCOM session and destroy or compromise the middlebox resources they uncovered on other sessions. Needless to say, the least secure MIDCOM session becomes the achilles heel 👑, and that makes the middlebox vulnerable to security attacks.
Lastly, there can be a security vulnerability for applications traversing a middlebox when a resource on that middlebox is controlled by multiple external agents 🚦. A middlebox service may be disrupted by conflicting directives from multiple agents, each associated with a different middlebox function but applied to the same application session. Care must be taken in the protocol design so that agents for one function don't abruptly step over resources that impact a different function. Alternatively, the severity of these problems could be lessened when a single MIDCOM agent is responsible for supporting all the middlebox services for an application, thanks to the reduced complexity and synchronization effort in managing the middlebox resources 🧚.
References 📚
[SIP] Rosenberg, J., Shulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[H.323] ITU-T Recommendation H.323. "Packet-based Multimedia Communications Systems," 1998.
[RTP] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[RTSP] Schulzrinne, H., Rao, A. and R. Lanphier: "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[POL-TERM] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[REQMTS] Swale, R. P., Mart, P. A., Sijben, P., Brim, S. and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002.
Authors' Addresses 🏡
Pyda Srisuresh
Kuokoa Networks, Inc.
475 Potrero Ave.
Sunnyvale, CA 94085
EMail: srisuresh@yahoo.com
Jiri Kuthan
Fraunhofer Institute FOKUS
Kaiserin-Augusta-Allee 31
D-10589 Berlin, Germany
EMail: kuthan@fokus.fhg.de
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
U.S.A.
EMail: jdrosen@dynamicsoft.com
Andrew Molitor
Aravox technologies
4201 Lexington Avenue North, Suite 1105
Arden Hills, MN 55126
U.S.A.
voice: (651) 256-2700
EMail: amolitor@visi.com
Abdallah Rayhan
WINCORE Lab
Electrical and Computer Engineering
Ryerson University
350 Victoria Street
Toronto, ON M5B 2K3
EMail: rayhan@ee.ryerson.ca, ar_rayhan@yahoo.caFull Copyright Statement ©️
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
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 🎀
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc3303 2002-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms