RFC 5189
Middlebox Communication (MIDCOM) Protocol Semantics
RFC 5189: Middlebox Communication (MIDCOM) Protocol Semantics 🦋
Okay bestie, let's get into it! 💖 This is RFC 5189, and it's giving standards-track main character energy 👑
- Network Working Group 🌸
- Number: RFC 5189
- Title: Middlebox Communication (MIDCOM) Protocol Semantics
- Authors: M. Stiemerling (NEC), J. Quittek (NEC), T. Taylor (Nortel)
- Category: Standards Track ✨
- Date: March 2008 🗓️
- Obsoletes: RFC 3989 💀
Status of This Memo 📜
So this document is an Internet standards track protocol spec for the whole Internet community, and it literally asks people to talk about it and suggest improvements 🫶 Check the current edition of "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. And the distribution of this memo is unlimited, so share it with everyone 🌈
Abstract 🦋
Okay so this doc 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) 🔥 Now, the semantics bit doesn't pin down a concrete syntax or a transport protocol, so it's not the full recipe. But a real protocol is expected to implement these semantics or, more likely, a superset of them 💜 The MIDCOM protocol semantics come from the MIDCOM requirements, the MIDCOM framework, and working group decisions. And yes, this document obsoletes RFC 3989 💅
Table of Contents 🧚
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Transaction Definition Template ............................7
2. Semantics Specification .........................................8
2.1. General Protocol Design ....................................8
2.1.1. Protocol Transactions ...............................8
2.1.2. Message Types .......................................9
2.1.3. Session, Policy Rule, and Policy Rule Group ........10
2.1.4. Atomicity ..........................................11
2.1.5. Access Control .....................................11
2.1.6. Middlebox Capabilities .............................12
2.1.7. Agent and Middlebox Identifiers ....................12
2.1.8. Conformance ........................................13
2.2. Session Control Transactions ..............................13
2.2.1. Session Establishment (SE) .........................14
2.2.2. Session Termination (ST) ...........................16
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) ..........................25
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 ...................61
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 ...........................62
5.2.1. Extensible Syntax and Semantics ....................62
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 ......63
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 .....................................64
5.3.1. Authentication, Confidentiality, Integrity .........64
5.3.2. Optional Confidentiality of Control Messages .......64
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. Acknowledgements ...............................................66
9. References .....................................................67
9.1. Normative References ......................................67
9.2. Informative References ....................................67
Appendix A. Changes from RFC 3989 .................................691. Introduction 💖
So the MIDCOM working group already came up with a framework [MDC-FRM] and a list of requirements [MDC-REQ] for middlebox communication 🎀 The next step toward an actual MIDCOM protocol is writing down protocol semantics. These are constrained by those two docs, but not completely spelled out by them, so there's some room to decide things 🧚
This memo proposes semantics for the MIDCOM protocol, and it's fully compliant with the requirements in [MDC-REQ] and with the working group's consensus on semantic issues ✨ This document obsoletes RFC 3989 [MDC-SEM], so if you're still on that one, it's time to upgrade bestie 💅
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 in terms of transactions. There are two basic types: request transactions and asynchronous transactions. Then there are two concrete kinds of request transactions: configuration transactions and monitoring transactions 🦋
For each transaction, the semantics are specified by describing: (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; and (4) the reply and notification messages the middlebox sends to the agent to tell it about the state change 📬 It's giving very organized, very intentional 💜
The semantics can be implemented by any protocol that supports these two transaction types and is flexible enough about transaction parameters 🫶 Different protocols might need to extend the semantics below. They might add more transactions, add more parameters to transactions, or split a single transaction into a set of transactions ⭐ No matter what extensions get added, the semantics below give the minimum necessary subset of what must be implemented 🍓
Here's how the rest of this doc is laid out 🗺️ Section 2 describes the protocol semantics, and it's split into four subsections:
- General Protocol Design (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 MIDCOM protocol implementations, with respect to the semantics defined in section 2 🌸 Section 4 gives two elaborated usage examples 🧚 And finally, section 5 explains how the semantics meet the MIDCOM requirements 👑 Let's keep going!! 💅✨
1.1. Terminology 🎀
Okay so this memo borrows its definitions from the framework [MDC-FRM] and requirements [MDC-REQ] docs, which is very neat of it 💅. On top of that, there are a few extra terms you need to know:
- request transaction 🦋: a request transaction is a whole little journey. The agent sends a request message to the middlebox, the middlebox processes it, a reply message comes back from the middlebox to the agent, and optionally, notification messages get sent from the middlebox to agents other than the one who asked. A request transaction might cause a state transition at the middlebox.
- configuration transaction 🛠️: this is a request transaction that asks for a state change in the middlebox. If it's accepted, it causes a state change at the middlebox.
- monitoring transaction 👀: this is a request transaction that asks for state information from the middlebox. It does not cause a state transition at the middlebox.
- asynchronous transaction ⚡: this one isn't triggered by an agent at all. It can happen without any agent taking part in a session with the middlebox. Potentially, it includes notification messages going from the middlebox to agents that are in an open session. A notification message gets sent to each agent that needs to hear about the asynchronous event, and the message shows the state transition at the middlebox.
- agent-unique 🧩: an agent-unique value is unique within the agent's context, and that context covers all the MIDCOM sessions the agent is part of. The agent is the one who assigns it.
- middlebox-unique 🧩: a middlebox-unique value is unique within the middlebox's context, which covers all the MIDCOM sessions the middlebox is part of. The middlebox is the one who assigns it.
- policy rule 📜: in general, 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" [RFC3198]. In the MIDCOM world, the condition is a specification of a set of packets that the rules get applied to. Each rule's set of actions always has just one element, and that element is either action "reserve" or action "enable".
- policy reserve rule 🌷: a policy rule with a reserve action. Its policy condition is always true. The action reserves either just an IP address, or an IP address plus a range of port numbers, 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 policy condition is a descriptor of one or more unidirectional or bidirectional packet flows, and the policy action lets packets belonging to that flow traverse the middlebox. The descriptor identifies the protocol, the flow direction, and the source and destination addresses, optionally with a range of port numbers.
- NAT binding 🌉: okay, this one's a bit sneaky 🙈. The term NAT binding as used in this document does not necessarily mean a NAT bind as defined in [NAT-TERM]. In MIDCOM semantics, a NAT binding is an abstraction that lets two endpoints communicate through the NAT-type middlebox. An enable action may result in a NAT bind or a NAT session, depending on the request and its parameters.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 🫶
1.2. Transaction Definition Template 🌸
Here's the deal: the semantics of the MIDCOM protocol get specified per transaction, section by section. Each transaction specification has the entries below. Parameter entries, failure reason, and notification message type only show up if they actually apply 💖.
transaction-name: a descriptive name for this type of transaction.transaction-type: the transaction type is either 'configuration', 'monitoring', or 'asynchronous'. See section 1.1 for what each transaction type means.transaction-compliance: this entry says either 'mandatory' or 'optional'. For the details, see section 2.1.8.request-parameters: this entry lists every parameter needed for the request, with a description of each one.reply-parameters (success): this entry lists all the parameters that get sent back from the middlebox to the agent as a positive response to the earlier request, with a description of each one.failure reason: every negative reply has two parameters: a request identifier that says which request the reply is for, and a parameter that gives the failure reason. These two are compulsory, so the template doesn't list them. What the template does have is a list of possible failure reasons the second parameter might show. That list is not exhaustive, and a concrete protocol specification may extend it ✨.notification message type: this entry describes the notification message type that the transaction may use.semantics: this entry describes what the transaction actually means. In particular, it covers how the middlebox processes the request message, and which middlebox state transitions the transaction causes or is caused by.
2. Semantics Specification 💅
2.1. General Protocol Design 🎀
The semantics specification is all about finding a balance 🧠. It wants to properly support applications that need dynamic configuration of middleboxes, and it also wants the protocol to stay simple to specify and implement.
Protocol interactions are organised into transactions. The state of a middlebox is described by state machines, and those state machines are made of states and state transitions. One transaction may cause, or be caused by, state transitions in more than one state machine. But for each state machine, there is no more than one transition per transaction 🦋.
2.1.1. Protocol Transactions ✨
State transitions get kicked off in one of two ways: either by a request message from the agent to the middlebox, or by some other event at the middlebox. In the first case, the middlebox tells the agent about the state transition by sending a reply message. In the second case, the middlebox sends an unsolicited asynchronous notification message to each agent affected by the transaction, as long as that agent is taking part in an open session with the middlebox 📨.
Request and reply messages both carry an agent-unique request identifier. That's how the agent figures out which sent request a received reply belongs to 🔍.
An analysis of the requirements showed that three kinds of transactions are required:
- Configuration transactions, which let the agent request state transitions at the middlebox 🛠️.
- Asynchronous transactions, which let the middlebox report state changes that the agent did not ask for ⚡.
- Monitoring transactions, which let the agent request state information from the middlebox 👀.
Configuration transactions and asynchronous transactions provide the basic MIDCOM protocol functionality 🌈. They're tied to middlebox state transitions, and they cover setting up and tearing down MIDCOM sessions and policy rules.
Monitoring transactions aren't tied to middlebox state transitions at all. Agents use them to look at the number, status, and properties of the policy rules that have been set up at the middlebox 🔭.
As specified in detail in section 3, configuration transactions and asynchronous transactions are mandatory except of the Group Lifetime Change (GLC). They must be implemented by a compliant middlebox 🧚. The GLC transaction and some of the monitoring transactions are optional 💜.
2.1.2. Message Types
okay so MIDCOM has three flavours of message: requests, replies, and notifications 🦋 and each flavour comes in different types. the semantics doc only pins a message type down by its list of parameters. the order of those params and how they're encoded is up to whatever concrete protocol gets written later 💅 a protocol is also allowed to tack on extra params or mash several together, as long as all the info from the semantics is still in there somewhere ✨
for requests and positive replies, you get one message type per request transaction. each reply transaction defines its parameter list (for the request and the successful reply) using the transaction definition template from section 1.2 🎀
if a request fails, the middlebox sends a negative reply back to the agent 🥺 it's the same for every request transaction: it carries the request identifier so the agent knows which request it's answering, plus a parameter saying why it failed 💀
there are three notification types: the Session Termination Notification (STN), the Policy Rule Event Notification (REN), and the Group Event Notification (GEN). every one of them carries a middlebox-unique notification identifier 🌸
STN the Session Termination Notification has that identifier plus one parameter giving the reason the middlebox ended the session 🧚
REN the Policy Rule Event Notification has the notification identifier, a policy rule identifier, and the remaining policy lifetime 💜
GEN the Group Event Notification has 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 sort into three buckets: ones about sessions, ones about policy rules, and ones about policy rule groups 🌈 rule groups are handy for showing how rules relate to each other, and for simplifying things because you can do one transaction per group instead of one per rule 🍓
sessions and policy rules are stateful at the middlebox 😭 their states don't depend on each other, so their state machines (one per session, one per policy rule) can be kept separate 🦋 rule groups are stateful too, but the middlebox doesn't have to store any state for them, since the group's state is implicitly defined by the states of all the rules in it (see section 2.4) ✨
splitting session state from policy rule state keeps the semantics spec simple and makes implementation easier too, so that's how it's structured, with two separate state machines to illustrate things 💖 real protocol state machines will probably be more complex than the ones here, but they're 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 🔥 that means the middlebox never interrupts processing of one request to handle another request that's arriving or already queued 😤 this holds even when requests come in from different sessions at the same time 👑 asynchronous transactions are the exception, though: they 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 🎀 the middlebox doesn't start processing a request until the whole request has arrived 🫶 no intermediate state is stable at the middlebox, and no intermediate state gets reported to any agent 🙈
the number of transactions in this document is pretty small, because we cut it down to a minimal set that still meets the requirements 🌸 a real implementation might need to split some of the transactions below into two or more transactions of the protocol, for reasons like protocol constraints or wanting more flexibility 🧚 that's generally fine, but keep in mind it 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 rule is created, it gets a middlebox-unique identifier for use in later transactions 🪪 on top of that, every rule has an owner, which is the authenticated agent that set it up 👑 the middlebox uses the owner attribute to control access: whenever an authenticated agent wants to modify an existing rule, the middlebox checks who owns it and whether the requesting agent is allowed to act on that owning agent's rules 💅
all rules in the same rule group must have the same owner 🫶 so an agent either has access to every member of a group or to none of them 🦋
the middlebox can be configured to let specific authenticated agents access and modify rules with certain owners 🌈 a sensible default is letting each agent access its own rules 💖 it might also be nice to set up an agent identity as an administrator that can modify all rules owned by any agent 👑 configuring authorization at the middlebox, though, is outside the scope of the MIDCOM semantics and protocol 🙈
2.1.6. Middlebox Capabilities
at session setup it's really useful for the agent to learn what the middlebox can do 🧚 so the session establishment procedure in section 2.2.1 includes sending capability info from the middlebox to the agent ✨ the capabilities covered are:
- 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
- Support for interface-specific policy rules
- 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, "Asynchronous Policy Rule Event (ARE)").
- Maximum number of simultaneous MIDCOM sessions
a concrete protocol spec can extend this list with more info that's useful for the agent 🎀
2.1.7. Agent and Middlebox Identifiers
so that agents and middleboxes can each keep multiple sessions going, every request message carries a parameter identifying the requesting agent, and every reply and notification message carries a parameter identifying the middlebox 🦋 these aren't listed in each transaction's description because they're shared by all of them, and the individual semantics descriptions don't reference them 🌸 they aren't necessarily passed explicitly as MIDCOM parameters, since the underlying (secure) transport protocol might provide them 🧚 agent identifiers are middlebox-unique at the middlebox, and middlebox identifiers are agent-unique at the agent ✨
2.1.8. Conformance
the MIDCOM requirements in [MDC-REQ] call for protocol capabilities that the transactions below are designed to meet 💖 that doesn't mean every middlebox has to support all of these transactions 🙈 the set of supported transactions it announces can differ between authenticated agents 🫶 during the capability exchange at session establishment, the middlebox tells the agent which transactions that agent is authorized to perform 💅 some transactions have to be offered to every authenticated agent 🔥
each transaction definition below has a conformance entry saying either 'mandatory' or 'optional' 🌈 a mandatory transaction needs to be implemented by every middlebox offering MIDCOM service, and it must be offered to each of the authenticated agents 💜 an optional transaction doesn't necessarily need to be implemented by a middlebox, and the middlebox may offer it only to certain authenticated agents 🦋 a middlebox may offer one, several, all, or none of the optional transactions to agents 🍓 whether an agent may use an optional request transaction is decided by the middlebox's authorization procedure, which this document doesn't specify 🧚
2.2. Session Control Transactions
a valid MIDCOM session has to be established before any transaction on policy rules or policy rule groups is possible 🔑 a MIDCOM session is an authenticated and authorized association between an agent and a middlebox 🫶 agents start sessions, and either the agent or the middlebox can end them 💅 both agents and middleboxes can take part in several sessions (with different entities) at the same time 👑 to tell sessions apart, each party uses local session identifiers 🪪
all transactions are carried within a MIDCOM session 🌸
session control has three transactions ✨
- Session Establishment (SE)
- Session Termination (ST)
- Asynchronous Session Termination (AST)
the first two are configuration transactions the agent starts, and the last one is an asynchronous transaction the middlebox starts 🦋
2.2.1. Session Establishment (SE) 💖
okay so this is the transaction that opens a MIDCOM session 🦋
transaction-name:session establishmenttransaction-type:configurationtransaction-compliance:mandatory
request-parameters (what the agent sends 📨):
request identifier: a little ID that's unique to the agent 🪪, so it can match each request with its reply.version: the version of the MIDCOM protocol 🎀middlebox challenge (mc): an authentication challenge token that checks the middlebox is legit 🔐. It's only in the first iteration of the request, see below.agent authentication (aa): a token that proves the agent is legit to the middlebox 🫶. It gets updated in the second iteration of the request with the answer to the middlebox challenge.
reply-parameters (success) (what the middlebox sends back ✨):
request identifier: matches the identifier of the requestmiddlebox authentication (ma): proves the middlebox is legit to the agent 💅agent challenge (ac): an authentication challenge token for the agent's authenticationmiddlebox capabilities: a list describing what the middlebox can do. See section 2.1.6 for the full list 🧚
failure reason (the sad girl list 💀):
authentication failedno authorizationprotocol version of agent and middlebox do not matchlack of resources
semantics 🌈
So this SE transaction is how a MIDCOM session gets established. For mutual authentication (both sides checking each other, which is the main character move 👑), two SE transactions back to back are required, as shown in Figure 1:
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 MiddleboxSession establishment can be simplified to a single transaction 🍓. In that case, the server challenge and agent challenge are omitted by the sender or ignored by the receiver. Authentication must be provided by other means instead, for example by Transport Layer Security (TLS) [RFC4346] or IPsec [RFC4302][RFC4303]. Literally a whole different vibe 🙈
The middlebox checks with its policy decision point whether the requesting agent is authorized to open a MIDCOM session. If it's not, the middlebox sends a negative reply with 'no authorization' as the failure reason 💀. If authentication and authorization both work out, the session is established ✨, and the agent may start requesting transactions on policy rules and policy rule groups 🦋.
Part of the successful reply is an indication of the middlebox's capabilities. Iconic 💜
2.2.2. Session Termination (ST) 🌸
transaction-name:session terminationtransaction-type:configurationtransaction-compliance:mandatory
request-parameters:
request identifier: an agent-unique identifier for matching the corresponding request and reply at the agent 🪪
reply-parameters (success only):
request identifier: matches the identifier of the request
semantics 🥀
This transaction is used to close the MIDCOM session on behalf of the agent 👋. After session termination, the middlebox keeps all established policy rules until their lifetime expires, or until an event occurs that causes the middlebox to terminate them 🎀.
The middlebox always generates a successful reply 💖. After sending that reply, the middlebox won't send any more messages to the agent within the current session. It also won't process any further requests within this session, whether it got them while handling the session termination request or gets them later. Bye bye, no more chat 🫠
2.2.3. Asynchronous Session Termination (AST) 🔔
transaction-name:asynchronous session terminationtransaction-type:asynchronoustransaction-compliance:mandatorynotification message type:Session Termination Notification (STN)
reply-parameters (success only):
termination reason: the reason why the session is terminated
semantics 💅
The middlebox may decide to terminate a MIDCOM session at any time 😭. Before it actually terminates the session, the middlebox generates an STN message and sends it to the agent. After sending the notification, the middlebox won't process any further requests from the agent, even if they're already queued up at the middlebox 🙅♀️.
Same as before, after session termination the middlebox keeps all established policy rules until their lifetime expires, or until an event occurs for which the middlebox terminates them 🌈.
Unlike in other asynchronous transactions, only one notification gets sent, since there's only one agent affected by the transaction. Solo queen energy 👑
2.2.4. Session Termination by Interruption of Connection 🔌
If a MIDCOM session is based on an underlying network connection, the session can also end when that connection gets interrupted 💔. If the middlebox detects this, it terminates the session immediately ⚡. The effect on established policy rules is the same as for the Asynchronous Session Termination 🦋.
2.2.5. Session State Machine 🧠
There's a state machine that shows how the session transactions work together, see Figure 2 ✨. The transaction abbreviations are explained in the headings of each transaction section 🎀.
All sessions start in state CLOSED 🌸. If mutual authentication is already provided by other means, 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 you back to CLOSED 😭, and a successful SE transaction moves you to OPEN 💖.
At any time, an AST transaction or a connection failure can happen, which moves you back to CLOSED 🥀. A successful ST transaction from either NOAUTH or OPEN also returns you to CLOSED 👋. The parameters of the transactions are explained in Figure 2. The value mc=0 represents 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 explains the semantics of transactions on policy rules 💜. The following transactions are specified:
- 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 transactions (PRR, PER, RLC) are configuration transactions initiated by the agent 🛠️. The fourth and fifth (PRL, PRS) are monitoring transactions 👁️. The last one (ARE) is an asynchronous transaction 🌊. The PRL and PRS transactions don't have any effect on the policy rule state machine, so they're giving observe-only 🙈
Before any transaction can start, a valid MIDCOM session must be established first 🔐.
2.3.1. Configuration Transactions 🛠️
Policy rule transactions PER and RLC are the core of the MIDCOM protocol 👑. Both are mandatory, and they serve for:
- configuring NAT bindings (PER) 🌉
- configuring firewall pinholes (PER) 🕳️
- extending the lifetime of established policy rules (RLC) ⏳
- deleting policy rules (RLC) 🗑️
Some cases require knowing in advance which IP address (and port number) NAT would pick in a PER transaction. That info is required before there's enough to finish a complete PER transaction (see the example in section 4.2 🧩). To support those cases, the core transactions get extended by the Policy Reserve Rule (PRR) transaction, which serves for:
- reserving addresses and port numbers at NATs (PRR) 🌸
2.3.2. Establishing Policy Rules 🦋
Both PRR and PER establish a policy rule 💖. The action within the rule is 'reserve' if it's set by PRR, and 'enable' if it's set by PER ✨.
The Policy Reserve Rule (PRR) transaction is used to set up an address reservation on neither side, one side, or both sides of the middlebox, depending on the middlebox configuration 🎀. The transaction returns the reserved IP addresses, plus the optional ranges of port numbers, to the agent. No address binding or pinhole configuration happens at the middlebox, so packet processing at the middlebox stays unchanged 🫶.
On pure firewalls 🧱, the PRR transaction is successfully processed without any reservation. But the state transition of the MIDCOM protocol engine is exactly the same as on NATs, which is lowkey wild 🤯.
On a traditional NAT (see [NAT-TRAD]), only an external address gets reserved. On a twice-NAT, an internal and an external address both get reserved 🌈. The reservation at a NAT covers required resources, such as IP addresses and port numbers, held for future use 🍓. How the reservation is done depends on the NAT's implementation 🛠️. In both cases, the reservation is either an IP address on its own, or an IP address combined with a range of port numbers 💜.
The Policy Enable Rule (PER) transaction is used to establish 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 create a new rule from scratch 🧚.
On a NAT, the enable action is interpreted as a bind action, which sets up bindings between internal and external addresses 🌉. At a firewall, the enable action is interpreted as one or more allow actions that configure pinholes 🕳️. The number of allow actions depends on the parameters of the request and on the firewall's implementation 💅.
On a combined NAT/firewall, the enable action is interpreted as a combination of bind and allow actions 👑.
The PRR transaction and the PER transaction 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 so every policy rule gets its own middlebox-unique identifier 🆔✨ Nobody else at that middlebox gets the same one, bestie.
Every rule also has an owner 👑 Access control is based on ownership, so who can touch a rule depends on who owns it (see section 2.1.5) 🔐 And the owner never changes for the whole life of the rule. Iconic loyalty 💅
Each rule has its own lifetime ⏳ When that lifetime runs out, the rule gets terminated at the middlebox. Usually the middlebox says "bye" to a rule with an ARE transaction 👋 A Policy Rule Lifetime Change (RLC) transaction can stretch a rule's lifetime, but only up to the limit the middlebox set at session setup 🙅♀️ An RLC can also shorten a rule's lifetime, or delete the rule outright by asking for a lifetime of zero 🗑️ (Also, rule lifetimes can get changed by the Group Lifetime Change (GLC) transaction too, so keep that in mind 🧠)
Every policy rule belongs to exactly one policy rule group 🧚 That membership doesn't change while the rule is alive. Picking the group happens as part of the transaction that creates the rule 🛠️ If the agent doesn't name a group, that same transaction makes a brand new one, and the middlebox picks its identifier 🆕 If the agent does name a group, the new rule just joins that existing group 🫶 A group only exists while it still has member rules. Once every policy in the group has reached the end of its lifetime, the group is gone 🌅
Agents can look at 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 🔔
So when a policy rule changes its state, or its remaining lifetime changes in some way other than just ticking down with time, every agent that can access that rule and has an open session with the middlebox gets told 📣 If the agent asked for the change explicitly in a request message, the middlebox answers that agent with the matching reply 💌 Everyone else who can access the policy gets a Policy Rule Event Notification (REN) message instead 🔔
Here's the tea ☕ A middlebox can serve several agents at once, each in its own parallel session. The sets of policy rules those agents can access might overlap 🫂 For example, there could be an agent who authenticates as an administrator and can access every policy of every agent 👑 Or there could be a backup agent running alongside a main agent, authenticating as the same entity as the main agent 🧑🤝🧑
For a PER, PRR, or RLC transaction, the requesting agent gets back a PER, PRR, or RLC reply, respectively 📬 Every other agent that can access the created, modified, or terminated rule (and has an open session with the middlebox) gets a REN message carrying the policy rule identifier (PID) and the rule's remaining lifetime 🆔⏳
If a rule gets terminated because its lifetime got truncated, or because of some other event that no agent started, the middlebox sends a REN message to each agent that can access that rule and has an open session with the middlebox 🚨 This is what keeps every agent up to date on the latest state of all the rules it can access, which is honestly so important 🥹
2.3.5. Address Tuples 🌸
Request and reply messages for the PRR, PER, and PRS transactions carry 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
The request message of PER and the reply message of PRS also carry a direction of flow parameter 🧭 For UDP and IP, this parameter says which way packets travel through the middlebox. With 'inbound', UDP packets go from outside to inside. With 'outbound', they go from inside to outside. Either way, the packets can only cross the middlebox in one direction 🚪 If you want a bidirectional flow, you use 'bidirectional' as the direction of flow parameter 🔁
TCP is always bidirectional, but the direction of flow parameter still gets defined for it, like this 🧵
- inbound: bidirectional TCP packet flow. The first packet, with the TCP SYN flag set and the ACK flag not set, must arrive at the middlebox at the outside interface.
- outbound: bidirectional TCP packet flow. The first packet, with the TCP SYN flag set and the ACK flag not set, must arrive at the middlebox at the inside interface.
- bidirectional: bidirectional TCP packet flow. The first packet, with the TCP SYN flag set and the ACK flag not set, may arrive at the inside or outside interface.
We call this whole set of parameters an address tuple 🎀 An address tuple specifies either a communication endpoint at an internal or external device, or addresses the middlebox has allocated. This document distinguishes four kinds of address tuples, 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 the internal network, from the middlebox's point of view.
- 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 going from the internal endpoint to the middlebox, and the source for packets going 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 going from the external endpoint to the middlebox, and the source for packets going from the middlebox to the external endpoint.
- A3 - external endpoint: Address tuple A3 specifies a communication endpoint of a device within the external network, from the middlebox's point of view.
For a firewall, the inside and outside endpoints are identical to the corresponding external or internal endpoints, respectively 🧱 So the installed policy rule sets the same value in A2 as in A0 (A0=A2), and the same value in A1 as in A3 (A1=A3) 🪞
For a traditional NAT, A2 gets a value different from A0, but the NAT binds them together 🔗 Same as with the firewall, A1 has the same value as A3 in a traditional NAT 💜
For a twice-NAT, there are two bindings of address tuples, because 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 🦋
2.3.6. Address Parameter Constraints ✨
okay so, the address tuple parameters come with some rules that apply to basically every message that uses them 💅 instead of repeating them in every single transaction description, they're all summarized right here, so you don't need them again later 🎀
MIDCOM semantics in this doc cover IPv4 and IPv6 as network protocols, and TCP and UDP (running over IPv4 and IPv6) as transport protocols 🌸 Any other transport protocol, like Stream Control Transmission Protocol (SCTP), isn't defined in these semantics, but concrete protocol specs may support it 🦋
The IP version parameter has either the value 'IPv4' or 'IPv6' 💖 In a policy rule, the value of the IP version parameter must be the same for address tuples A0 and A1, and for A2 and A3 🫶
The value of the IP address parameter must conform with the specified IP version ✨
Wildcarding is allowed for the IP address of an address tuple 🧚 Whether it's allowed at all, or how wide the range can be, depends on the middlebox's local policy, so check section 6, "Security Considerations" too 🙈 Wildcarding is set with the IP address prefix length parameter. Like with any prefix length, this parameter says how many high-significance bits of the IP address are fixed, and the remaining low-significance bits get wildcarded 🌈
The transport protocol parameter can be 'TCP', 'UDP', or 'ANY' 🍓 If it's 'ANY', the middlebox only considers IP headers for packet handling, so the transport header isn't looked at at all 👀 The port number, port range, and port parity values don't matter when the protocol parameter is 'ANY' 💅 In a policy rule, the value of 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 names a specific UDP or TCP port number. Zero means port wildcarding for whatever protocol the transport protocol parameter names 💜 If the port number parameter is zero, the port range parameter doesn't matter at all 🙈 Depending on the transport protocol, this parameter might really be about ports, or it might be about an equivalent concept 🧚
The port parity parameter is used differently for Policy Reserve Rules (PRRs) and Policy Enable Rules (PERs), so pay attention here 👑 For a PRR, the value can be 'odd', 'even', or 'any'. It specifies 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 matching internal or external port numbers 🦋 In this context, the value is 'same' or 'any' ✨ If it's 'same', the parity of the port number of A0 must match the parity of the port number of A2, and the parity of the port number of A1 must match the parity of the port number of A3 💖 If the value is 'any', there are no constraints on the parity of any port number 🫶
The port range parameter specifies a run of consecutive port numbers. Its value is a positive integer 🌈 Just like the port number parameter, it defines a set of consecutive ports that starts at the port number parameter's value (the lowest port) and has as many elements as the port range parameter says. A value of 1 means a single 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 greater than one is basically the same as a set of policy rules P_1, P_2, ..., P_n, where n equals the port range value 🤯 Each of those rules has a port range of 1. Policy rule P_1 holds address tuples A0_1, A1_1, A2_1, and A3_1, and each one contains the first port number from the matching address tuple in P. Policy rule P_2 holds A0_2, A1_2, A2_2, and A3_2, each with the second port number, and so on 🎀
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 the interfaces the requested policy rule gets bound to 👑 Honestly, the middlebox is usually careful about this when it reserves or enables a policy rule, since it knows its whole configuration 🧠 For agents that do want to choose, the Policy Reserve Rule (PRR) and Policy Enable Rule (PER) transactions have optional parameters, 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, but only 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) 🌸 That's the vibe, bestie 💖
2.3.8. Policy Reserve Rule (PRR) ✨
Here's the PRR, the transaction where the agent basically says "hold these addresses and ports for me, bestie" 🎀 It's a configuration transaction and it's mandatory, so no skipping it 💅
transaction-name: policy reserve rule
transaction-type: configuration
transaction-compliance: mandatoryrequest-parameters 🌸
- request identifier: an agent-unique ID so the agent can match each reply to its request 🪪
- group identifier: the group this policy reserve rule should belong to. As indicated in section 2.3.3, if this value is not supplied, the middlebox assigns a new group for this policy reserve rule 🧚
- service: the NAT service the agent wants from the middlebox. Allowed values are
'traditional'or'twice'💖 - internal IP version: the IP version requested on 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): the interface on the inside of the middlebox; see section 2.3.7.
- external IP version: the IP version requested 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 requested parity of the first (lowest) port number to reserve. Allowed values are
'odd','even', and'any'. See also section 2.3.5. 🍓 - policy rule lifetime: the lifetime the agent proposes for the requested policy rule ⭐
reply-parameters (success) 👑
- request identifier: matches the identifier of the request 🫶
- policy rule identifier: a middlebox-unique policy rule identifier. The middlebox assigns it, and it's used as the policy rule handle in later policy rule transactions, especially to point at this policy reserve rule in a subsequent PER transaction 🔑
- group identifier: the group this policy reserve rule is a member of 🌈
- reserved inside IP address: the reserved IPv4 or IPv6 address on the inside of the middlebox. For an outbound flow, this is the destination the internal endpoint sends its packets to (A1 in Figure 3). For an inbound flow, it's the apparent source address of the packets as forwarded to the internal endpoint (A0 in Figure 3). The middlebox only reserves and reports an inside address when twice-NAT is in effect. Otherwise, an empty value for the addresses means 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 reserved IPv4 or IPv6 address on the outside of the middlebox. For an inbound flow, this is the destination the external endpoint sends its packets to (A2 in Figure 3). For an outbound flow, it's the apparent source address of the packets as forwarded to the external endpoint (A3 in Figure 3). If the middlebox is configured as a pure firewall, an empty value for the addresses means 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 grants. When it runs out, the reservation gets revoked, unless a policy enable rule in a PER transaction has already replaced it 💀
failure reason 🥀
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 it takes to get a flow enabled ✨ Usually the PRR shows up when you need to reserve stuff before you have enough info for a full policy enable rule transaction. See section 4.2 for an example 🌷
When the middlebox gets the request, it figures out how many address (and port) reservations it needs based on its configuration. If it only offers 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 set up 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 if needed. Once a PRR transaction has reserved an outside address (A2) for an internal endpoint (A0) at the middlebox, the middlebox must ensure that this reserved A2 stays available in any later PER and PRR transactions. Lowkey a big deal 🔒
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 neither of them should be included. 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) gets reserved, and the inside interface parameter to pick the interface where the inside address tuple (inside IP address and port number) gets reserved. Without them, the middlebox picks the interfaces based on its internal configuration. 🦋
If there's a lack of resources, like available IP addresses, port numbers, or storage for more policy rules, the reservation fails and an appropriate failure reply gets generated. Not it 💀
If the agent specifies a policy rule group that doesn't exist, or an existing one that the requesting agent doesn't own, then no new policy rule is established and an appropriate failure reply gets generated. 🙅♀️
If it succeeds, this transaction creates a new policy reserve rule. If the agent specified an existing policy rule group, the new policy rule becomes a member of it. If no group is specified, a new group gets created with the new policy rule as its only member. The middlebox generates a middlebox-unique identifier for the new policy rule. The owner of the new policy rule is the authenticated agent that sent the request. 👑
The middlebox picks a lifetime that's greater than zero and less than or equal to 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_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
setupA 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 request only NAT service or twice-NAT service by picking the service parameter 'traditional' or 'twice'. An agent with no preference picks 'twice'. The 'traditional' value should only be used to select traditional NAT service on middleboxes that offer both traditional NAT and twice-NAT. With 'twice', the combined twice-NAT/NAT middlebox reserves A2 and A1. With 'traditional', it only reserves A2. An agent must always use the PRR transaction to choose NAT-only or twice-NAT service on 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). The reserved address(es) get returned to the agent. In this case, the request parameters "port range" and "port parity", and the reply parameters "inside port number" and "outside port number", don't matter at all 🙃
If the protocol identifier is UDP or TCP, a combo of an IP address and a consecutive sequence of port numbers, starting with the specified parity, gets reserved on neither side, one side, or both sides of the middlebox, as appropriate. The IP address(es) and the first (lowest) reserved port number(s) in that 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 with open sessions can access the new policy rule. If it finds one or more, it sends a REN message reporting the new policy rule to each of them. Main character energy for the whole group 📣
MIDCOM agents use the policy enable rule (PER) transaction to enable policy reserve rules that were already set up by a policy reserve rule (PRR) transaction. See also section 2.3.2. 🦋
2.3.9. Policy Enable Rule (PER) 🧚
Next up is the PER, the one that flips a reserved rule on 🔥
transaction-name: policy enable rule
transaction-type: configuration
transaction-compliance: mandatoryrequest-parameters 💖
- request identifier: an agent-unique ID for matching the request and reply at the agent 🪪
- policy reserve rule identifier: a reference to an existing policy reserve rule created by a PRR transaction. This can be empty, in which case the middlebox must assign any necessary addresses and port numbers within this PER transaction. If it isn't empty, 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 policy enable rule should be a member of. As indicated in section 2.3.3, if this value isn't supplied, the middlebox assigns a new group for this policy reserve rule. 🫶
- 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
'same'and'any'. See also section 2.3.5. - direction of flow 🦋: This parameter specifies the direction of enabled communication, either
'inbound','outbound', or'bidirectional'. - 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 3), 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 3). 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 independently of the type of middlebox (NAT, NAPT, firewall, NAT-PT, combined devices), for unidirectional or bidirectional traffic. It's giving universal compatibility 💅
The agent sends an enable request specifying the endpoints (optionally including wildcards) and the direction of communication (inbound, outbound, bidirectional). The communication endpoints are displayed in Figure 3. The basic operation of the PER transaction can be described by:
- 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. In the presence of these parameters, 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 the presence of 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 is the RLC transaction, and it's giving "I'd like to change how long this rule sticks around, please" 💅 It's a configuration transaction, so the agent is basically asking the middlebox to edit a rule's lifetime. 🦋
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 either a policy reserve rule or a policy enable rule 🌸policy rule lifetime: the new lifetime you're proposing for the rule 💖
reply-parameters (success):
request identifier: matches the identifier from the request, obviously 🫶policy rule lifetime: the remaining lifetime the middlebox actually granted ⏳
failure reason:
agent not authorized for this transactionagent not authorized to change lifetime of this policy ruleno such policy rulelifetime cannot be extended
notification message type: Policy Rule Event Notification (REN)
semantics:
okay so the agent can use this to ask for three things: making the lifetime longer, making it shorter, or ending the rule entirely. ✨ To end a rule, you suggest a new lifetime of zero. Iconic behaviour, no cap. 💀
Here's the vibe check the middlebox runs. First it checks that the policy rule exists and that the agent is allowed to access it. If either check fails, it sends back the matching failure reply. If the requested lifetime is longer than the current one, it also checks whether the rule is even allowed to be extended, and if it isn't, it sends a failure message. 🙈
A failure reply means the new lifetime was NOT accepted and the rule stays exactly as it was. A success reply goes out whenever the rule's lifetime got changed in any way. 🎀
The success reply carries the new lifetime. The middlebox picks a value that's greater than zero and less than or equal to the smaller of two things: what the agent asked for, and the maximum lifetime the middlebox set at session startup. Basically:
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
Wait, the bit that's lowkey dramatic: after the middlebox sends a success reply with a lifetime of zero, it treats the policy rule as non-existent. Any transaction on that rule after that gets a negative reply saying the rule doesn't exist anymore. Gone. Ghosted. 👻🌈
Also, the policy rule lifetime can get changed by the Group Lifetime Change (GLC) transaction too, as long as the rule is a member of that group. Multiple ways to make the change, bestie. 🧚
Last part: once the remaining lifetime has been successfully changed and the reply has gone back to the requesting agent, the middlebox checks whether any other authenticated agents in open sessions can access the rule. If it finds any, it sends each of them a REN message reporting the new remaining lifetime. Everyone stays in the loop 💜
2.3.11. Policy Rule List (PRL) 🌸
transaction-name: policy rule list
transaction-type: monitoring
transaction-compliance: mandatoryThis one is a monitoring transaction, and it's basically the "show me everything I can see" button. 👀
request-parameters:
request identifier: an agent-unique identifier for matching corresponding request and reply at the agent 🎀
reply-parameters (success):
request identifier: matches the identifier of the request 🫶policy list: the list of policy rule identifiers for every policy rule the agent can access 📋
failure reason:
transaction not supportedagent not authorized for this transaction
semantics:
okay so the agent can use this to list every policy it's allowed to access. Usually the agent already knows this stuff, but in special situations, like after an agent fail-over, or for special agents like an administrating agent that can access all policies, this transaction is a total lifesaver. 🧚✨
The middlebox checks whether the agent is authorized to request this first. If that check fails, it sends back a failure reply. Otherwise you get a list of all the policies the agent can access, and each entry shows the policy's identifier and its owner. 💖
And the tea: this transaction does NOT change the policy rule state at all. It's purely a look-don't-touch situation. 🙈
2.3.12. Policy Rule Status (PRS) 💅
transaction-name: policy rule status
transaction-type: monitoring
transaction-compliance: mandatoryAnother monitoring transaction, but this one is the deep-dive. It's giving "tell me EVERYTHING about this one rule." 🔍🦋
request-parameters:
request identifier: an agent-unique identifier for matching corresponding request and reply at the agent 🎀policy rule identifier: the middlebox-unique identifier for the policy rule 🌸
reply-parameters (success):
request identifier: matches the identifier of the request 🫶policy rule owner: an identifier of the agent that owns this policy rule 👑group identifier: a reference to the group the policy rule belongs to 🧺policy rule action: this has either the value'reserve'or the value'enable'🔥transport protocol: identifies the protocol a reservation is requested 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 (IP version of A0 in Figure 3) 🌐external IP address version: the version of the external IP address (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 at the inside of the NAT (A1 in Figure 3); see section 2.3.5 🏡inside port number: the internal port number provided at 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 at the outside of the NAT (A2 in Figure 3); see 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 🎫port parity: the parity of the allocated ports ⚖️service: the selected service in the case of a mixed traditional and twice-NAT middlebox (see section 2.3.8) 🍓policy rule lifetime: the remaining lifetime of the policy rule ⏳
failure reason:
transaction not supportedagent not authorized for this transactionno such policy ruleagent not authorized to access this policy rule
semantics:
okay so the agent can use this to list all the properties of a policy rule. Same deal as the PRL: usually the agent already has this info, but after an agent fail-over, or for special agents like an administrating agent that can access all policy rules, this transaction is super helpful. 🧚
The middlebox first checks that the specified policy rule exists and that the agent is authorized to access this group. 🙈 If either check fails, you get an appropriate failure reply. Otherwise, all the properties of the rule come back to the agent. Some of those returned parameters might be irrelevant, depending on the policy rule action ('reserve' or 'enable') and on other parameters, like the protocol identifier. Not every field is always the main character. 🎭
Again, this transaction does NOT affect the policy rule state. Look all you want, babe. 👀💜
2.3.13. Asynchronous Policy Rule Event (ARE) 🔔
transaction-name: asynchronous policy rule event
transaction-type: asynchronous
transaction-compliance: mandatorynotification message type: Policy Rule Event Notification (REN)
semantics:
okay so this is the one where the middlebox just... decides on its own to do something. 😭 At any point in time, it can choose to terminate a policy rule. The most common reason is lifetime expiration, but other events can trigger it too, like changes in the policy rule decision point. Plot twist, no warning needed. 🌪️
When that happens, the middlebox sends a REN message to every agent that's in an open session with it and is authorized to access the rule. The notification goes out BEFORE the middlebox changes the rule's lifetime. 🔔 Any other authorized agent can also trigger a lifetime change, and that change can be a shortening (lt_new < lt_existing), an extension (lt_new > lt_existing), or a termination of the policy rule (lt_new = 0). Lots of drama, all the time. 🎬✨
The ARE transaction handles REN messages the same way section 2.3.4 describes, just for multiple agents at once. Everyone gets the update, everyone stays in the loop 🫶🌈
2.3.14. Policy Rule State Machine ✨
okay so the state machine for policy rule transactions is shown in Figure 4 with every possible state transition 🦋 the transaction abbreviations live in the headings of each transaction section, so just look there 💅
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)/success
Figure 4: Policy Rule State Machinethis state machine exists per policy rule identifier (PRID) 🌸 every policy rule starts out in state PRID UNUSED, which basically means the policy rule doesn't exist or isn't active 🙈 once you're back in PRID UNUSED, that policy rule identifier is no longer tied to an existing policy rule and the middlebox is allowed to reuse it 🔁
a successful PRR transaction moves you from the starting state PRID UNUSED to RESERVED, where an address reservation gets set up 🎀 from RESERVED you can get into ENABLED with a PER transaction 💖 PER can also take you straight from PRID UNUSED to ENABLED with no reservation at all, which is so efficient, bestie ✨ and in ENABLED, the requested communication between the internal and the external endpoint is turned on 🦋
RESERVED and ENABLED can both be kept alive by successful RLC transactions that ask for a lifetime greater than 0 🫶 going back to PRID UNUSED from either of these states can happen through an ARE transaction, or through a successful RLC transaction with a lifetime parameter of 0 💀
a failed request transaction does NOT change state at the middlebox 😭 wait, sorry, let me be precise: it does not change state at the middlebox, full stop 💅
and note that transitions kicked off by RLC transactions can also be kicked off by GLC transactions 🌈
2.4. Policy Rule Group Transactions 👑
this section covers the semantics for transactions on groups of policy rules 🧚 the group transactions are:
- Group Lifetime Change (GLC)
- Group List (GL)
- Group Status (GS)
all of them are request transactions started by the agent 🫶 GLC is a configuration transaction, while GL and GS are monitoring transactions that don't have any effect on the group state machine 🔥
2.4.1. Overview 🌸
okay so a policy rule group has only one attribute: 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 an implicit property too, and it's just the owner of its member policy rules 👑
a group gets implicitly created when its first member policy rule is established 🦋 and it gets implicitly terminated when the last remaining member policy rule is terminated 💀 which means the lifetime of a group is the maximum of the lifetimes of all its member policy rules, no cap 🎀
every group has a middlebox-unique identifier 🔑
policy rule group transactions are declared as 'optional' by their respective compliance entry in section 3 🙈 but they still give you some really nice functionality, like letting the agent send one request instead of several, which you can't get 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, you can use GLC to delete all member policy rules by asking for a lifetime of zero 💖
the monitoring transactions Group List (GL) and Group Status (GS) let the agent explore the state of the middlebox and check its access rights 👀 GL lists all groups the agent may access, including groups owned by other agents 🧚 GS reports the status of one individual group and lists all its policy rules by their policy rule identifiers 🍓 then the agent can dig into each individual policy rule by using those identifiers in a policy rule status (PRS) transaction (see section 2.3.12) ✨
GL and GS are especially helpful after an agent fail-over 🫶 the agent taking over for a failed one can use them to retrieve whichever policies were established by the failed agent, which is such a lifesaver 🦋
notifications on group events are generated the same way policy rule events are 🔔 to tell agents about group events, the Policy Rule Group Event Notification (GEN) message type is used 💜 GEN messages contain 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:
configuration - 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 🧠
okay so the agent can use this transaction to ask for an extension of the lifetime of all members of a policy rule group 🌷 or to ask for shortening everyone's lifetime 🫧 or to request termination of all member policies, which also means the group is gone 💀 termination is requested by suggesting a new group lifetime of zero 🔥
the middlebox first checks whether the specified group exists and whether the agent is authorized to access it 🔍 if one of those checks fails, an appropriate failure reply is generated 😭 if the requested lifetime is longer than the current one, the middlebox also checks whether the group's lifetime may be extended, and it generates an appropriate failure message if it may not 🙅♀️
a failure reply means the lifetime of the group stays exactly the same 🫶 a success reply is generated by the middlebox if the lifetime of the group was changed in any way ✨
the success reply contains the new common lifetime of all member policy rules of the group 🎀 the middlebox picks a new lifetime that is less than or equal to the minimum of the requested lifetime and the maximum lifetime the middlebox specified at session setup along with its other capabilities, so:
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 sending a success reply with a lifetime of zero, the middlebox will terminate the member policy rules without any further notification to the agent 💔 it then considers the group and all of its members non-existent 🫥 any further transaction on this policy rule group or on any of its members gets a negative reply, saying that this group or policy rule (respectively) doesn't exist anymore 🙃
after the remaining policy rule group lifetime is successfully changed and the reply has been sent to the requesting agent, the middlebox checks whether there are other authenticated agents in open sessions that can access the policy rule group 👀 if it finds one or more, it sends a GEN message reporting the new remaining policy rule group lifetime to each of them 📣
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 transaction
semantics 🌈
the agent can use this transaction type to list all groups it can access 💜 usually the agent already has this info, but in special cases (like after an agent fail-over) or for special agents (like an administrating agent that can access all groups), this transaction is super helpful 🫶
the middlebox first checks whether the agent is authorized to request this transaction 🔐 if the check fails, an appropriate failure reply is generated 😬 otherwise, a list of all groups the agent can access is returned, showing the identifier and the owner of each group 🎀
this transaction does not have any effect on the group state 🦋
2.4.4. Group Status (GS) 🔍
okay bestie, this one is GS, and it's basically the "wait, what's actually in this group??" transaction 👀
transaction-name: group status
transaction-type: monitoring
transaction-compliance: optionalRequest parameters:
request identifier: an agent-unique ID so the agent can match the request to its reply 🎀group identifier: points at the group you want the status of 🧚
Reply parameters (success):
request identifier: matches the ID from the request, obviously 💅group owner: the ID of the agent that owns this policy rule group 👑group lifetime: how much lifetime the group has left. It's the maximum of the remaining lifetimes of all the members' policy rules, so it's the longest-living member that wins ⏳member list: every policy rule that's a member of the group, each one named by its middlebox-unique policy rule identifier 📋
Failure reasons:
- transaction not supported
- agent not authorized for this transaction
- no such group
- agent not authorized to list members of this group
Semantics:
The agent can use this transaction to list all the member policy rules of a group. Usually the agent already knows this stuff, but sometimes it doesn't, like after an agent fail-over, or for special agents like an administrating agent that can access every group. That's when GS is a total lifesaver 🙌
The middlebox checks two things first: does the group exist, and is the agent allowed to access it? If either check fails, it sends back an appropriate failure reply 💀 Otherwise it returns the full list of group members, with the identifier of each one.
This transaction does not have any effect on the group state. It's a read-only glow-up, no changes made 🦋
3. Conformance Statements ✨
okay so, a protocol definition complies with the semantics in section 2 if the protocol specification includes all the specified transactions with all of their mandatory parameters. BUT it's not required that an actual implementation of a middlebox supports every single one of these transactions 🫶 And which transactions are required for compliance is different for agents and middleboxes, so don't mix them up 😭
This section has the conformance statements for MIDCOM protocol implementations as they relate to the semantics. Conformance looks different for agents and for middleboxes. A concrete protocol specification will probably extend these statements, but any extension is expected to extend them in a way that keeps all of them still holding 💅
Here's the transaction-compliance property for 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. Non-negotiable, no cap 🙅♀️
A compliant implementation of a MIDCOM protocol MAY support none, one, or more of the following transactions: GLC, GL, GS. So the group ones are totally up to you 💜
A compliant implementation MAY extend the protocol semantics by further transactions. Main character energy, you can add more stuff ✨
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. So you can rearrange the parameters, as long as the actual information survives the glow-up 🦋
A compliant implementation of a MIDCOM protocol MAY support the use of interface-specific policy rules. If you do support them, then either both or neither of the optional inside and outside interface parameters in PRR, PER, and PRS MUST be included. No half-and-half situations 🙈
A compliant implementation MAY extend the list of parameters of transactions. More params, more fun 🍓
A compliant implementation MAY replace a single transaction by a set of more fine-grained transactions. If you do that, 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 one transaction gets split into a set of smaller ones, that set MUST be equivalent to the single transaction. And this set of transactions MUST further meet the atomicity requirement stated in section 2.1.4. Very important, bestie, don't skip this 😤
3.2. Middlebox Conformance 🧚
A middlebox implementation of a MIDCOM protocol supports a request transaction if it can receive and process all possible correct message instances of that request transaction, and if it generates a correct reply for any correct request it gets 🎀
A middlebox implementation of a MIDCOM protocol supports an asynchronous transaction if it can 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. So the middlebox has to spill its supported transactions during SE, no secrets 🤫
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 that request 💖
An agent implementation of a MIDCOM protocol supports an asynchronous transaction if it can receive and process all possible correct message instances of that transaction 🌈
A compliant agent implementation of a MIDCOM protocol must not use any optional transaction that the middlebox doesn't support. The middlebox tells the agent which transactions it supports within the SE transaction, so the agent knows what's off the table 🙃
4. Transaction Usage Examples 🎀
this section gives two usage examples of the transactions from section 2. The first one shows how an agent can explore all the policy rules and policy rule groups it's allowed to access at a middlebox 🔍 The second example shows how a middlebox gets configured alongside setting up a voice over IP session with the Session Initiation Protocol (SIP) [RFC3261]. It's giving real-world vibes 📞✨
4.1. Exploring Policy Rules and Policy Rule Groups 🔍
okay so this example assumes you already have an established session 💖 here's what 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 the session gets disrupted or after an intentional session termination, the agent might want to re-establish the session and check which of the groups and policy rules it set up are still in place ✨
also, an agent system might fail and another one takes over 😭 then the new agent system needs to find out what the failing system already configured and what still needs to be done. main character energy for the recovery arc 🎀
a third situation where exploring policy rules and groups is useful is an agent with 'administrator' authorization 👑 this agent may access and modify any policy rule or group created by any other agent. iconic power move ngl 💅
all agents will probably start their exploration with the Group List (GL) transaction, as shown in Figure 5 🦋 on this request, the middlebox returns a list of pairs, each containing an agent identifier and a group identifier (GID). so the agent learns which of its own groups it can access, and which other agents' groups it can access too 🌸
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 Transactions
in Figure 5, three groups are accessible to the agent, and it grabs info about the second group using the Group Status (GS) transaction 🧚 it gets back the owner of the group, the remaining lifetime, and the list of member policy rules. in this case that's four policy rule identifiers (PIDs) 🍓
next up, the agent explores these four policy rules ✨ the example assumes the middlebox is a traditional NAPT. Figure 6 shows the exploration of 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' parameter in Figure 6 is just a placeholder in policy rule status replies for policy reserve rules 🫶 the policy rule with PID1 is a policy reserve rule for UDP traffic at 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 are wildcarded in the reply. same deal for the inside middlebox address and port number. the only address info in the reply is the reserved outside IP address of the middlebox (IPADR_OUT) and the matching port number (PORT_OUT1). note that IPADR_OUT and PORT_OUT1 may not be wildcarded, because the reserve action doesn't support that 🙈
applying PRS to PID2 (Figure 7) shows the second policy rule is a policy enable rule for inbound UDP packets 🌈 the internal destination is fixed when it comes to IP address, protocol, and port number, but for the external source, the port number is wildcarded. the outside IP address and port number of the middlebox are what the external sender needs to use as destination in the original packet it sends. at the middlebox, the 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 from the inside address, which 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 inside IP address and port number always match the external IP address and port number (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 communication between the same host 🎀 here all 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 shown outside IP address and port number of the middlebox ✨
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 Bidirectional TCP Traffic
finally, Figure 9 shows the status report for enabled bidirectional TCP traffic 🔥 note that A1=A3 still holds. for outbound packets, only the source IP address and port number get replaced at the middlebox, and for inbound packets, only the destination IP address and port number get replaced.
4.2. Enabling a SIP-Signaled Call 📞
this elaborated transaction usage example shows the interaction between a back-to-back user agent (B2BUA) and a middlebox 💖 the middlebox itself is a traditional Network Address and Port Translator (NAPT), and two SIP user agents talk to each other through the B2BUA and a NAPT, as shown in Figure 10 🦋 the MIDCOM agent is co-located with the B2BUA, and the MIDCOM server is at the middlebox. so the MIDCOM protocol runs between the B2BUA and the middlebox 🧚
+-------------+
| B2BUA |
| 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, we're making these assumptions 🌸
- The NAPT is statically configured to forward SIP signaling from the outside to the B2BUA -- i.e., traffic to the NAPT's external IP address and port 5060 is forwarded to the internal B2BUA.
- The SIP user agent A, located inside the private network, is registered at the B2BUA 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 RTP Control Protocol (RTCP) paths.
- The middlebox and the B2BUA share an established MIDCOM session.
- Some parameters are omitted, such as the request identifier (RID).
and here are the abbreviations we'll be using 🍓
- 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 📞 the user agent A sends an INVITE SIP message to the B2BUA (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_AIwhere the m tag is the media tag that contains the receiving UDP port number, and the c tag contains 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 B2BUA 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 numbers of user agent B are known at this point, the address of user agent B must be wildcarded. the wildcarded IP address and port number enable the 'early media' capability, but this comes with some insecurity, because any outside host can reach user agent A on the enabled port number through the middlebox 😭
4.2. HTTP-Related URI Schemes ✨
Okay, Figure 11 is where it gets spicy 🌶️
User Agent B2BUA Middlebox User Agent
A NAPT B
| | | |
| INVITE | | |
| 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
So a successful PER reply, like the one in Figure 11, creates a NAT binding at the middlebox 🦋. That binding lets UDP traffic from any host outside user agent A's private network reach user agent A 😳. User agent B could start sending traffic the second it gets the INVITE, and so could literally any other host, even ones that aren't supposed to be in the call, like a malicious host 💀. Not it! 🙅
If the middlebox doesn't support or doesn't permit IP address wildcarding for security reasons, the PER request gets rejected with an appropriate failure reason, like 'IP wildcarding not supported' 🥲. Even so, the B2BUA 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 (B sends it in the SIP reply) and wildcarding isn't permitted, the B2BUA goes with the PRR transaction 🧚.
User Agent B2BUA Middlebox User Agent
A 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
With a PRR request, the B2BUA asks for an outside IP address and port number (see Figure 12) without setting up a NAT binding or pin hole 🌸. The PRR request carries the service parameter tw, which means the MIDCOM agent picks the default value 💅. In this setup (NAPT, no twice-NAT), only an outside address gets reserved. Then the B2BUA swaps user agent A's IP address and port in the SDP payload of the INVITE for the reserved IP address and port from the PRR reply, and forwards the INVITE to user agent B with that modified SDP body. So user agent B knows exactly where to send its RTP media stream 🎀.
That SIP 200 OK reply tells us the IP address and port where user agent B will receive a media stream 🫶. The IP address is assumed to be the same one user agent B will send its media stream from 👀.
Now the B2BUA has everything it needs to set up the full NAT binding with a policy enable rule (PER) transaction, so UDP/RTP data can flow from user agent B to user agent A 🔥. This PER transaction points to the reservation by passing the PID of the PRR, which is PID1.
The other direction, UDP/RTP from A to B, needs enabling too 🙈. That's a second PER transaction with all the necessary parameters (see Figure 13). This request carries the group identifier GID1 that the middlebox assigned in the first PER transaction, so both policy rules end up in the same group 👑. Once both UDP/RTP streams are enabled, the B2BUA forwards the 200 OK SIP message to user agent A to say the call can start 📞✨.
User Agent B2BUA Middlebox User Agent
A 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 B2BUA forwards all SIP messages and then terminates the group using a group lifetime change (GLC) transaction with a requested remaining lifetime of 0 seconds (see Figure 14) 💀. Terminating the group also terminates all member policy rules 🧹.
User Agent B2BUA Middlebox User Agent
A 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's 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 with the number of the section in which they are defined: "requirement x.y.z" refers to the requirement specified in section x.y.z of [MDC-REQ] 🧠.
5.1. Protocol Machinery Requirements 🔧
5.1.1. Authorized Association 🔐
The specified semantics lets a MIDCOM agent set up an authorized association between itself and the middlebox 🤝. The agent identifies itself using the authentication mechanism of the Session Establishment transaction described in section 2.2.1. Based on that authentication, the middlebox can figure out whether or not 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 🙌. How the different sessions get separated is left to the concrete protocol definition. It must provide a clear mapping of protocol messages to open sessions. Then 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 🙌. Again, how the sessions get separated is left to the concrete protocol definition. It must provide a clear mapping of protocol messages to open sessions. Then 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 of 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 in the view of its administrators 👩💼. From an agent's point of view, the middlebox behavior is unpredictable, because 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 behavior is not necessarily deterministic from the point of view of any agent.
Since predictability of the middlebox behavior is given 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 put 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. no in-between drama, bestie 💅
for each state transition, a message gets sent to the matching 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 exactly this purpose 🔥 and notifications are self-explanatory by their definition 💖
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) 👑 which means 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 the agent requested 🦋 and at any time the agent can retrieve full status information about all accessible policy rules and policy rule groups. no mysteries, no ghosting 🙈 so 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 (STN) 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 the agent did not explicitly ask for. 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, either by using two subsequent Session Establishment transactions or by mutual authentication provided on a lower protocol layer 🫶 so requirement 2.1.8 is met, iconic behaviour 👑
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. either side can end it, which means requirement 2.1.9 is met ✨
5.1.10. Request Result 📬
section 2.1 states that each request from an agent is followed by a reply from the middlebox indicating either success or failure. so requirement 2.2.10 is met 🍓
5.1.11. Version Interworking 🧚
section 2.2.1 says the agent needs to specify the protocol version number it will use during the session. the middlebox may accept this and act according to that protocol version, or it may reject the session if it does not support that version 🌈 if the session setup gets 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 the ones it overlaps, it is accepted (assuming the required authorization is given) ✨
so the behaviour 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 asks for 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 🦋 so 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, and 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 the input used to authorize access to policy rules and groups.
if the middlebox is sufficiently configurable, its administrator can set it up 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'/'disallow', are supported 🧐 in conformance with decisions the working group made 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 bestie, security is where things get SERIOUS 🫶 The agent and middlebox talking to each other is a super sensitive spot, because it kinda feels like it goes against what a middlebox even is. Like, getting policy rules from something outside the middlebox? Iykyk 💀 So effective means have to be used to ensure 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). Once authentication is in place, the middlebox can decide whether an agent is authorized to request an action at the middlebox 👑 For integrity and confidentiality of the transferred data between both entities, the semantics relies on underlying protocols, such as TLS or IPsec.
For the TLS and IPsec use, both sides must use securely configured credentials for authentication and authorization 🔒
Wildcarding IP addresses and port numbers in policy rules comes with some risks, like accidentally opening overly wildcarded policy rules 😬 An excessively wildcarded policy rule would be A0 and A3 with the IP address set to 'any' IP address, for instance. That kind of pinhole makes the middlebox useless from a security point of view, because any packet could traverse it without further checking. The local policy of the middlebox should reject such policy rule enable requests.
A reasonable default for wildcarding would be 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.
The example in section 4.2 shows how SIP-signaled calls can be served securely without wildcarding IP addresses 🎀 But some SIP-signaled applications make use of 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 isn't known yet, the IP address of the second participant needs to be wildcarded 🙈
In cases like this and several similar ones, the middlebox operator has a security policy decision to make 💅 The operator can configure the middlebox to support more functionality, for example by allowing wildcarded IP addresses. Or they can make network operation more secure, for example by disallowing wildcarded IP addresses.
7. IAB Considerations on UNSAF 🦋
UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a process at originating endpoints that attempt to determine or fix the address (and port) by which they are known to another endpoint. UNSAF proposals, such as Simple Traversal of the UDP Protocol through NAT (STUN) [RFC3489], are considered 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 such a middlebox communication (MIDCOM) solution. MIDCOM is not intended as a short-term workaround, but more as a long-term solution for middlebox communication 🌸 In MIDCOM, endpoints are not involved in allocating, maintaining, and deleting addresses and ports at the middlebox. The full control of addresses and ports at the middlebox is located at the MIDCOM server.
Therefore, this document addresses the UNSAF considerations in [RFC3424] by proposing a long-term alternative solution 🧚
8. Acknowledgements 💜
We would like to thank all the people contributing to the semantics discussion on the mailing list for a lot of valuable comments 🫶
9. References 📚
9.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative 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.
- [MDC-SEM] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communications (MIDCOM) Protocol Semantics", RFC 3989, February 2005.
- [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.
- [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
- [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [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.
Appendix A. Changes from RFC 3989 ✨
- The example in section 4.2 used a SIP proxy server modifying the body of a SIP message. This was a violation of RFC 3261. This has been fixed by replacing the SIP proxy server with a back-to-back user agent.
- Clarifications concerning the used set of transaction types have been added.
- Section 3.1, "General Implementation Conformance", now uses key words from RFC 2119.
- Minor editorial changes have been made and references have been updated.
Authors' Addresses 💌
Martin Stiemerling
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-113
EMail: stiemerling@nw.neclab.eu
Juergen Quittek
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-115
EMail: quittek@nw.neclab.eu
Tom Taylor
Nortel
1852 Lorraine Ave.
Ottawa, Ontario
Canada K1H 6Z8
Phone: +1 613 763 1496
EMail: tom.taylor@rogers.comFull Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🌈
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
📦 where this page comes from
- ietf: rfc5189 2008-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms