RFC 3989
Middlebox Communications (MIDCOM) Protocol Semantics
RFC 3989: Middlebox Communications (MIDCOM) Protocol Semantics 🎀
Part 1 of 15 💖 okay bestie, this is the first chunk, so get comfy.
The title block first. This is RFC 3989, part of the Network Working Group series. It was written by M. Stiemerling and J. Quittek from NEC, and T. Taylor from Nortel. It's an Informational document, dated February 2005. The title block doesn't list anything it obsoletes or updates. It's all about defining MIDCOM protocol semantics 🦋
Status of This Memo 🌸
This memo gives information to the Internet community ✨ It does not specify an Internet standard of any kind, so it's not a spec you're forced to follow. Distribution of this memo is unlimited, so share it with everyone 💅
Copyright Notice 🌈
Copyright (C) The Internet Society (2005).
Abstract 💜
Okay so this memo lays out the semantics for a Middlebox Communication (MIDCOM) protocol 🔥 MIDCOM agents use it to talk to middleboxes, like firewalls and Network Address Translators (NATs). Important tea: the semantics discussion does not include any concrete syntax or transport protocol. Like, at all. 🙈
But a real protocol is expected to implement these semantics, or, more likely, a superset of them. The semantics come from the MIDCOM requirements, the MIDCOM framework, and working group decisions. It's giving well-researched ✨
Table of Contents 🧚
1. Introduction ................................................. 3
1.1. Terminology ............................................ 4
1.2. Transaction Definition Template ........................ 6
2. Semantics Specification ...................................... 7
2.1. General Protocol Design ................................ 7
2.1.1. Protocol Transactions .......................... 8
2.1.2. Message Types .................................. 9
2.1.3. Session, Policy Rule, and Policy Rule Group .... 9
2.1.4. Atomicity ...................................... 10
2.1.5. Access Control ................................. 11
2.1.6. Middlebox Capabilities ......................... 11
2.1.7. Agent and Middlebox Identifiers ................ 12
2.1.8. Conformance .................................... 12
2.2. Session Control Transactions ........................... 13
2.2.1. Session Establishment (SE) ..................... 13
2.2.2. Session Termination (ST) ....................... 15
2.2.3. Asynchronous Session Termination (AST) ......... 16
2.2.4. Session Termination by Interruption of
Connection ..................................... 17
2.2.5. Session State Machine .......................... 17
2.3. Policy Rule Transactions ............................... 18
2.3.1. Configuration Transactions ..................... 19
2.3.2. Establishing Policy Rules ...................... 19
2.3.3. Maintaining Policy Rules and Policy Rule Groups 20
2.3.4. Policy Events and Asynchronous Notifications ... 21
2.3.5. Address Tuples ................................. 21
2.3.6. Address Parameter Constraints .................. 23
2.3.7. Interface-specific Policy Rules ................ 25
2.3.8. Policy Reserve Rule (PRR) ...................... 26
2.3.9. Policy Enable Rule (PER) ....................... 30
2.3.10. Policy Rule Lifetime Change (RLC) .............. 36
2.3.11. Policy Rule List (PRL) ......................... 38
2.3.12. Policy Rule Status (PRS) ....................... 39
2.3.13. Asynchronous Policy Rule Event (ARE) ........... 41
2.3.14. Policy Rule State Machine ...................... 42
2.4. Policy Rule Group Transactions ......................... 43
2.4.1. Overview ....................................... 43
2.4.2. Group Lifetime Change (GLC) .................... 44
2.4.3. Group List (GL) ................................ 46
2.4.4. Group Status (GS) .............................. 47
3. Conformance Statements ....................................... 48
3.1. General Implementation Conformance ..................... 49
3.2. Middlebox Conformance .................................. 50
3.3. Agent Conformance ...................................... 50
4. Transaction Usage Examples ................................... 50
4.1. Exploring Policy Rules and Policy Rule Groups .......... 50
4.2. Enabling a SIP-Signaled Call ........................... 54
5. Compliance with MIDCOM Requirements .......................... 59
5.1. Protocol Machinery Requirements ........................ 59
5.1.1. Authorized Association ......................... 59
5.1.2. Agent Connects to Multiple Middleboxes ......... 60
5.1.3. Multiple Agents Connect to Same Middlebox ...... 60
5.1.4. Deterministic Behavior ......................... 60
5.1.5. Known and Stable State ......................... 60
5.1.6. Status Report .................................. 61
5.1.7. Unsolicited Messages (Asynchronous
Notifications).................................. 61
5.1.8. Mutual Authentication .......................... 61
5.1.9. Session Termination by Any Party ............... 62
5.1.10. Request Result ................................. 62
5.1.11. Version Interworking ........................... 62
5.1.12. Deterministic Handling of Overlapping Rules .... 62
5.2. Protocol Semantics Requirements ........................ 63
5.2.1. Extensible Syntax and Semantics ................ 63
5.2.2. Policy Rules for Different Types of Middleboxes 63
5.2.3. Ruleset Groups ................................. 63
5.2.4. Policy Rule Lifetime Extension ................. 63
5.2.5. Robust Failure Modes ........................... 63
5.2.6. Failure Reasons ................................ 63
5.2.7. Multiple Agents Manipulating Same Policy Rule .. 64
5.2.8. Carrying Filtering Rules ....................... 64
5.2.9. Parity of Port Numbers ......................... 64
5.2.10. Consecutive Range of Port Numbers .............. 64
5.2.11. Contradicting Overlapping Policy Rules ......... 64
5.3. Security Requirements .................................. 65
5.3.1. Authentication, Confidentiality, Integrity ..... 65
5.3.2. Optional Confidentiality of Control Messages ... 65
5.3.3. Operation across Untrusted Domains ............. 65
5.3.4. Mitigate Replay Attacks ........................ 65
6. Security Considerations ...................................... 65
7. IAB Considerations on UNSAF .................................. 66
8. Acknowledgments .............................................. 67
9. References ................................................... 67
9.1. Normative References ................................... 67
9.2. Informative References ................................. 67
Authors' Addresses ............................................... 69
Full Copyright Statement ......................................... 701. Introduction ✨
Okay, backstory time 📖 The MIDCOM working group already made a framework [MDC-FRM] and a list of requirements [MDC-REQ] for middlebox communication. The next step toward an actual MIDCOM protocol is specifying protocol semantics. Those semantics are constrained by those two documents, but not completely dictated by them 🧠
This memo suggests a semantics for the MIDCOM protocol. It is fully compliant with the requirements listed in [MDC-REQ], and it also matches the working group's consensus on semantic issues. Main character energy 👑
Following the working group charter, the semantics are aimed at packet filters and network address translators (NATs). They support applications that need dynamic configuration of these middleboxes 🍓
The semantics are defined using transactions. There are two basic types: request-reply transactions and asynchronous transactions. For each transaction, the spec describes four things:
- (1) the parameters of the transaction,
- (2) how request messages get processed at the middlebox,
- (3) the state transitions at the middlebox, caused by request transactions or indicated by asynchronous transactions respectively,
- (4) the reply and notification messages the middlebox sends to the agent to tell it about the state change.
The semantics can be implemented by any protocol that supports these two transaction types and is flexible enough about transaction parameters 🫶 Different implementations might need to extend the semantics by adding more transactions, adding more parameters to transactions, and/or splitting one transaction into a set of transactions. No matter what extensions show up, the semantics below give the minimum necessary subset of what must be implemented. Lowkey the most important bit 🔥
The rest of this document is laid out like this. Section 2 describes the protocol semantics, in four subsections:
- General Protocol Issues (section 2.1)
- Session Control (section 2.2)
- Policy Rules (section 2.3)
- Policy Rule Groups (section 2.4)
Section 3 has the conformance statements for MIDCOM protocol definitions and implementations, measured against the semantics in section 2. Section 4 gives two elaborated usage examples. Last but not least, section 5 explains how these semantics meet the MIDCOM requirements 💖
(Part 1 ends here. More parts are coming, so stay tuned, bestie!) 🦋
1.1. Terminology 📚
okay so the terms in this memo follow the definitions in the framework [MDC-FRM] and requirements [MDC-REQ] document, so those are the source of truth 🫶
Here's the extra vocab we need:
- request transaction 💌: it's a whole back-and-forth. The agent sends a request message to the middlebox, the middlebox processes it, and then it sends a reply message back to the agent. On top of that, it might also send notification messages to agents other than the one who asked, and that part is optional. A request transaction might cause a state transition at the middlebox.
- configuration transaction 🛠️: a request transaction that asks the middlebox to change its state. If it gets accepted, it causes a state change at the middlebox.
- monitoring transaction 👀: a request transaction that asks the middlebox for state information. It does not cause a state transition at the middlebox, so it's just peeking, no drama.
- asynchronous transaction ⚡: this one isn't triggered by an agent at all. It may happen without any agent taking part in a session with the middlebox. It can include notification messages going out to agents that are in an open session. Each agent that needs to hear about the asynchronous event gets its own notification message, and that message tells them about the state transition at the middlebox.
- agent-unique 🦋: a value that's unique in the context of the agent. That context covers all the MIDCOM sessions the agent is part of. The agent is the one who assigns it.
- middlebox-unique 🧚: a value that's unique in the context of the middlebox. That context covers all the MIDCOM sessions the middlebox is part of. The middlebox assigns this one.
- policy rule 🌸: the general idea comes from [RFC3198], which says a policy rule is "a basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions -- where the conditions are evaluated to determine whether the actions are performed." In MIDCOM land, the condition is a specification of a set of packets that the rules get applied to. Every rule has just one action in its set, and that action is either
"reserve"or"enable". ✨ - policy reserve rule 🎀: a policy rule with a reserve action. Its policy condition is always true. The action reserves just an IP address, or an IP address plus a range of port numbers. That reservation can sit on neither side, one side, or both sides of the middlebox, depending on how the middlebox is configured.
- policy enable rule 🔓: a policy rule with an enable action. Its condition is a descriptor of one or more unidirectional or bidirectional packet flows. The action lets packets in that flow go through the middlebox. The descriptor identifies the protocol, the flow direction, and the source and destination addresses, and it can optionally include a range of port numbers.
- NAT binding 🌈: heads up, this doesn't always mean a NAT bind as defined in [NAT-TERM]. In MIDCOM semantics, a NAT binding is an abstraction that lets two end points talk to each other through a NAT-type middlebox. An enable action might end up creating a NAT bind or a NAT session, and which one depends on the request and its parameters. 💅
1.2. Transaction Definition Template 🧩
okay so in the sections coming up, the MIDCOM protocol semantics get spelled out one transaction at a time. Every transaction spec has the entries below. Parameter entries, failure reason, and notification message type only show up when they actually apply.
transaction-name🏷️: a descriptive name for this type of transaction.transaction-type🗂️: this is either'configuration','monitoring', or'asynchronous'. Check section 1.1 for what each type means.transaction-compliance✅: this is either'mandatory'or'optional'. For the details, see section 2.1.8.request-parameters📥: every parameter that this request needs. Each one gets a description.reply-parameters (success)📤: every parameter the middlebox sends back to the agent as a positive response to the earlier request. Each one gets a description.failure reason💔: every negative reply has two parameters. The first is a request identifier, which says which request the reply belongs to. The second is a parameter that gives the failure reason. Those two are compulsory, so the template doesn't list them. What the template does list is a set of potential failure reasons that the second parameter might show. That list isn't exhaustive, and a concrete protocol spec is allowed to extend it. 🙃notification message type🔔: the type of notification message that this transaction may use.semantics🧠: the real meaning of the transaction. It describes how the middlebox processes the request message, plus the middlebox state transitions that the transaction causes or is caused by.
2. Semantics Specification 🎀
2.1. General Protocol Design 💖
okay so the big goal here is finding a balance. The protocol needs to properly support applications that want to dynamically configure middleboxes, but it also needs to stay simple to specify and simple to implement. 🫶
Protocol interactions are organised into transactions. A middlebox's state gets described by state machines, and those are made of states and state transitions. Here's the rule that matters: one transaction can cause state transitions in more than one state machine, or be caused by them. But for any single state machine, a transaction gets at most one transition. 🦋
2.1.1. Protocol Transactions 🔁
okay so state transitions start in one of two ways. Either a request message comes in from the agent to the middlebox, or some other event happens at the middlebox. If it's the first one, the middlebox tells the agent about the state transition by sending a reply message. If it's the second one, the middlebox sends an unsolicited asynchronous notification message to each agent affected by the transaction. That only happens if the agent is in an open session with the middlebox. 💌
Request and reply messages both carry an agent-unique request identifier. That's how the agent knows which sent request a received reply belongs to. 🪪
The requirements analysis showed that four kinds of transactions are needed:
- Configuration transactions 🛠️: they let the agent ask the middlebox for state transitions.
- Asynchronous transactions ⚡: they let the middlebox change state without an agent asking for it.
- Monitoring transactions 👀: they let the agent ask the middlebox for state information.
- Convenience transactions 🎁: they bundle a set of configuration transactions together.
Configuration transactions and asynchronous transactions are the core of MIDCOM. They're tied to middlebox state transitions, and they cover setting up and tearing down MIDCOM sessions and policy rules. 🔥
Monitoring transactions don't touch middlebox state transitions at all. Agents use them to look at how many policy rules exist at the middlebox, what state those rules are in, and what properties they have. 🔍
Convenience transactions make MIDCOM sessions simpler because they squash a bunch of configuration transactions into one. They aren't needed for MIDCOM to work at all. 💅
As section 3 spells out in detail, configuration transactions and asynchronous transactions are mandatory. A compliant middlebox must implement them. All the convenience transactions are optional, and some of the monitoring transactions are optional too. 🌈
2.1.2. Message Types 📨
Okay bestie, MIDCOM has three kinds of messages: request messages, reply messages, and notification messages. Each kind comes in different message types 💅. In this semantics doc, a message type is defined only by its list of parameters. The order of the parameters and how they're encoded is left up to a concrete protocol definition 🧩. A protocol definition can also add more parameters to a message type, or squish several parameters into one, as long as all the info from the semantics is still there 🎀.
For request messages and positive reply messages, there's one message type per request transaction 🦋. Each reply transaction uses the transaction definition template from section 1.2 to define the parameter list of the request message and of the positive (successful) reply message.
If a request transaction fails, the middlebox sends a negative reply message to the agent 😭. It's the same for every request transaction. It carries the request identifier (so the agent knows which request the reply belongs to) and a parameter saying why it failed.
There are three notification message types 🔔: the Session Termination Notification (STN), the Policy Rule Event Notification (REN), and the Group Event Notification (GEN). All of them carry a middlebox-unique notification identifier.
- STN: the Session Termination Notification also contains a single parameter indicating the reason for session termination by the middlebox 🚪
- REN: the Policy Rule Event Notification contains the notification identifier, a policy rule identifier, and the remaining policy lifetime ⏳
- GEN: the Group Event Notification contains the notification identifier, a policy rule group identifier, and the remaining policy rule group lifetime 🧁
2.1.3. Session, Policy Rule, and Policy Rule Group 🗂️
All transactions can be sorted into ones about sessions, ones about policy rules, and ones about policy rule groups. Groups are how you show relationships between policy rules, and they make life easier because you can do one transaction per group instead of one per rule 🙌.
Sessions and policy rules are stateful at the middlebox 🧠. Their states are independent of each other, so their state machines (one per session and one per policy rule) can be separated. Policy rule groups are stateful too, but the middlebox doesn't have to keep state for them. That's because the semantics were chosen so the group state is implicitly defined by the state of all the rules belonging to the group (see section 2.4) 💜.
Splitting session state from policy rule state makes the semantics spec simpler and makes implementation simpler, so the spec is structured that way and we use two separate state machines to illustrate things 🦋. Heads up though: state machines in real protocol designs and implementations will probably be more complex than these 👀. Still, the protocol state machines are expected to be a superset of the semantics state machines in this document 💅.
2.1.4. Atomicity ⚛️
All request transactions are atomic with respect to each other 🔒. Processing a request at the middlebox is never interrupted by another request arriving or already queued. This especially applies when the middlebox gets requests from different sessions at the same time. However, asynchronous transactions can interrupt and/or terminate processing of a request at any time 💀.
From the agent's point of view, all request transactions are atomic too ✨. Processing doesn't start until the complete request has arrived at the middlebox. No intermediate state is stable at the middlebox, and no intermediate state gets reported to any agent 🙈.
Only a small number of transactions are specified here 🌸. For simplicity, the set was trimmed down to a minimal one that still meets the requirements. A real implementation might need to split some of these transactions into two or more transactions of the protocol, maybe because of constraints of the particular protocol or to get more flexibility. In general that's no big deal, but
keep in mind that splitting a transaction might change the atomicity of the affected transactions ⚠️
2.1.5. Access Control 🔐
Ownership decides who gets access to policy rules and policy rule groups 👑. When a policy rule is created, a middlebox-unique identifier is generated so it can be referenced in later transactions. Beyond that identifier, every policy rule has an owner: the authenticated agent that established the rule. The middlebox uses the owner attribute to control access. Each time an authenticated agent asks to modify an existing policy rule, the middlebox looks up the owner and checks whether the requesting agent is authorized to perform transactions on the owning agent's policy rules.
All policy rules in the same policy rule group must have the same owner 🫶. So authenticated agents have access either to all members of a policy rule group, or to none of them.
The middlebox may be configured to let specific authenticated agents access and modify policy rules with certain specific owners. Obviously a reasonable default would let each agent access its own policy rules 🎀. It might also be good to configure an agent identity to act as administrator, allowing modification of all policy rules owned by any agent 👩💼. But how authorization is configured at the middlebox is out of scope for the MIDCOM semantics and protocol 🙅♀️.
2.1.6. Middlebox Capabilities 📋
Agents really want to know what the middlebox can do 🧚. So at session establishment, the session establishment procedure described in section 2.2.1 includes a transfer of capability information from the middlebox to the agent. The list of covered middlebox capabilities includes the following:
- Support of firewall function
- List of supported NAT functions, perhaps including
- address translation
- port translation
- protocol translation
- twice-NAT
- Internal IP address wildcard support
- External IP address wildcard support
- Port wildcard support
- Supported IP version(s) for internal network: IPv4, IPv6, or both
- Supported IP version(s) for external network: IPv4, IPv6, or both
- List of supported optional MIDCOM protocol transactions
- Optional interface-specific policy rule support: not supported or supported
- Policy rule persistence: persistent or non-persistent (a rule is persistent when the middlebox can save the rule to a non-volatile memory, e.g., a hard disk or flash memory)
- Maximum remaining lifetime of a policy rule or policy rule group
- Idle-timeout of policy rules in the middlebox (reserved and enabled policy rules not used by any data traffic for the time of this idle-timeout are deleted automatically by the middlebox; for the deletion of policy rules by middleboxes, see section 2.3.13 about Asynchronous Policy Rule Event) ⏰
- Maximum number of simultaneous MIDCOM sessions
The list of middlebox capabilities may be extended by a concrete protocol specification with further information useful for the agent 🌈.
2.1.7. Agent and Middlebox Identifiers 🪪
To let both agents and middleboxes keep multiple sessions going 💫, each request message contains a parameter identifying the requesting agent. Each reply message and each notification message contains a parameter identifying the middlebox. These parameters aren't explicitly listed in the description of each transaction, because they're common to all of them, and they aren't referenced further in the individual semantics descriptions. Even though they aren't necessarily passed explicitly as parameters of the MIDCOM protocol, they might be provided by the underlying (secure) transport protocol being used 🚚. Agent identifiers at the middlebox are middlebox-unique, and middlebox identifiers at the agent are agent-unique, respectively.
2.1.8. Conformance ✅
The MIDCOM requirements in [MDC-REQ] demand capabilities of the MIDCOM protocol, and the set of transactions specified below meets them 📜. However, an actual middlebox implementation may support only a subset of these transactions 🤷. The set of announced supported transactions may be different for different authenticated agents. The middlebox tells each authenticated agent, during the capability exchange at session establishment, which transactions that agent is authorized to perform. Some transactions need to be offered to every authenticated agent.
Each transaction definition below has a conformance entry that contains either 'mandatory' or 'optional' 🏷️. A mandatory transaction needs to be implemented by every middlebox offering MIDCOM service and must be must be offered to each of the authenticated agents. An optional transaction doesn't necessarily need to be implemented by a middlebox; it may offer these optional transactions only to certain authenticated agents. The middlebox may offer one, several, all, or no optional transactions to the agents. Whether an agent is allowed to use an optional request transaction is determined by the middlebox's authorization procedure, which is not further specified by this document 🙃.
2.2. Session Control Transactions 🎟️
Before any transaction on policy rules or policy rule groups is possible, a valid MIDCOM session must be established 🤝. A MIDCOM session is an authenticated and authorized association between agent and middlebox. Sessions are initiated by agents and can be terminated by either the agent or the middlebox. Both agent and middlebox may participate in several sessions (with different entities) at the same time 💞. To tell different sessions apart, each party uses local session identifiers.
All transactions are transmitted within this MIDCOM session 📬.
Session control is supported by three transactions:
- Session Establishment (SE)
- Session Termination (ST)
- Asynchronous Session Termination (AST)
The first two are configuration transactions initiated by the agent, and the last one is an asynchronous transaction initiated by the middlebox 💖.
2.2.1. Session Establishment (SE) ✨
transaction-name: session establishment
transaction-type: configuration
transaction-compliance: mandatoryOkay so SE is how an agent opens a MIDCOM session 🦋. It's mandatory, no cap, and here's what goes in the request and reply:
- Request parameters:
request identifier: an agent-unique ID so the agent can match each request to its reply 🎀version: the version of the MIDCOM protocol 🌸middlebox authentication challenge (mc): a challenge token for authenticating the middlebox. It only shows up in the first iteration of the request 🙈agent authentication (aa): a token that proves the agent's identity to the middlebox. It gets updated in the second iteration of the request, carrying the answer to the middlebox's challenge 💜
- Reply parameters (success):
request identifier: matches the ID from the request 🧚middlebox authentication (ma): a token that proves the middlebox's identity to the agent 🔥agent challenge token (ac): a challenge token for the agent's authentication 💅middlebox capabilities: a list of what the middlebox can do. The full list is in section 2.1.6 🌈
- Failure reasons:
authentication failedno authorizationprotocol version of agent and middlebox do not matchlack of resources
Semantics time, bestie 👑. This transaction sets up a MIDCOM session. For both sides to authenticate each other, you need two SE transactions back to back, as Figure 1 shows:
agent middlebox
| session establishment request |
| (with middlebox challenge mc) | CLOSED
|-------------------------------------------->|
| |
| successful reply (with middlebox |
| authentication ma and agent challenge ac) |
|<--------------------------------------------|
| | NOAUTH
| session establishment request |
| (with agent authentication aa) |
|-------------------------------------------->|
| |
| successful reply |
|<--------------------------------------------|
| | OPEN
| |
Figure 1: Mutual authentication of agent and middleboxMutual auth is giving full commitment 🫶. You can also simplify it down to a single transaction ✨. In that case the server challenge and agent challenge get left out by the sender or ignored by the receiver, so authentication has to come from somewhere else, like TLS [RFC2246] or IPsec [RFC2402][RFC2406]. Think of it as the bodyguard being outsourced 💖.
The middlebox checks with its policy decision point to see if the requesting agent is allowed to open a MIDCOM session 👀. If not, it sends back a negative reply with no authorization as the failure reason 💀. If authentication and authorization both work out, the session is established 🎉, and the agent can start asking for transactions on policy rules and policy rule groups.
Also, the successful reply always includes the middlebox's capabilities 🍓.
2.2.2. Session Termination (ST) 🌙
transaction-name: session termination
transaction-type: configuration
transaction-compliance: mandatoryST is how the agent closes the MIDCOM session. It's also mandatory 🎀.
- Request parameters:
request identifier: an agent-unique ID for matching the request to its reply 🌸
- Reply parameters (success only):
request identifier: matches the ID from the request 💜
Semantics: after the session ends, the middlebox keeps all the policy rules it set up, until their lifetime runs out or something happens that makes the middlebox end them 🦋. Once the middlebox sends its successful reply, it stops sending the agent any more messages in this session 🤐. It also won't process any requests in this session that it got while handling the termination request, or any requests that show up later 🙅♀️.
The middlebox always sends a successful reply, so this one's never going to fail 😤.
2.2.3. Asynchronous Session Termination (AST) ⭐
transaction-name: asynchronous session termination
transaction-type: asynchronous
transaction-compliance: mandatory
notification message type: Session Termination Notification (STN)AST is the middlebox ending the session on its own, and it's mandatory too 👑.
- Reply parameters (success only):
termination reason: why the session got terminated 🔥
Semantics: the middlebox can end a MIDCOM session whenever it wants ⚡. Before it actually ends the session, it sends the agent a Session Termination Notification (STN) message 📩. After sending that notification, the middlebox won't process any more requests from the agent, even if they're already sitting in its queue 💀.
Same as with ST, the policy rules stay put after the session ends, until their lifetime is up or an event comes along that makes the middlebox end them 🌈.
Unlike other asynchronous transactions, only one notification gets sent here, because there's only one agent involved 🧚.
2.2.4. Session Termination by Interruption of Connection 🔌
If a MIDCOM session is running on top of a network connection, the session can also end when that connection gets interrupted 💔. When the middlebox notices this, it ends the session right away ⚡. What happens to the established policy rules is the same as with Asynchronous Session Termination.
2.2.5. Session State Machine 🗺️
Figure 2 shows a state machine for the session transactions 🦋. The transaction abbreviations are explained in the headings of each transaction section.
Every session starts in state CLOSED 🌸. If mutual authentication is already handled by something else, a successful SE transaction can move the session to state OPEN ✨. Otherwise, it moves to state NOAUTH 🫶. From NOAUTH, a failed second SE transaction sends the session back to CLOSED 💔. A successful SE transaction moves it to OPEN 🎉. At any time, an AST transaction or a connection failure can happen, and that sends the session back to CLOSED 🥀. A successful ST transaction from either NOAUTH or OPEN also takes the session back to CLOSED 🔁. The transaction parameters are explained in Figure 2, and mc=0 stands for an empty middlebox challenge 🤍.
mc = middlebox challenge
SE/failure ma = middlebox authentication
+-------+ ac = agent challenge
| v aa = agent authentication
+----------+
| CLOSED |----------------+
+----------+ | SE(mc!=0)/
| ^ ^ | success(ma,ac)
SE(mc=0, | | | AST |
aa=OK)/ | | | SE/failure v
success | | | ST/success +----------+
| | +------------| NOAUTH |
| | +----------+
| | AST | SE(mc=0,
v | ST/success | aa=OK)/
+----------+ | success
| OPEN |<---------------+
+----------+
Figure 2: Session State Machine2.3. Policy Rule Transactions 🎀
This section covers the semantics of transactions on policy rules 💅. These are the transactions specified here:
- Policy Reserve Rule (PRR)
- Policy Enable Rule (PER)
- Policy Rule Lifetime Change (RLC)
- Policy Rule List (PRL)
- Policy Rule Status (PRS)
- Asynchronous Policy Rule Event (ARE)
The first three (PRR, PER, RLC) are configuration transactions that the agent starts 🌸. The fourth and fifth (PRL, PRS) are monitoring transactions 👀. The last one (ARE) is asynchronous 🔔. PRL and PRS and transactions don't affect the policy rule state machine at all 🙃.
Before any of these transactions can start, a valid MIDCOM session has to be established first 🔑.
2.3.1. Configuration Transactions ⚙️
Policy Rule transactions PER and RLC are the heart of the MIDCOM protocol 💖. Both are mandatory, and they handle:
- configuring NAT bindings (PER) 🌐
- configuring firewall pinholes (PER) 🕳️
- extending the lifetime of established policy rules (RLC) ⏰
- deleting policy rules (RLC) 🗑️
Sometimes the agent needs to know ahead of time which IP address (and port number) NAT is going to pick in a PER transaction 🔮. That info is needed before there's enough data to do a complete PER transaction (see the example in section 4.2). To cover those cases, the core transactions get an extra one, the Policy Reserve Rule (PRR) transaction, which handles:
- reserving addresses and port numbers at NATs (PRR) 🧚
2.3.2. Establishing Policy Rules 🏗️
PRR and PER both establish a policy rule 🎉. The action in the rule is 'reserve' if PRR sets it, and 'enable' if PER sets it 💜.
The Policy Reserve Rule (PRR) transaction sets up an address reservation on neither side, one side, or both sides of the middlebox, depending on how the middlebox is configured 🦋. The transaction gives the reserved IP addresses and the optional port number ranges back to the agent 🎁. No address binding or pinhole gets configured at the middlebox, and packet processing stays exactly the same 🫶.
On pure firewalls, PRR still gets processed successfully without reserving anything 🧱. But the MIDCOM protocol engine goes through exactly the same state transition as it does on NATs 🔁.
On a traditional NAT (see [NAT-TRAD]), only an external address gets reserved. On a twice-NAT, an internal address and an external address both get reserved 🌗. The reservation at a NAT covers required resources, like IP addresses and port numbers, that are held for later use 🗝️. How the reservation actually happens depends on how the NAT is implemented 🛠️. Either way, the reservation is either just an IP address, or an IP address combined with a range of port numbers 🌈.
The Policy Enable Rule (PER) transaction establishes a policy rule that affects packet processing at the middlebox 🚦. Depending on its input parameters, it can use a reservation made by a PRR transaction, or it can create a brand-new rule from scratch ✨.
On a NAT, the enable action works as a bind action, setting up bindings between internal and external addresses 🌉. At a firewall, the enable action works as one or more allow actions that configure pinholes 🪟. How many allow actions there are depends on the request parameters and how the firewall is implemented 🔢.
On a combined NAT/firewall, the enable action is a mix of bind and allow actions 💫.
The PRR and PER transactions are described in more detail in sections 2.3.8 and 2.3.9 below 📖.
2.3.3. Maintaining Policy Rules and Policy Rule Groups
okay bestie, let's talk about keeping policy rules alive (or letting them go 💀). Every policy rule gets its own middlebox-unique identifier ✨, so no two rules on the same middlebox share one.
Every policy rule also has an owner 👑. Access control to the rule is based on ownership (see section 2.1.5), and the owner never changes for the rule's whole lifetime. No swapping owners mid-rule, periodt 💅
Each rule has its own individual lifetime ⏳. When that lifetime runs out, the middlebox terminates the rule. Usually the middlebox tells you about the termination with an ARE transaction. A policy rule lifetime change (RLC) transaction can extend the lifetime, but only up to the limit the middlebox set at session setup. An RLC can also shorten the lifetime, or delete the rule outright by asking for a lifetime of zero. (Heads up: the group lifetime change (GLC) transaction can change policy rule lifetimes too 👀)
Each rule is a member of exactly one policy rule group 🎀. Group membership stays locked in for the rule's entire lifetime. Picking the group is part of the transaction that establishes the rule. If the agent doesn't name a group, that same transaction makes a brand new one, and the middlebox chooses its identifier. If the agent does name one, the new rule just joins that existing group. A group only exists while it still has member rules. Once every policy in it has reached the end of its lifetime, the group is gone 🫥 (ghost era, no cap).
Agents can check out the properties and status of every policy rule they're allowed to access by using the Policy Rule Status (PRS) transaction 🔍.
2.3.4. Policy Events and Asynchronous Notifications
If a policy rule changes its state, or its remaining lifetime changes in some way other than just counting down with time, every agent that can access that rule and has an open session with the middlebox gets notified 📣. If an explicit request caused the change, the requesting agent gets the matching reply back. Everyone else who can access the policy gets a Policy Rule Event Notification (REN) message.
Note that a middlebox can serve multiple agents at the same time in different parallel sessions. Between these agents, the sets of policy rules they can access may overlap. For example, there might be an agent that authenticates as administrator and can access all policies of all agents 👑. Or there could be a backup agent running a session in parallel to a main agent, authenticating itself as the same entity as the main agent 🫂.
For a PER, PRR, or RLC transaction, the requesting agent receives a PER, PRR, or RLC reply, respectively. Every other agent that can access the created, modified, or terminated policy rule (and that participates in an open session with the middlebox) gets an REN message carrying the policy rule identifier (PID) and the remaining lifetime of the rule.
If a rule gets terminated by lifetime truncation or by some other event not triggered by an agent, the middlebox sends an REN message to each agent that can access that particular rule and participates in an open session with the middlebox. This way, an agent always knows the most recent state of every policy rule it can access. Always in the loop ✨
2.3.5. Address Tuples
Request and reply messages of the PRR, PER, and PRS transactions contain address specifications for IP and transport addresses. These parameters include:
- IP version
- IP address
- IP address prefix length
- transport protocol
- port number
- port parity
- port range
Additionally, the request message of PER and the reply message of PRS contain a direction of flow parameter. This parameter indicates, for UDP and IP, the direction of packets traversing the middlebox. For 'inbound', the UDP packets are traversing from outside to inside. For 'outbound', they traverse from inside to the outside. In both cases, the packets can traverse the middelbox only uni-directionally. A bi-directional flow is enabled through 'bi-directional' as the direction of flow parameter. For TCP, the packet flow is always bi-directional, but the direction of the flow parameter is defined as:
- inbound: bi-directional TCP packet flow. The first packet, with TCP SYN flag set and ACK flag not set, must arrive at the middlebox at the outside interface.
- outbound: bi-directional TCP packet flow. The first packet, with TCP SYN flag set and ACK flag not set, must arrive at the middlebox at the inside interface.
- bi-directional: bi-directional TCP packet flow. The first packet, with TCP SYN flag set and ACK flag not set, may arrive at the inside or outside interface.
We refer to the set of these parameters as an address tuple 🧩. An address tuple specifies either a communication endpoint at an internal or external device, or allocated addresses at the middlebox. In this document, we distinguish four kinds of address tuples, as shown in Figure 3.
+----------+ +----------+
| internal | A0 A1 +-----------+ A2 A3 | external |
| endpoint +----------+ middlebox +----------+ endpoint |
+----------+ +-----------+ +----------+
Figure 3: Address tuples A0 - A3- A0 -- internal endpoint: Address tuple A0 specifies a communication endpoint of a device within (with respect to the middlebox) the internal network.
- A1 -- middlebox inside address: Address tuple A1 specifies a virtual communication endpoint at the middlebox within the internal network. A1 is the destination address for packets passing from the internal endpoint to the middlebox, and is the source for packets passing from the middlebox to the internal endpoint.
- A2 -- middlebox outside address: Address tuple A2 specifies a virtual communication endpoint at the middlebox within the external network. A2 is the destination address for packets passing from the external endpoint to the middlebox, and is the source for packets passing from the middlebox to the external endpoint.
- A3 -- external endpoint: Address tuple A3 specifies a communication endpoint of a device within (with respect to the middlebox) the external network.
For a firewall, the inside and outside endpoints are identical to the corresponding external or internal endpoints, respectively. In this case, the installed policy rule sets the same value in A2 as in A0 (A0=A2), and sets the same value in A1 as in A3 (A1=A3) 🧱.
For a traditional NAT, A2 is given a value different from that of A0, but the NAT binds them. As for the firewall, it is also as it is at a traditional NAT: A1 has the same value as A3 🔁.
For a twice-NAT, there are two bindings of address tuples: A1 and A2 are both assigned values by the NAT. The middlebox outside address A2 is bound to the internal endpoint A0, and the middlebox inside address A1 is bound to the external endpoint A3. Two bindings, double the glow-up ✨🦋
2.3.6. Address Parameter Constraints ✨
okay so bestie, some constraints apply to the transaction parameters inside an address tuple, and they're the same no matter which message is using them 💅 so instead of repeating them in every single transaction description (bo-ring 🥱), they're all summarized right here 🧚
the MIDCOM semantics in this doc cover IPv4 and IPv6 as the network protocols, and TCP and UDP (running over IPv4 or IPv6) as the transport protocols 🦋 handling any other transport protocol, like SCTP, isn't defined by these semantics, but a concrete protocol spec might support it 🌸
the IP version parameter is either 'IPv4' or 'IPv6' 💖 in a policy rule, the IP version parameter must be the same for address tuples A0 and A1, and also for A2 and A3 🫶
the IP address parameter has to match the IP version you picked 🎀
an IP address in an address tuple may be wildcarded 🌈 whether wildcarding is allowed, and how much of it is allowed, depends on the local policy of the middlebox 👑 (see also section 6, "Security Considerations", because it's serious 😭) wildcarding gets set with the IP address prefix length parameter 🍓 like usual prefix length stuff, this parameter says how many of the high-significance bits of the IP address are fixed, and the remaining low-significance bits are wildcarded ✨
the transport protocol parameter can be 'TCP', 'UDP', or 'ANY' 💜 if it's 'ANY', only the IP headers get considered for packet handling in the middlebox, meaning the transport header is not looked at 🙈 the port number, port range, and port parity parameters don't matter at all when the protocol is 'ANY' 💀 and in a policy rule, the transport protocol parameter must be the same for all address tuples A0, A1, A2, and A3 🔥
the port number parameter is either zero or a positive integer 🦋 a positive integer is a concrete UDP or TCP port number, and zero means port wildcarding for whatever protocol the transport protocol parameter names 🌸 if the port number is zero, the port range parameter doesn't matter 🫠 and depending on the transport protocol, this parameter might literally be ports or something equivalent to ports 🧚
the port parity parameter is used differently for policy reserve rules (PRR) and policy enable rules (PER) 🎀
for a PRR, the value can be 'odd', 'even', or 'any' 💅 it says the parity of the first (lowest) reserved port number 💖
for a PER, the port parity parameter tells the middlebox whether the port numbers it allocates should have the same parity as the corresponding internal or external port numbers, respectively 🦋 here the value is either 'same' or 'any' 🌈 if it's 'same', then the parity of the port number of A0 must be the same as the parity of the port number of A2, and the parity of the port number of A1 must be the same as the parity of the port number of A3 🫶 if it's 'any', there are no constraints on the parity of any port number 🎀
the port range parameter says how many consecutive port numbers you get 🍓 its value is a positive integer 💜 like the port number parameter, it defines a set of consecutive ports, starting at the port number as the lowest one and having as many members as the port range says ✨ a value of 1 means just one port number 🌸 the port range parameter must have the same value for each address tuple A0, A1, A2, and A3 👑
a single policy rule P with a port range bigger than one is basically the same as a bunch of policy rules, P_1, P_2, ..., P_n, where n equals the port range value 🤯 every one of those rules has a port range of 1 🌈 policy rule P_1 has address tuples A0_1, A1_1, A2_1, and A3_1, and each one holds the first port number from the matching address tuple in P 🦋 policy rule P_2 has A0_2, A1_2, A2_2, and A3_2, each with the second port number from the matching tuple in P, and so on and so forth 💅
2.3.7. Interface-specific Policy Rules 🦋
usually agents request policy rules knowing only A0 and A3, which are the address tuples (see section 2.3.5) 💖 but in very special cases, agents might need to pick which interfaces the requested policy rule gets bound to 🧚 usually the middlebox is careful about choosing the right interfaces when it reserves or enables a policy rule, since it has the overall picture of its own configuration 👑 but for agents that want to pick the interfaces, there are optional parameters in the Policy Reserve Rule (PRR) and Policy Enable Rule (PER) transactions 🎀 they're called
- inside interface: the selected interface on the inside of the middlebox, i.e., in the private or protected address realm 🏠
- outside interface: the selected interface on the outside of the middlebox, i.e., in the public address realm 🌍
the Policy Rule Status (PRS) transactions include these optional parameters in their replies, when they're supported 💜
agents can find out at session startup whether the middlebox supports interface-specific policy rules by checking the middlebox capabilities (see section 2.1.6) ✨🫶
2.3.8. Policy Reserve Rule (PRR) 🎀
transaction-name: policy reserve rule
transaction-type: configuration
transaction-compliance: mandatoryOkay bestie, the PRR is the "hold my spot" transaction 🦋 It's how an agent reserves addresses and ports at the middlebox before it has every detail it needs to fully enable a flow.
Here's what you send in the request 💌
request identifier: an agent-unique ID so the agent can match the request to its reply.group identifier: the group this PRR should join. As covered in section 2.3.3, if you leave it out, the middlebox makes a brand-new group for it 👑service: the NAT service you want from the middlebox. The only allowed values are'traditional'or'twice'.internal IP version: the IP version you want on the inside of the middlebox. See section 2.3.5.internal IP address: the IP address of the inside communication endpoint (A0 in Figure 3). See section 2.3.5.internal port number: the port number of that same inside endpoint (A0 in Figure 3). See section 2.3.5.inside interface(optional): the interface on the inside of the middlebox. See section 2.3.7.external IP version: the IP version you want on the outside of the middlebox. See section 2.3.5.outside interface(optional): the interface on the outside of the middlebox. See Section 2.3.7.transport protocol: see section 2.3.5.port range: how many consecutive port numbers to reserve. See section 2.3.5.port parity: the parity you want for the first (lowest) port number being reserved. The allowed values are'odd','even', and'any'. See also section 2.3.5.policy rule lifetime: your lifetime proposal for the requested policy rule.
When it works out, the reply comes back with these goodies ✨
request identifier: matches the one you sent.policy rule identifier: a middlebox-unique ID for this policy rule. The middlebox assigns it, and you use it as the policy rule handle in later policy rule transactions. You'll especially need it to point at the PRR in a later PER transaction 🔑group identifier: the group this PRR belongs to.reserved inside IP address: the IPv4 or IPv6 address reserved on the inside of the middlebox. For an outbound flow, this is where the inside endpoint sends its packets (A1 in Figure 3). For an inbound flow, it's the apparent source address of packets forwarded to the inside endpoint (A0 in Figure 3). The middlebox only reserves and reports an inside address when twice-NAT is in effect. Otherwise, empty address values mean no inside reservation was made. See also Section 2.3.5.reserved inside port number: see section 2.3.5.reserved outside IP address: the IPv4 or IPv6 address reserved on the outside of the middlebox. For an inbound flow, this is where the outside endpoint sends its packets (A2 in Figure 4). For an outbound flow, it's the apparent source address of packets forwarded to the outside endpoint (A3 in Figure 3). If the middlebox is configured as a pure firewall, empty address values mean no outside reservation was made. See also section 2.3.5.reserved outside port number: see section 2.3.5.policy rule lifetime: the lifetime the middlebox actually granted. After that, the reservation gets revoked, unless a policy enable rule in a PER transaction has already replaced it 🕰️
If it doesn't work out, you get one of these failure reasons 💀
agent not authorized for this transactionagent not authorized to add members to this grouplack of IP addresseslack of port numberslack of resourcesspecified inside/outside interface does not existspecified inside/outside interface not available for specified service
notification message type: Policy Rule Event Notification (REN) 📣
semantics
The agent can use this transaction to reserve an IP address, or a combo of IP address, transport type, port number, and port range, on neither side, one side, or both sides of the middlebox. Whatever is needed to support enabling a flow works here 🦋 You'd typically use the PRR when you need to reserve something before you have enough parameters for a complete policy enable rule transaction. See section 4.2 for an example.
When the request arrives, the middlebox figures out how many address (and port) reservations it needs, based on its configuration. If it only provides packet filter services, it doesn't reserve anything and returns empty values for the reserved inside and outside IP addresses and port numbers. If it's configured for twice-NAT, it reserves both inside and outside IP addresses (plus an optional range of port numbers) and returns them. Otherwise, it reserves and returns an outside IP address (plus an optional range of port numbers), and returns empty values for the reserved inside address and port range 💅
The A0 parameters (inside IP address version, inside IP address, and inside port number) help the middlebox work out the correct NAT mapping, and therefore A2 when needed. Once a PRR has reserved an outside address (A2) for an inside endpoint (A0), the middlebox MUST ensure that this reserved A2 is still available in any later PER and PRR transaction. Don't let it vanish on us 😭
For middleboxes that support interface-specific policy rules, as defined in section 2.3.7, the optional inside and outside interface parameters MUST both be included in the request, or SHOULD be left out entirely. When they're there, the middlebox uses the outside interface parameter to pick the interface where the outside address tuple (outside IP address and port number) is reserved, and the inside interface parameter to pick the interface where the inside address tuple (inside IP address and port number) is reserved. Without them, the middlebox picks the interfaces based on its own internal configuration 🧚
If resources run low, like available IP addresses, port numbers, or storage for more policy rules, the reservation fails and an appropriate failure reply gets generated 🥲
If you specify a policy rule group that doesn't exist, or one that exists but isn't owned by the requesting agent, then no new policy rule gets established and an appropriate failure reply gets generated 🙅♀️
On success, this transaction creates a new policy reserve rule. If you specified an existing policy rule group, the new rule becomes a member of it. If you didn't specify one, a new group gets created with the new rule as its only member. The middlebox generates a middlebox-unique identifier for the new rule, and the owner is the authenticated agent that sent the request 👑 The middlebox picks a lifetime that's greater than zero and at most the smaller of the requested value and the maximum lifetime the middlebox set at session startup:
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)where
lt_grantedis the lifetime the middlebox actually grantslt_requestedis the lifetime the agent asked forlt_maximumis the maximum lifetime set at session setup
A middlebox with NAT capability always reserves a middlebox external address tuple (A2) in response to a PRR request. In the special case of a combined twice-NAT/NAT middlebox, the agent can ask for only NAT service or only twice-NAT service by choosing 'traditional' or 'twice' for the service parameter. An agent with no preference picks 'twice'. The 'traditional' value SHOULD only be used to pick traditional NAT service on middleboxes that offer both traditional NAT and twice NAT. With 'twice', the combined middlebox reserves A2 and A1. With 'traditional', it reserves A2 only. An agent MUST always use the PRR transaction to choose NAT only or twice-NAT service in the special case of a combined twice-NAT/NAT middlebox 🎯 A firewall middlebox ignores this parameter.
If the protocol identifier is 'ANY', the middlebox only reserves available inside and/or outside IP address(es). Those reserved addresses get returned to the agent. In this case, the request parameters "port range" and "port parity", plus the reply parameters "inside port number" and "outside port number", don't matter at all 🤷♀️
If the protocol identifier is 'UDP' or 'TCP', the middlebox reserves a combo of an IP address and a consecutive sequence of port numbers, starting with the specified parity. This happens on neither side, one side, or both sides of the middlebox, depending on what's appropriate. The IP address(es) and the first (lowest) reserved port number(s) in the sequence get returned to the agent. (This also applies to other protocols that support ports or the equivalent.) 🔌
After a new policy reserve rule is successfully established and the reply has been sent to the requesting agent, the middlebox checks whether any other authenticated agents in open sessions can access the new rule. If it finds one or more, it sends a REN message reporting the new rule to each of them 📣
MIDCOM agents use the policy enable rule (PER) transaction to enable policy reserve rules that were set up earlier by a policy reserve rule (PRR) transaction. See also section 2.3.2. 💜
2.3.9. Policy Enable Rule (PER) ✨
transaction-name: policy enable rule
transaction-type: configuration
transaction-compliance: mandatoryOkay so the PER is the transaction that turns a PRR's reservation into an actual, enabled policy 💖 Here's what you send in the request 💌
request identifier: an agent-unique ID so the agent can match the request to its reply.policy reserve rule identifier: a reference to a policy reserve rule that already exists from a PRR transaction. This reference MAY be empty. If it's empty, the middlebox MUST assign any necessary addresses and port numbers within this PER transaction 🧁 If it's not empty, then the following request parameters don't matter: group identifier, transport protocol, port range, port parity, internal IP version, external IP version.group identifier: the group this PER should join. As covered in section 2.3.3, if you leave it out, the middlebox makes a brand-new group for it 👑transport protocol: see section 2.3.5.port range: how many consecutive port numbers to reserve. See section 2.3.5.- port parity 🎀: The requested parity of the port number(s) to be mapped. Allowed values of this parameter are
sameandany. See also section 2.3.5. 🧚 - direction of flow 🦋: This parameter specifies the direction of enabled communication, either
inbound,outbound, orbi-directional. 💜 - internal IP version 🌸: Requested IP version at the inside of the middlebox; see section 2.3.5.
- internal IP address 🍓: The IP address of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- internal port number ✨: The port number of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- inside interface (optional) 🫶: Interface at the inside of the middlebox; see section 2.3.7.
- external IP version 🌈: Requested IP version at the outside of the middlebox; see section 2.3.5.
- external IP address 👑: The IP address of the external communication endpoint (A3 in Figure 3); see section 2.3.5.
- external port number 💖: The port number of the external communication endpoint (A3 in Figure 4), see section 2.3.5.
- outside interface (optional) 🌙: Interface at the outside of the middlebox; see section 2.3.7.
- policy rule lifetime ⏳: A lifetime proposal to the middlebox for the requested policy rule.
Reply-parameters (success) 🎉
- request identifier 🪪: An identifier matching the identifier of the request.
- policy rule identifier 🔑: A middlebox-unique policy rule identifier. It is assigned by the middlebox and used as policy rule handle in further policy rule transactions. If a policy reserve rule identifier was provided in the request, then the returned policy rule identifier has the same value.
- group identifier 🧁: A reference to the group of which the policy enable rule is a member. If a policy reserve rule identifier was provided in the request, then this parameter identifies the group of which the policy reserve rule was a member.
- inside IP address 🏠: The IP address provided at the inside of the middlebox (A1 in Figure 3). In case of a twice-NAT, this parameter will be an internal IP address reserved at the inside of the middlebox. In all other cases, this reply-parameter will be identical with the external IP address passed with the request. If the policy reserve rule identifier parameter was supplied in the request and the respective PRR transaction reserved an inside IP address, then the inside IP address provided in the PER response will be the identical value to that returned by the response to the PRR request. See also section 2.3.5.
- inside port number 🚪: The internal port number provided at the inside of the middlebox (A1 in Figure 3); see also section 2.3.5.
- outside IP address 🌍: The external IP address provided at the outside of the middlebox (A2 in Figure 4). In case of a pure firewall, this parameter will be identical with the internal IP address passed with the request. In all other cases, this reply-parameter will be an external IP address reserved at the outside of the middlebox. See also section 2.3.5.
- outside port number 🛣️: The external port number provided at the outside of the NAT (A2 in Figure 3); see section 2.3.5..
- policy rule lifetime ⏳: The policy rule lifetime granted by the middlebox.
Failure reason 🙀
agent not authorized for this transactionagent not authorized to add members to this groupno such policy reserve ruleagent not authorized to replace this policy reserve ruleconflict with already existing policy rule (e.g., the same internal address-port is being mapped to different outside address-port pairs)lack of IP addresseslack of port numberslack of resourcesno internal IP wildcarding allowedno external IP wildcarding allowedspecified inside/outside interface does not existspecified inside/outside interface not available for specified servicereserved A0 to requested A0 mismatch
Notification message type: Policy Rule Event Notification (REN) 📣
Semantics 💅
This transaction can be used by an agent to enable communication between an internal endpoint and an external endpoint, and it works no matter what type of middlebox you've got (NAT, NAPT, firewall, NAT-PT, combined devices). It works for unidirectional or bi-directional traffic too. Iconic, right? 🦋
The agent sends an enable request specifying the endpoints (optionally including wildcards) and the direction of communication (inbound, outbound, bi-directional). The communication endpoints are displayed in Figure 3. The basic operation of the PER transaction goes like this:
- the agent sending A0 and A3 to the middlebox,
- the middlebox reserving A1 and A2 or using A1 and A2 from a previous PRR transaction,
- the middlebox enabling packet transfer between A0 and A3 by binding A0-A2 and A1-A3 and/or by opening the corresponding pinholes, both according to the specified direction, and
- the middlebox returning A1 and A2 to the agent.
In case of a pure packet filtering firewall, the returned address tuples are the same as those in the request: A2=A0 and A1=A3. Each partner uses the other's real address. 🤝 In case of a traditional NAT, the internal endpoint may use the real address of the external endpoint (A1=A3), but the external endpoint uses an address tuple provided by the NAT (A2!=A0). In case of a twice-NAT device, both endpoints use address tuples provided by the NAT for addressing their communication partner (A3!=A1 and A2!=A0).
If a firewall is combined with a NAT or a twice-NAT, the replied address tuples will be the same as for pure traditional NAT or twice-NAT, respectively, but the middlebox will configure its packet filter in addition to the performed NAT bindings. In case of a firewall combined with a traditional NAT, the policy rule MAY imply more than one enable action for the firewall configuration, as incoming and outgoing packets may use different source-destination pairs. 🧠
For middleboxes supporting interface specific policy rules, as defined in Section 2.3.7, the optional inside and outside interface parameters MUST both be included in the request, or neither of them SHOULD be included. When these parameters are present, the middlebox uses the outside interface parameter to select the interface at which the outside address tuple (outside IP address and port number) is bound, and the inside interface parameter to select the interface at which the inside address tuple (inside IP address and port number) is bound. Without these parameters, the middlebox selects the particular interfaces based on its internal configuration. 🎯
Checking the Policy Reservation Rule Identifier 🔍
If the parameter specifying the policy reservation rule identifier is not empty, then the middlebox checks whether the referenced policy rule exists, whether the agent is authorized to replace this policy rule, and whether this policy rule is a policy reserve rule.
In case of success, this transaction creates a new policy enable rule. If a policy reserve rule was referenced, then the policy reserve rule is terminated without an explicit notification sent to the agent (other than the successful PER reply). ✅
The PRR transaction sets the internal endpoint A0 during the reservation process. In the process of creating a new policy enable rule, the middlebox MAY check whether the requested A0 is equal to the reserved A0. The middlebox MAY reject a PER request with a requested A0 not equal to the reserved A0 and MUST then send an appropriate failure message. Alternatively, the middlebox MAY change A0 due to the PER request. 😬
The middlebox generates a middlebox-unique identifier for the new policy rule. If a policy reserve rule was referenced, then the identifier of the policy reserve rule is reused. ♻️
The owner of the new policy rule is the authenticated agent that sent the request. 👑
Checking the Policy Rule Group Identifier 🧩
If no policy reserve rule was specified, then the policy rule group parameter is checked. If a non-existing policy rule group is specified, or if an existing policy rule group is specified that is not owned by the requesting agent, then no new policy rule is established, and an appropriate failure reply is generated. 🙅♀️
If an already existing policy rule group is specified, then the new policy rule becomes a member. If no policy group is specified, then a new group is created with the new policy rule as its only member. 🌱
If the transport protocol parameter value is 'ANY', then the middlebox enables communication between the specified external IP address and the specified internal IP address. The addresses to be used by the communication partners to address each other are returned to the agent as inside IP address and outside IP address. If the reservation identifier is not empty and if the reservation used the same transport protocol type, then the reserved IP addresses are used. 🫧
For the transport protocol parameter values 'UDP' and 'TCP', the middlebox acts analogously as for 'ANY', but also maps ranges of port numbers, keeping the port parity if requested. 🔢
The configuration of the middlebox may fail because of lack of resources, such as available IP addresses, port numbers, or storage for further policy rules. It may also fail because of a conflict with an established policy rule. In case of a conflict, the first-come first-served mechanism is applied. Existing policy rules remain unchanged and arriving new ones are rejected. However, in case of a non-conflicting overlap of policy rules (including identical policy rules), all policy rules are accepted. ⚖️
The middlebox chooses a lifetime value that is greater than zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox at session startup, i.e.,
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)where
- lt_granted is the lifetime actually granted by the middlebox
- lt_requested is the lifetime the agent requested
- lt_maximum is the maximum lifetime specified at session setup
In each case of failure, an appropriate failure reply is generated. The policy reserve rule that is referenced in the PER transaction is not affected in case of a failure within the PER transaction -- i.e., the policy reserve rule remains. 🛡️
After a new policy enable rule is successfully established and the reply message has been sent to the requesting agent, the middlebox checks whether there are other authenticated agents participating in open sessions that can access the new policy rule. If the middlebox finds one or more of these agents, then it sends a REN message reporting the new policy rule to each of them. 📨 🌟
2.3.10. Policy Rule Lifetime Change (RLC) 💖
transaction-name: policy rule lifetime change
transaction-type: configuration
transaction-compliance: mandatoryokay so this one is the "hey, can we change how long this rule sticks around?" transaction 🕰️✨
Request parameters:
request identifier: an agent-unique ID so the agent can match its request to the reply 🎀policy rule identifier: which policy rule's lifetime you want to change 🦋 this can be a policy reserve rule or a policy enable rulepolicy rule lifetime: your new lifetime proposal for the rule 💅
Reply parameters (success):
request identifier: matches the ID from the request 🫶policy rule lifetime: the remaining lifetime the middlebox actually granted 👑
Failure reasons:
agent not authorized for this transaction
agent not authorized to change lifetime of this policy
rule
no such policy rule
lifetime cannot be extendedNotification message type: Policy Rule Event Notification (REN) 🔔
Semantics:
Agents can use this to ask for a longer lifetime, a shorter lifetime, or to end the rule altogether 💀 Ending it is done by proposing a new lifetime of zero, which is giving main character energy 🌈
The middlebox checks two things first: does the rule exist, and is this agent allowed to touch it? If either check fails, you get an appropriate failure reply 😭 If your requested lifetime is longer than the current one, it also checks whether the rule is even allowed to be extended, and if not, you get a failure message too 🙈
A failure reply means your new lifetime was not accepted, and the rule stays exactly the same 🧚 A success reply is sent whenever the lifetime was changed in any way ✨
The success reply carries the new lifetime, and the middlebox picks a value that is greater than zero and no bigger than the smaller of your requested value and the maximum lifetime the middlebox set when the session started 🎀 In other words:
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)where:
lt_grantedis the lifetime the middlebox actually grants 💜lt_requestedis the lifetime the agent asked for 🍓lt_maximumis the maximum lifetime set at session setup 🌸
⚠️ Once a success reply with a lifetime of zero has been sent, the middlebox considers the rule non-existent. Any later transaction on that rule gets a negative reply saying it doesn't exist anymore. Gone, bestie 💀
Also, the group lifetime can be changed by the Group Lifetime Change (GLC) transaction too, if the rule belongs to that group, so keep an eye on that 👀
After the lifetime was successfully changed and the reply has gone back to the requesting agent, the middlebox looks for any other authenticated agents with open sessions who can access the rule. If it finds any, it sends each of them a REN message with the new remaining lifetime 📣 everyone gets the tea ☕
2.3.11. Policy Rule List (PRL) 🌷
transaction-name: policy rule list
transaction-type: monitoring
transaction-compliance: mandatorythis is the "what rules can I even see?" transaction 🔍
Request parameters:
request identifier: an agent-unique ID to match request and reply 🎀
Reply parameters (success):
request identifier: matches the request's ID 🫶policy list: the policy rule identifiers for every rule that this agent can access 📋
Failure reasons:
transaction not supported
agent not authorized for this transactionSemantics:
Agents can use this to list every policy they can access 💅 Usually the agent already knows this, but it comes in clutch after something like an agent fail-over, or for special agents like an administrating one that can access all policies 👑
The middlebox first checks whether the agent is allowed to make this request. If that check fails, you get an appropriate failure reply 🙈 Otherwise you get the full list of policies the agent can access, with the identifier and owner of each one 🧚
This transaction has no effect on the policy rule state, so it's totally safe to just look 👀
2.3.12. Policy Rule Status (PRS) 🔎
transaction-name: policy rule status
transaction-type: monitoring
transaction-compliance: mandatorythis is the deep-dive one, where you get all the details about a single rule 🕵️♀️✨
Request parameters:
request identifier: an agent-unique ID to match request and reply 🎀policy rule identifier: the middlebox-unique identifier of the rule 🦋
Reply parameters (success):
request identifier: matches the request's ID 🫶policy rule owner: identifies the agent that owns this rule 👑group identifier: a reference to the group this rule belongs to 🌈policy rule action: has the value'reserve'or the value'enable'💖transport protocol: says which protocol the reservation is for; see section 2.3.5 🌸port range: the number of consecutive port numbers; see section 2.3.5 🍓direction: the direction of the communication the middlebox enables. This only applies to policy enable rules 🧚internal IP address version: the version of the internal IP address (the IP version of A0 in Figure 3) 🎀external IP address version: the version of the external IP address (the IP version of A3 in Figure 3) 🎀internal IP address: the IP address of the internal communication endpoint (A0 in Figure 3); see section 2.3.5 🦋internal port number: the port number of the internal communication endpoint (A0 in Figure 3); see section 2.3.5 🦋external IP address: the IP address of the external communication endpoint (A3 in Figure 3); see section 2.3.5 🌍external port number: the port number of the external communication endpoint (A3 in Figure 3); see section 2.3.5 🌍inside interface (optional): the inside interface at the middlebox; see section 2.3.7 🏠inside IP address: the internal IP address provided on the inside of the NAT (A1 in Figure 3); see section 2.3.5 🏠inside port number: the internal port number provided on the inside of the NAT (A1 in Figure 3); see section 2.3.5 🏠outside interface (optional): the outside interface at the middlebox; see section 2.3.7 🌤️outside IP address: the external IP address provided on the outside of the NAT (A2 in Figure 3); see section 2.3.5 🌤️outside port number: the external port number provided on the outside of the NAT (A2 in Figure 3); see section 2.3.5 🌤️port parity: the parity of the allocated ports ⚖️service: the selected service when you've got a mixed traditional and twice-NAT middlebox (see section 2.3.8) 💫policy rule lifetime: the remaining lifetime of the policy rule ⏳
Failure reasons:
transaction not supported
agent not authorized for this transaction
no such policy rule
agent not authorized to access this policy ruleSemantics:
Agents can use this to list all the properties of a policy rule 📜 Again, the agent usually has this already, but after an agent fail-over, or for special agents like an administrating one that can access all policy rules, this transaction is a lifesaver 🛟
The middlebox first checks whether the specified rule exists and whether the agent is authorized to access this group 🧐 (yes, it says "group" there, and yes, that's the spec, so we're keeping it 🙃) If one of those checks fails, you get an appropriate failure reply 😭 Otherwise, all the properties of the rule come back to the agent 💅
Some of the returned parameters may be irrelevant, depending on the policy rule action ('reserve' or 'enable') and on other parameters -- for example, the protocol identifier 🤷♀️ so don't panic if a field looks empty, it's just not applicable 🫶
This transaction has no effect on the policy rule state, so it's read-only vibes only 👀✨
2.3.13. Asynchronous Policy Rule Event (ARE) 🔔
transaction-name: asynchronous policy rule event
transaction-type: notification
transaction-compliance: mandatorythis is the middlebox being spontaneous and telling everyone at once 📣
Notification message type: Policy Rule Event Notification (REN) 🔔
Semantics:
The middlebox can decide, at any moment, to terminate a policy rule 💀 This happens most often when the rule's lifetime runs out ⏰ Other things can trigger it too, like changes in the policy rule decision point 🧠
When that happens, the middlebox sends a REN message to every agent that has an open session with it and is authorized to access the rule 📨 The notification goes out before the middlebox changes the rule's lifetime 🙌 That lifetime change might be triggered by any other authorized agent, and it can end up as a shortening (lt_new < lt_existing), an extension (lt_new > lt_existing), or a termination of the rule (lt_new = 0) 🌈
The ARE transaction corresponds to the REN message handling described in section 2.3.4 for multiple agents 🫶 basically, the same group-chat energy, just for everyone at once 💜
2.3.14. Policy Rule State Machine ✨
Okay bestie, this is the whole life cycle of a policy rule 🦋 The state machine for policy rule transactions is in Figure 4, and it shows every possible transition. The abbreviations you'll see are explained in the headings of each transaction section.
PRR/success +---------------+
+-----------------+ PRID UNUSED |<-+
+----+ | +---------------+ |
| | | ^ | |
| v v | | |
| +-------------+ ARE | | PER/ | ARE
| | RESERVED +------------+ | success | RLC(lt=0)/
| +-+----+------+ RLC(lt=0)/ | | success
| | | success | |
+----+ | v |
RLC(lt>0)/ | PER/success +---------------+ |
success +---------------->| ENABLED +--+
+-+-------------+
| ^
lt = lifetime +-----------+
RLC(lt>0)/successFigure 4: Policy Rule State Machine 💜
This state machine exists separately for each policy rule identifier (PRID) 💅 At the start, every policy rule is in PRID UNUSED, which basically means the rule doesn't exist or isn't active. Once a PRID is back in PRID UNUSED, it's no longer tied to an existing policy rule, so the middlebox is allowed to reuse it. 🌈
A successful PRR moves things from PRID UNUSED to RESERVED, where an address reservation gets set up. From RESERVED, a PER gets you into ENABLED. A PER can also jump straight from PRID UNUSED into ENABLED without a reservation at all. In ENABLED, the requested communication between the internal and external endpoints is switched on ✨
RLC with a lifetime greater than 0 keeps RESERVED or ENABLED going. Getting back to PRID UNUSED from either of those states happens with an ARE transaction, or with a successful RLC whose lifetime parameter is 0 🙈
A failed request transaction doesn't change the state at the middlebox, so nothing shifts if the request flops 💀
Quick aside: transitions started by RLC transactions can also be started by GLC transactions, so keep that in mind 👑
2.4. Policy Rule Group Transactions ✨
Groups time! 🧚 This section covers the transactions that work on whole groups of policy rules. There are three:
- Group Lifetime Change (GLC)
- Group List (GL)
- Group Status (GS)
All three are request transactions started by the agent. GLC is a convenience transaction. GL and GS are monitoring transactions, and they don't have any effect on the group state machine 🫶
2.4.1. Overview
A policy rule group has only one attribute, and that's its list of members. Every member policy of a single group has to be owned by the same authenticated agent. So a group's owner is just the owner of its member policy rules, which makes it an implicit property of the group 👑
A group gets created implicitly when its first member policy rule is established. It gets terminated implicitly when the last remaining member policy rule is terminated. That means the lifetime of a group is the maximum of the lifetimes of all its member policy rules ⏳
Every group has a middlebox-unique identifier 🔑
Group transactions are declared as 'optional' by their compliance entries in section 3. Even so, they're super useful. They give the agent convenience, like sending one request instead of several, and that perk isn't there if only the mandatory transactions are available 💖
The Group Lifetime Change (GLC) transaction is basically the same as running Policy Rule Lifetime Change (RLC) transactions on every member of the group at the same time. A successful GLC leaves all member policy rules with the same lifetime. Just like RLC, GLC can delete all the member policy rules by requesting a lifetime of zero 🗑️
The monitoring transactions, Group List (GL) and Group Status (GS), let the agent check the state of the middlebox and explore its access rights 🔍 GL lists every group the agent may access, including groups owned by other agents. GS reports the status of one individual group and lists all of its policy rules by their policy rule identifiers. From there, the agent can dig into each individual policy rule with a policy rule status (PRS) transaction (see section 2.3.12) 🦋
GL and GS are especially helpful when there's an agent fail-over. The agent taking over for a failed one can use these transactions to retrieve whichever policies the failed agent set up 🫶
Notifications about group events work the same way as policy rule events. To tell agents about group events, the Policy Rule Group Event Notification (GEN) message type is used. GEN messages carry an agent-unique notification identifier, the policy rule group identifier, and the remaining lifetime of the group ✨
2.4.2. Group Lifetime Change (GLC)
transaction-name: group lifetime change
transaction-type: convenience
transaction-compliance: optional
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
- group identifier: A reference to the group for which the
lifetime is requested to be changed.
- group lifetime: The new lifetime proposal for the group.
reply-parameters (success):
- request identifier: An identifier matching the identifier of the
request.
- group lifetime: The group lifetime granted by the middlebox.
failure reason:
- transaction not supported
- agent not authorized for this transaction
- agent not authorized to change lifetime of this group
- no such group
- lifetime cannot be extended
notification message type: Policy Rule Group Event Notification (GEN)Semantics time! 🎀 The agent can use GLC to ask for a longer lifetime for all members of a policy rule group, a shorter one, or to terminate all member policies (which also terminates the group). To terminate, the agent suggests a new group lifetime of zero 💀
The middlebox checks first whether the specified group exists and whether the agent is allowed to access it. If either check fails, the middlebox generates an appropriate failure reply 🙅♀️ If the requested lifetime is longer than the current one, the middlebox also checks whether the group's lifetime can be extended at all. If it can't, it generates an appropriate failure message.
A failure reply means the group's lifetime stays exactly the same. The middlebox generates a success reply whenever the group's lifetime changed in any way 🌸
The success reply holds the new common lifetime of all the member policy rules in the group. The middlebox picks that new lifetime so that it's less than or equal to the minimum of the requested lifetime and the maximum lifetime the middlebox set at session setup along with its other capabilities. In formula form:
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)where:
lt_grantedis the lifetime actually granted by the middleboxlt_requestedis the lifetime the agent requestedlt_maximumis the maximum lifetime specified at session setup
After the middlebox sends a success reply with a lifetime of zero, it terminates the member policy rules without any further notification to the agent. From then on, the group and all of its members count as non-existent. Any later transaction on this policy rule group, or on any of its members, gets a negative reply saying that the group or policy rule, respectively, doesn't exist anymore 😭
After the remaining policy rule group lifetime has been successfully changed and the reply has gone back to the requesting agent, the middlebox checks whether other authenticated agents in open sessions can access the policy rule group. If it finds one or more, it sends each of them a GEN message reporting the new remaining policy rule group lifetime 📣
2.4.3. Group List (GL)
transaction-name: group list
transaction-type: monitoring
transaction-compliance: optional
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
reply-parameters (success):
- request identifier: An identifier matching the identifier of the
request.
- group list: List of all groups that the agent can access. For
each listed group, the identifier and the owner are indicated.
failure reason:
- transaction not supported
- agent not authorized for this transactionSemantics, but make it cute 🍓 The agent can use GL to list every group it can access. Usually the agent already has this info, but there are special cases where GL really shines, like after an agent fail-over, or for special agents such as an administrating agent that can access all groups 🧚
The middlebox first checks whether the agent is authorized to request this transaction. If that check fails, the middlebox generates an appropriate failure reply. Otherwise, it returns a list of all the groups the agent can access, with the identifier and the owner of each group ✨
This transaction has no effect on the group state 🦋
2.4.4. Group Status (GS) 💅
transaction-name: group status ✨
transaction-type: monitoring 👀
transaction-compliance: optional 🌸
request-parameters:
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent. 🎀
- group identifier: A reference to the group for which status information is requested. 🧚
reply-parameters (success):
- request identifier: An identifier matching the identifier of the request. 🦋
- group owner: An identifier of the agent owning this policy rule group. 👑
- group lifetime: The remaining lifetime of the group. This is the maximum of the remaining lifetime of all members, policy rules. ⏳
- member list: List of all policy rules that are members of the group. The policy rules are specified by their middlebox-unique policy rule identifier. 📋
failure reason:
- transaction not supported
- agent not authorized for this transaction
- no such group
- agent not authorized to list members of this group
semantics:
Okay so, the GS transaction is how an agent can list every member policy rule of a group. 🫶 Usually the agent already has this info saved, but it's lowkey super useful in special cases, like after an agent fail-over 😭, or for special agents (think an administrating agent that can access all groups) 👑.
The middlebox checks two things first: does the specified group exist, and is the agent allowed to access it? 🔍 If either check fails, it sends back the matching failure reply. 💀 If both pass, it returns a list of all group members, with each one's identifier. 💖
And this transaction does not have any effect on the group state. It's just a look, no touching! 🙈
3. Conformance Statements 📜
A protocol definition complies with the semantics defined in section 2 if the protocol specification includes all specified transactions with all their mandatory parameters. ✅ BUT, concrete implementations are allowed to support only some of the optional transactions, not all of them. 🌈 Which transactions are required for compliance is different for agent and middlebox, so keep that in mind, bestie! 🧚
This section has the conformance statements for MIDCOM protocol implementations related to the semantics. Conformance is specified differently for agents and middleboxes. 🦋 These statements will probably get extended by a concrete protocol specification, and that extension is expected to extend the statements below in such a way that all of them still hold. 💜
Here's the transaction-compliance property of every transaction from the previous section 💅:
- Session Control Transactions
- Session Establishment (SE) mandatory
- Session Termination (ST) mandatory
- Asynchronous Session Termination (AST) mandatory
- Policy Rule Transactions
- Policy Reserve Rule (PRR) mandatory
- Policy Enable Rule (PER) mandatory
- Policy Rule Lifetime Change (RLC) mandatory
- Policy Rule List (PRL) mandatory
- Policy Rule Status (PRS) mandatory
- Asynchronous Policy Rule Event (ARE) mandatory
- Policy Rule Group Transactions
- Group Lifetime Change (GLC) optional
- Group List (GL) optional
- Group Status (GS) optional3.1. General Implementation Conformance 🎀
A compliant implementation of a MIDCOM protocol must support all mandatory transactions. 💯
A compliant implementation of a MIDCOM protocol may support none, one, or more of the following transactions: GLC, GL, GS. 🌸
A compliant implementation may extend the protocol semantics by further transactions. ⭐
A compliant implementation of a MIDCOM protocol must support all mandatory parameters of each transaction concerning the information contained. The set of parameters can be redefined per transaction as long as the contained information is maintained. 🧩
A compliant implementation of a MIDCOM protocol may support the use of interface-specific policy rules. Either both or neither of the optional inside and outside interface parameters in PRR, PER, and PRS must be included when interface-specific policy rules are supported. 🫣
A compliant implementation may extend the list of parameters of transactions. 🍓
A compliant implementation may replace a single transaction by a set of more fine-grained transactions. In such a case, it must be ensured that requirement 2.1.4 (deterministic behavior) and requirement 2.1.5 (known and stable state) of [MDC-REQ] are still met. 🔥 When a single transaction is replaced by a set of multiple fine-grained transactions, this set must be equivalent to a single transaction. Furthermore, this set of transactions must further meet the atomicity requirement stated in section 2.1.3. 💜
3.2. Middlebox Conformance 🧚
A middlebox implementation of a MIDCOM protocol supports a request transaction if it is able to receive and process all possible correct message instances of the particular request transaction, and if it generates a correct reply for any correct request it receives. 📬
A middlebox implementation of a MIDCOM protocol supports an asynchronous transaction if it is able to generate the corresponding notification message properly. 🔔
A compliant middlebox implementation of a MIDCOM protocol must inform the agent about the list of supported transactions within the SE transaction. 📣
3.3. Agent Conformance 🦋
An agent implementation of a MIDCOM protocol supports a request transaction if it can generate the corresponding request message properly, and if it can receive and process all possible correct replies to the particular request. 🎀
An agent implementation of a MIDCOM protocol supports an asynchronous transaction if it can receive and process all possible correct message instances of the particular transaction. 👂
A compliant agent implementation of a MIDCOM protocol must not use any optional transaction that is not supported by the middlebox. The middlebox informs the agent about the list of supported transactions within the SE transaction. 🙅♀️
4. Transaction Usage Examples 🌈
This section gives two usage examples of the transactions specified in Section 2. ✨ The first shows how an agent can explore all policy rules and policy rule groups that it may access at a middlebox. 🔍 The second example shows the configuration of a middlebox in combination with the setup of a voice over IP session with the Session Initiation Protocol (SIP) [RFC3261]. 📞🫶
4.1. Exploring Policy Rules and Policy Rule Groups ✨
Okay bestie, so this example assumes an already established session 🎀 It shows how an agent can figure out:
- which groups it may access and who owns these groups,
- the status and member list of all accessible groups, and
- the status and properties of all accessible policy rules.
If there's just a single session, none of this is needed 🙈 The middlebox tells the agent about every state transition of any policy rule or policy rule group. But after a session gets disrupted or intentionally terminated, the agent might want to reconnect and check which of its groups and policy rules are still in place 🦋
Also, an agent system can fail and another one takes over 💀 The new agent system then needs to find out what the failing one already configured and what still needs doing.
A third situation where exploring is useful is an agent with 'administrator' authorization 👑 That agent can access and modify any policy rule or group created by any other agent.
All agents will probably start with the Group List (GL) transaction, as shown in Figure 5 💅 The middlebox replies with a list of pairs, each holding an agent identifier and a group identifier (GID). That tells the agent which of its own groups, and which other agents' groups, it can access.
agent middlebox
| GL |
|**********************************************>|
|<**********************************************|
| (agent1,GID1) (agent1,GID2) (agent2,GID3) |
| |
| GS GID2 |
|**********************************************>|
|<**********************************************|
| agent1 lifetime PID1 PID2 PID3 PID4 |
| |Figure 5: Using the GL and the GS transaction
In Figure 5 there are three accessible groups, and the agent uses the Group Status (GS) transaction to get info about the second one 🔥 It gets back the owner, the remaining lifetime, and the member policy rules, which here are four policy rule identifiers (PIDs).
Next up, the agent explores those four policy rules 🌸 The example assumes the middlebox is a traditional NAPT. Figure 6 shows the first policy rule. In reply to a Policy Rule Status (PRS) transaction, the middlebox always returns this list of parameters:
- policy rule owner
- group identifier
- policy rule action (reserve or enable)
- protocol type
- port range
- direction
- internal IP address
- internal port number
- external address
- external port number
- middlebox inside IP address
- middlebox inside port number
- middlebox outside IP address
- middlebox outside port number
- IP address versions (not printed)
- middlebox service (not printed)
- inside and outside interface (optional, not printed)
agent middlebox
| PRS PID1 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 RESERVE UDP 1 "" |
| ANY ANY ANY ANY |
| ANY ANY IPADR_OUT PORT_OUT1 |
| |Figure 6: Status report for an outside reservation
The 'ANY' you see in Figure 6 is a placeholder that shows up in policy rule status replies for policy reserve rules 🧚 PID1 is a policy reserve rule for UDP traffic on the outside of the middlebox. Since it's a reserve rule, direction is empty. There's no internal or external address involved yet, so those four fields get wildcarded in the reply. The same goes for the inside middlebox address and port number. The only address info in the reply is the reserved outside IP address of the middlebox (IPADDR_OUT) and its port number (PORT_OUT1). Note that IPADR_OUT and PORT_OUT1 may not be wildcarded, because the reserve action doesn't support that ⚠️
Heads up: IPADR_OUT and PORT_OUT1 are the only real address values in a reserve reply, so they can't be wildcarded. ✨
Now PRS on PID2 (Figure 7) shows the second rule is a policy enable rule for inbound UDP packets 🦋 The internal destination is fixed for IP address, protocol, and port number. For the external source, the port number is wildcarded. The outside IP address and port number of the middlebox are what the external sender has to use as destination in the original packet it sends. At the middlebox, that destination address gets replaced with the internal address of the final receiver. During address translation, the source IP address and source port numbers of the packets stay unchanged. You can tell because the inside address is identical to the external address 💜
agent middlebox
| PRS PID2 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ENABLE UDP 1 IN |
| IPADR_INT PORT_INT1 IPADR_EXT ANY |
| IPADR_EXT ANY IPADR_OUT PORT_OUT2 |
| |Figure 7: Status report for enabled inbound packets
For traditional NATs, the identity between the inside IP address and port number and the external IP address and port number always holds (A1=A3 in Figure 3) 🍓 For a pure firewall, the outside IP address and port number are always identical with the internal IP address and port number (A0=A2 in Figure 3).
agent middlebox
| PRS PID3 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ENABLE UDP 1 OUT |
| IPADR_INT PORT_INT2 IPADR_EXT PORT_EXT1 |
| IPADR_EXT PORT_EXT1 IPADR_OUT PORT_OUT3 |
| |Figure 8: Status report for enabled outbound packets
Figure 8 shows enabled outbound UDP traffic between the same host 🌈 Here all the port numbers are known. Since A1=A3 again, the internal sender uses the external IP address and port number as destination in the original packets. At the firewall, the internal source IP address and port number get replaced by the outside IP address and port number of the middlebox shown in the figure.
agent middlebox
| PRS PID4 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ENABLE TCP 1 BI |
| IPADR_INT PORT_INT3 IPADR_EXT PORT_EXT2 |
| IPADR_EXT PORT_EXT2 IPADR_OUT PORT_OUT4 |
| |Figure 9: Status report for bi-directional TCP traffic
Finally, Figure 9 shows the status report for enabled bi-directional TCP traffic 🫶 Note that A1=A3 still holds. For outbound packets, only the source IP address and port number get replaced at the middlebox. For inbound packets, only the destination IP address and port number get replaced.
4.2. Enabling a SIP-Signaled Call 📞
This elaborate transaction usage example shows how a SIP proxy and a middlebox work together 💖 The middlebox is a traditional Network Address and Port Translator (NAPT), and two SIP user agents talk to each other through the SIP proxy and NAPT, as shown in Figure 10. The MIDCOM agent is co-located with the SIP proxy, and the MIDCOM server sits at the middlebox. So the MIDCOM protocol runs between the SIP proxy and the middlebox 🎀
+-------------+
| SIP Proxy |
| for domain ++++
| example.com | +
+-------------+ +
^ ^ +
Private | | + Public Network
Network | | +
+----------+ | | +----+------+ +----------------+
| SIP User |<-+ +->| Middlebox |<------->| SIP User Agent |
| Agent A |<#######>| NAPT |<#######>| B@example.org |
+----------+ +-----------+ +----------------+
<--> SIP Signaling
<##> RTP Traffic
++++ MIDCOM protocolFigure 10: Example of a SIP Scenario
For the sequence charts below, here are our assumptions 🧚
- The NAPT is statically configured to forward SIP signaling from the outside to the SIP proxy server -- i.e., traffic to the NAPT's external IP address and port 5060 is forwarded to the internal SIP proxy.
- The SIP user agent A, located inside the private network, is registered at the SIP proxy with its private IP address.
- User A knows the general SIP URL of user B. The URL is B@example.org. However, the concrete URL of the SIP User Agent B, which user B currently uses, is not known.
- The RTP paths are configured, but not the RTCP paths.
- The middlebox and the SIP server share an established MIDCOM session.
- Some parameters are omitted, such as the request identifier (RID).
Furthermore, these abbreviations are used 💜
- IP_AI: Internal IP address of user agent A
- P_AI: Internal port number of user agent A to receive RTP data
- P_AE: External mapped port number of user agent A
- IP_AE: External IP address of the middlebox
- IP_B: IP address of user agent B
- P_B: Port number of user agent B to receive RTP data
- GID: Group identifier
- PID: Policy rule identifier
The abbreviations of the MIDCOM transactions can be found in the particular section headings 🦋
In our example, user A tries to call user B 📞 User agent A sends an INVITE SIP message to the SIP proxy server (see Figure 10). The SDP part of that SIP message that matters for the middlebox configuration is shown in the sequence chart like this:
SDP: m=..P_AI..
c=IP_AIHere the m tag is the media tag that holds the receiving UDP port number, and the c tag holds the IP address of the terminal receiving the media stream ✨
The INVITE message forwarded to user agent B must contain a public IP address and a port number that user agent B can send its RTP media stream to 🌸 The SIP proxy requests a policy enable rule at the middlebox with a PER request, using the wildcarded IP address and port number of user agent B. Since neither the IP address nor the port number of user agent B is known at this point, that address has to be wildcarded. The wildcarded IP address and port number enable the 'early media' capability, but they bring some insecurity 😭 Any outside host can reach user agent A on the enabled port number through the middlebox.
Okay so 👀 a successful PER reply (see Figure 11) makes a NAT binding at the middlebox 🦋. That means UDP traffic from any host outside user agent A's private network can reach user agent A 😬. User agent B could start sending right after the INVITE lands, and so could literally any other host, even ones that aren't supposed to be in the call, like a malicious host 💀 not me getting nervous 🙈
User Agent SIP Middlebox User Agent
A Proxy NAPT B
| | | |
| INIVTE | | |
| B@example.org | | |
| SDP:m=..P_AI.. | | |
| c=IP_AI | | |
|--------------->| | |
| | | |
| | PER PID1 UDP 1 EVEN IN | |
| | IP_AI P_AI ANY ANY 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID1 ANY ANY | |
| | IP_AE P_AE1 300s | |Figure 11: PER with wildcard address and port number
If the middlebox doesn't support IP address wildcarding, or doesn't allow it for security reasons 🔒, the PER request gets rejected with a failure reason like 'IP wildcarding not supported'. Even so, the SIP proxy server still needs an outside IP address and port number at the middlebox (the NAPT) so it can forward the SIP INVITE message 💌
If user agent B's IP address is still unknown (user agent B sends it in the SIP reply message) and IP address wildcarding isn't permitted, the SIP proxy server goes with the PRR transaction 🧚
With the PRR request, the SIP proxy asks for an outside IP address and port number (see Figure 12) without setting up a NAT binding or pin hole first ✨ The PRR request includes the service parameter 'tw', which means the MIDCOM agent picks the default value. In this setup, with NAPT and without a twice NAT, only an outside address gets reserved. In the SDP payload of the INVITE message, the SIP proxy swaps user agent A's IP address and port number for the reserved IP address and port from the PRR reply (see Figure 12). The SIP INVITE message then goes to user agent B with that modified SDP body, which has the outside address and port number where user agent B will send its RTP media stream 🎀
User Agent SIP Middlebox User Agent
A Proxy NAPT B
| | | |
...PER in Figure 11 has failed, continuing with PRR ...
| | | |
| |PRR tw v4 v4 A UDP 1 EVEN 300s| |
| |*****************************>| |
| |<*****************************| |
| | PRR OK PID1 GID1 EMPTY | |
| | IP_AE/P_AE 300s | |
| | | |
| | INVITE B@example.org SDP:m=..P_AE.. c=IP_AE |
| |-------------------------------------------->|
| |<--------------------------------------------|
| | 200 OK SDP:m=..P_B.. c=IP_B |Figure 12: Address reservation with PRR transaction
This SIP '200 OK' reply has the IP address and port number where user agent B will receive a media stream 📡 The IP address is assumed to match the one user agent B will send its media stream from 🫶
Now the SIP proxy has enough info to set up the full NAT binding with a policy enable rule (PER) transaction 🔥 so the UDP/RTP data of the call can flow from user agent B to user agent A. The PER transaction points at the reservation by passing the PID of the PRR (PID1) 💅
The other direction, UDP/RTP data from user agent A to B, also needs enabling. That happens with a second PER transaction carrying all the necessary parameters (see Figure 13) 🌈 This request includes the group identifier (GID1) the middlebox assigned in the first PER transaction, so both policy rules end up in the same group, which is so iconic 👑 Once both UDP/RTP streams are enabled, the SIP proxy can forward the '200 OK' SIP message to user agent A to say the call can start 📞
User Agent SIP Middlebox User Agent
A Proxy NAPT B
| | | |
| | PER PID1 UDP 1 SAME IN | |
| | IP_AI P_AI IP_B ANY 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID1 IP_B ANY | |
| | IP_AE P_AE1 300s | |
| | | |
...media stream from user agent B to A enabled...
| | | |
| | PER GID1 UDP 1 SAME OUT | |
| | IP_AI ANY IP_B P_B 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID2 IP_B P_B | |
| | IP_AE P_AE2 300s | |
| | | |
...media streams from both directions enabled...
| | | |
| 200 OK | | |
|<---------------| | |
| SDP:m=..P_B.. | | |
| c=IP_B | | |Figure 13: Policy rule establishment for UDP flows
User agent B decides to end the call and sends its 'BYE' SIP message to user agent A 📴 The SIP proxy forwards all the SIP messages and then terminates the group with a group lifetime change (GLC) transaction, requesting a remaining lifetime of 0 seconds (see Figure 14) 🧹 Terminating the group includes terminating all of its member policy rules 🌸
User Agent SIP Middlebox User Agent
A Proxy NAPT B
| | | |
| BYE | BYE |
|<---------------|<--------------------------------------------|
| | | |
| 200 OK | 200 OK |
|--------------->|-------------------------------------------->|
| | | |
| | GLC GID1 0s | |
| |*****************************>| |
| |<*****************************| |
| | GLC OK 0s | |
| | | |
...both NAT bindings for the media streams are removed...Figure 14: Termination of policy rule groups
5. Compliance with MIDCOM Requirements ⭐
This section explains how the specified semantics comply with the MIDCOM requirements 📋 It is structured according to [MDC-REQ]:
- Compliance with Protocol Machinery Requirements (section 5.1)
- Compliance with Protocol Semantics Requirements (section 5.2)
- Compliance with Security Requirements (section 5.3)
The requirements are referred to by the number of the section they're defined in. So "requirement x.y.z" means the requirement specified in section x.y.z of [MDC-REQ] 🔖
5.1. Protocol Machinery Requirements ⚙️
5.1.1. Authorized Association 🤝
The specified semantics let a MIDCOM agent set up an authorized association between itself and the middlebox. The agent identifies itself through the authentication mechanism of the Session Establishment transaction described in section 2.2.1. Based on that authentication, the middlebox can figure out whether the agent is allowed to request a service 🔐 So requirement 2.1.1 is met ✅
5.1.2. Agent Connects to Multiple Middleboxes 🦋
As specified in section 2.2, the MIDCOM protocol lets the agent talk to more than one middlebox at the same time. Picking a mechanism to separate the different sessions is left up to the concrete protocol definition. It must provide a clear mapping of protocol messages to open sessions. So requirement 2.1.2 is met 💖
5.1.3. Multiple Agents Connect to same Middlebox 👯
As specified in section 2.2, the MIDCOM protocol lets the middlebox talk to more than one agent at the same time. Picking a mechanism to separate the different sessions is left up to the concrete protocol definition. It must provide a clear mapping of protocol messages to open sessions. So requirement 2.1.3 is met 🌷
5.1.4. Deterministic Behavior 🔮
Section 2.1.2 says that the processing of an agent's request may not be interrupted by any request from the same or another agent. This gives atomicity among request transactions and avoids race conditions that would cause unpredictable behavior by the middlebox 🧠
The middlebox's behavior can only be predictable from its administrator's point of view. From an agent's point of view, the middlebox behavior is unpredictable, since the administrator can, for example, change the agent's authorization at any time without the agent being able to see that change 👀 So the middlebox's behavior isn't necessarily deterministic from the point of view of any agent.
Since the middlebox's behavior is predictable for its administrator, requirement 2.1.4 is met 🎉
5.1.5. Known and Stable State ✨
Okay so Section 2.1 says request transactions are atomic with respect to each other and from the point of view of an agent 🫶. Every transaction is clearly defined as a state transition that either leaves the current stable, well-defined state and enters a new stable, well-defined one, or stays in the current stable, well-defined state. Section 2.1 also clearly demands that intermediate states are not stable and are not reported to any agent 🙈.
Furthermore, for each state transition a message is sent to the corresponding agent, either a reply or a notification. The agent can uniquely map each reply to one of the requests it sent to the middlebox, because agent-unique request identifiers are used for this purpose 🔥. Notifications are self-explanatory by their definition 💅.
Furthermore, the Group List transaction (section 2.4.3), the Group Status transaction (section 2.4.4), the Policy Rule List transaction (section 2.3.11), and the Policy Rule Status transaction (section 2.3.12) let the agent check in at any time during a session to retrieve information about:
- all policy rule groups it may access,
- the status and member policy rules of all accessible groups,
- all policy rules it may access, and
- the status of all accessible policy rules.
So the agent is precisely informed about the state of the middlebox (as far as the services requested by the agent are affected), and requirement 2.1.5 is met 👑✨
5.1.6. Status Report 📣
As argued in the previous section, the middlebox unambiguously informs the agent about every state transition related to any of the services requested by the agent 💖. Also, at any time the agent can retrieve full status information about all accessible policy rules and policy rule groups. Thus, requirement 2.1.6 is met 🎀
5.1.7. Unsolicited Messages (Asynchronous Notifications) 🔔
The semantics includes asynchronous notification messages from the middlebox to the agent, including the Session Termination Notification message, the Policy Rule Event Notification (REN) message, and the Group Event Notification (GEN) message (see section 2.1.2). These notifications report every change of state of policy rules or policy rule groups that was not explicitly requested by the agent. Thus, requirement 2.1.7 is met by the semantics specified above 🦋
5.1.8. Mutual Authentication 🤝
As specified in section 2.2.1, the semantics requires mutual authentication of agent and middlebox, by using either two subsequent Session Establishment transactions or mutual authentication provided on a lower protocol layer. Thus, requirement 2.1.8 is met 🔐💜
5.1.9. Session Termination by Any Party 🚪
The semantics specification states in section 2.2.2 that the agent may request session termination by generating the Session Termination request, and that the middlebox may not reject this request. In turn, section 2.2.3 states that the middlebox may send the Asynchronous Session Termination notification at any time and then terminate the session. Thus, requirement 2.1.9 is met ✨
5.1.10. Request Result 🧾
Section 2.1 states that each request of an agent is followed by a reply of the middlebox indicating either success or failure. Thus, requirement 2.2.10 is met 🍓
5.1.11. Version Interworking 🌈
Section 2.2.1 states that the agent needs to specify the protocol version number that it will use during the session. The middlebox may accept this and act according to this protocol version, or it may reject the session if it does not support this version. If the session setup is rejected, the agent may try again with another version. Thus, requirement 2.2.11 is met 🧚
5.1.12. Deterministic Handling of Overlapping Rules 🎯
The only policy rule actions specified are 'reserve' and 'enable'. For firewalls, overlapping enable actions or reserve actions do not create any conflict, so a firewall will always accept overlapping rules as specified in section 2.3.2 (assuming the required authorization is given) 🔥.
For NATs, reserve and enable may conflict. If a conflicting request arrives, it is rejected, as stated in section 2.3.2. If an overlapping request arrives that does not conflict with those it overlaps, it is accepted (assuming the required authorization is given) 💅.
Therefore, the behavior of the middlebox in the presence of overlapping rules can be predicted deterministically, and requirement 2.1.12 is met 👑
5.2. Protocol Semantics Requirements 🧠
5.2.1. Extensible Syntax and Semantics 🌸
Requirement 2.2.1 explicitly requests extensibility of protocol syntax. This needs to be addressed by the concrete protocol definition. The semantics specification is extensible anyway, because new transactions may be added 🦋
5.2.2. Policy Rules for Different Types of Middleboxes 🧩
Section 2.3 explains that the semantics uses identical transactions for all middlebox types, and that the same policy rule can be applied to all of them. Thus, requirement 2.2.2 is met 💖
5.2.3. Ruleset Groups 📁
The semantics explicitly supports grouping of policy rules and transactions on policy rule groups, as described in section 2.4. The group transactions can be used for lifetime extension and termination of all policy rules that are members of the particular group. Thus, requirement 2.2.3 is met ✨
5.2.4. Policy Rule Lifetime Extension ⏳
The semantics includes a transaction for explicit lifetime extension of policy rules, as described in section 2.3.3. Thus, requirement 2.2.4 is met 🎀
5.2.5. Robust Failure Modes 🛡️
The state transitions at the middlebox are clearly specified and communicated to the agent. There is no intermediate state reached by a partial processing of a request. All requests are always processed completely, either successfully or unsuccessfully. All request transactions include a list of failure reasons. These failure reasons cover indication of invalid parameters where applicable. In case of failure, one of the specified reasons is returned from the middlebox to the agent. Thus, requirement 2.2.5 is met 💪
5.2.6. Failure Reasons 🙋
The semantics includes a failure reason parameter in each failure reply. Thus, requirement 2.2.6 is met 🫶
5.2.7. Multiple Agents Manipulating Same Policy Rule 👯
As specified in sections 2.3 and 2.4, each installed policy rule and policy rule group has an owner, which is the authenticated agent that created the policy rule or group, respectively. The authenticated identity is input to authorize access to policy rules and groups.
If the middlebox is sufficiently configurable, its administrator can configure it so that one authenticated agent is authorized to access and modify policy rules and groups owned by another agent. Because the specified semantics does not preclude this, it meets requirement 2.2.7 💜
5.2.8. Carrying Filtering Rules 🧺
The Policy Enable Rule transaction specified in section 2.3.8 can carry 5-tuple filtering rules. This meets requirement 2.2.8 🔥
5.2.9. Parity of Port Numbers ⚖️
As specified in section 2.3.6, the agent is able to request keeping the port parity when reserving port numbers with the PRR transaction (see section 2.3.8), and when establishing address bindings with the PER transaction (see section 2.3.9). Thus, requirement 2.2.9 is met 🌈
5.2.10. Consecutive Range of Port Numbers 🔢
As specified in section 2.3.6, the agent is able to request a consecutive range of port numbers when reserving port numbers with the PRR transaction (see section 2.3.8), and when establishing address bindings or pinholes with the PER transaction (see section 2.3.9). Thus, requirement 2.2.10 is met 🍭
5.2.11. Contradicting Overlapping Policy Rules 🙅♀️
Requirement 2.2.11 is based on the assumption that contradictory policy rule actions, such as 'enable'/'allow' and 'disable'/'disallows', are supported. In conformance with decisions made by the working group after finalizing the requirements document, this requirement is not met by the semantics, because no 'disable'/'disallow' action is supported 😭
5.3. Security Requirements 🔐
5.3.1. Authentication, Confidentiality, Integrity 🛡️💜
The semantics definition supports mutual authentication of agent and middlebox in the Session Establishment transaction (section 2.2.1). The use of an underlying protocol such as TLS or IPsec is mandatory. Thus, requirement 2.3.1 is met 🔒
5.3.2. Optional Confidentiality of Control Messages 🤫
The use of IPsec or TLS allows agent and middlebox to use an encryption method (including no encryption). Thus, requirement 2.3.2 is met 🦋
5.3.3. Operation across Untrusted Domains 🌍
Operation across untrusted domains is supported by mutual authentication and by the use of TLS or IPsec protection. Thus, requirement 2.3.3 is met 💅
5.3.4. Mitigate Replay Attacks 🔁
The specified semantics mitigates replay attacks and meets requirement 2.3.4 by requiring mutual authentication of agent and middlebox, and by mandating the use of TLS or IPsec protection.
Further mitigation can be provided as part of a concrete MIDCOM protocol definition -- for example, by requiring consecutively increasing numbers for request identifiers 🌟
6. Security Considerations 🔐✨
okay so this is the spicy section bestie 😭 The way a middlebox talks to an agent (see [MDC-FRM]) is literally the most sensitive spot for security. Like, it kind of feels contradictory that a policy rule can get configured from somewhere outside the middlebox, because that's not really what a middlebox is supposed to be 💀 So we have to use effective means to make sure of all of these:
- mutual authentication between agent and middlebox,
- authorization,
- message integrity, and
- message confidentiality.
The semantics has a mechanism for mutual authentication between agent and middlebox (see section 2.2.1) 🫶 With that authentication in place, the middlebox can decide whether a given agent is authorized to request an action from it. For integrity and confidentiality of the data moving between the two, the semantics leans on underlying protocols like TLS or IPsec. Main character energy from those protocols ngl 💅
For the TLS and IPsec use, both sides must use securely configured credentials for authentication and authorization 🔑
Now the wildcard drama 👀 Configuring policy rules with wildcarded IP addresses and port numbers comes with real risks, like ending up with overly wildcarded policy rules. An excessively wildcarded rule would be A0 and A3 with the IP address set to 'any', for instance. Honestly that kind of pinhole makes the middlebox useless from a security point of view, because any packet could waltz right through without any further checking 🙈 The local policy of the middlebox should reject those policy rule enable requests.
A reasonable default for wildcarding is that only one port number may be wildcarded, and all IP addresses must be set without wildcarding ✨ That said, sometimes security has to be balanced with functionality, so it's not always a perfect world.
The example in section 4.2 shows how SIP-signaled calls can be served securely without wildcarding IP addresses 🎀 But some SIP-signaled applications use early media (see section 5.5 of [RFC3398]). To receive early media, the middleboxes need to be configured before the second participant in a session is known. Since that participant isn't known yet, the IP address of the second participant has to be wildcarded 🥺
In cases like this, and in a few similar ones, the middlebox operator gets to make a security policy decision 👑 The operator can configure the middlebox to support more functionality, for example by allowing wildcarded IP addresses, or to make network operation more secure, for example by disallowing wildcarded IP addresses. It's a vibe check for the operator, honestly 💜
7. IAB Considerations on UNSAF 🦋
okay so UNSAF stands for UNilateral Self-Address Fixing 🌸 [RFC3424] describes it as a process where originating endpoints try to figure out or fix the address (and port) they're known by to another endpoint. UNSAF proposals, like STUN [RFC3489], are treated as a general class of workarounds for NAT traversal, and as solutions for scenarios with no middlebox communication (MIDCOM).
This document describes the protocol semantics for that middlebox communication (MIDCOM) solution 🧚 MIDCOM is not meant to be a short-term workaround. It's more of a long-term solution for middlebox communication. In MIDCOM, endpoints aren't involved in allocating, maintaining, and deleting addresses and ports at the middlebox. Instead, full control of addresses and ports at the middlebox lives with the MIDCOM server 💅
So this document addresses the UNSAF considerations from [RFC3424] by proposing a long-term alternative solution ✨ Iconic behavior, no notes.
8. Acknowledgements 🫶
We would like to thank everyone who contributed to the semantics discussion on the mailing list for their lots of valuable comments 💖
9. References 📚
9.1. Normative References
[MDC-FRM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
and A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
[MDC-REQ] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
"Middlebox Communications (midcom) Protocol
Requirements", RFC 3304, August 2002.
[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.9.2. Informative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC3198] 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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong,
"Integrated Services Digital Network (ISDN) User Part
(ISUP) to Session Initiation Protocol (SIP) Mapping", RFC
3398, December 2002.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.Authors' Addresses 🎀
Martin Stiemerling
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511-13
EMail: stiemerling@netlab.nec.de
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511-15
EMail: quittek@netlab.nec.de
Tom Taylor
Nortel
1852 Lorraine Ave.
Ottawa, Ontario
Canada K1H 6Z8
Phone: +1 613 763 1496
EMail: taylor@nortel.comFull Copyright Statement ©️
Copyright (C) The Internet Society (2005) 🌈
This document is subject to the rights, licenses and restrictions in BCP 78. Except as set out there, the authors keep all their rights.
The document and the info in it are provided on an "AS IS" basis, and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim every warranty, express or implied. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. Legally speaking it's a lot, but the vibe is: no guarantees, no cap 💀
Intellectual Property 💜
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to implementing or using the technology in this document. It also doesn't say whether a license under those rights is or isn't available, and it hasn't independently tried to identify any such rights. Info about the IETF's procedures for rights in IETF Documents can be found in BCP 78 and BCP 79 🔥
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users of this specification can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 🫶
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society ✨
📦 where this page comes from
- ietf: rfc3989 2005-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms