Middlebox Communication (MIDCOM) Protocol Semantics
obsoletes
- rfc-3989 — Middlebox Communications (MIDCOM) Protocol Semantics
Extracted elements (28)
Policy rule group state is not independently maintained by the middlebox; instead it is implicitly derived from the aggregate state of all member policy rules. A group ceases to exist once all its member rules have expired. This was chosen to avoid redundant state management.
Session state and policy rule state are maintained in two independent state machines. This separation was chosen to simplify both the semantics specification and concrete protocol implementations; concrete implementations are expected to have more complex state machines that are a superset of those defined here.
The PRR transaction exists to handle scenarios—such as SIP-signaled calls—where an application needs to know the NAT-allocated external address before it has enough information to issue a full PER request. Without PRR, such applications could not convey the external address in their signaling prior to enabling the data flow.
MIDCOM semantics defines handling for IPv4, IPv6, TCP, and UDP only. Handling of other transport protocols such as SCTP is explicitly not defined in the semantics but may be supported by concrete protocol specifications that implement a superset of this semantics.
Session establishment may be reduced to a single transaction if mutual authentication is provided by the underlying transport, e.g., TLS (RFC 4346) or IPsec (RFC 4302/4303). In this case the server challenge and agent challenge parameters are omitted by the sender or ignored by the receiver.
A valid MIDCOM session MUST be established before any transaction on policy rules or policy rule groups can take place. Sessions are initiated by agents and both agent and middlebox may participate in multiple concurrent sessions.
Access to policy rules is ownership-based: the owner is the authenticated agent that created the rule, and it does not change during the rule's lifetime. All policy rules in a group must share the same owner, so an agent either has access to all members of a group or to none.
All request transactions are atomic with respect to each other: processing of a request at the middlebox is never interrupted by another concurrent or queued request, including those from different sessions. Asynchronous transactions may, however, interrupt or terminate request processing at any time.
For conflicting policy rules, the first-come first-served mechanism applies: existing rules remain unchanged and the newly arriving conflicting rule is rejected. Non-conflicting overlapping rules (including identical rules) are all accepted.
For interface-specific policy rules, the inside and outside interface parameters MUST both be included in a PRR or PER request, or neither should be included. They cannot be specified individually.
Mandatory transactions (SE, ST, AST, PRR, PER, RLC, ARE, and monitoring transactions PRL and PRS) MUST be implemented by every middlebox offering MIDCOM service and must be offered to each authenticated agent. Optional transactions (notably GLC) need not be implemented and may be selectively offered.
Once a PRR transaction has reserved an outside address A2 for an internal endpoint A0, the middlebox MUST ensure that the reserved A2 remains available for any subsequent PER or PRR transactions that reference it.
The lifetime granted by the middlebox for any policy rule must satisfy: 0 ≤ lt_granted ≤ MIN(lt_requested, lt_maximum), where lt_maximum is the maximum lifetime reported at session setup. This formula applies identically to PRR, PER, and RLC transactions.
The port range parameter must have the same value for each of address tuples A0, A1, A2, and A3. A policy rule with port range n is semantically equivalent to n individual rules each covering a single port number starting from the base port.
When a policy rule's state or remaining lifetime changes (other than natural time decrement), the middlebox MUST notify all other agents that can access the rule and are in open sessions via a Policy Rule Event Notification (REN) message. The requesting agent receives the corresponding reply instead of a REN.
Within a policy rule the IP version parameter must be the same for address tuples A0 and A1, and separately for A2 and A3. The transport protocol parameter must be identical across all four address tuples A0, A1, A2, and A3.
Address tuples A0–A3 define the four communication endpoints used in policy rules: A0 is the internal endpoint, A1 is the middlebox inside address, A2 is the middlebox outside address, and A3 is the external endpoint. For a firewall A2=A0 and A1=A3; for traditional NAT A2≠A0 but A1=A3; for twice-NAT both A1 and A2 are assigned by the NAT.
At session establishment the middlebox reports its capabilities to the agent, including: firewall/NAT function support, address and port wildcarding support, supported IP versions on internal and external interfaces, list of supported optional MIDCOM transactions, policy rule persistence, maximum lifetime, idle-timeout, and maximum simultaneous sessions.
The Asynchronous Session Termination (AST) is a mandatory asynchronous transaction initiated by the middlebox at any time. It sends a Session Termination Notification (STN) message containing the termination reason before closing the session; exactly one notification is sent since only one agent is affected.
The Policy Enable Rule (PER) is a mandatory configuration transaction that enables packet flow between an internal endpoint (A0) and external endpoint (A3) through the middlebox. The agent sends A0 and A3; the middlebox assigns or reuses (from a prior PRR) A1 and A2, establishes bindings or pinholes according to the specified direction (inbound, outbound, bidirectional), and returns A1 and A2.
The Policy Reserve Rule (PRR) is a mandatory configuration transaction that reserves an IP address, or IP address plus consecutive port range, on one or both sides of the middlebox without yet affecting packet processing. On a pure firewall the reservation succeeds with empty values; on a traditional NAT only an external address (A2) is reserved; on a twice-NAT both A1 and A2 are reserved.
The Policy Rule Lifetime Change (RLC) is a mandatory configuration transaction allowing an agent to extend, shorten, or delete a policy rule. Deletion is requested by proposing a lifetime of zero; after a successful zero-lifetime reply the middlebox treats the rule as non-existent.
The Session Establishment (SE) transaction is a mandatory configuration transaction that uses two sequential request/reply iterations to provide mutual authentication between agent and middlebox. The first iteration carries a middlebox challenge (mc); the second carries the agent authentication (aa) responding to the agent challenge (ac) returned by the middlebox.
The Session Termination (ST) transaction is a mandatory configuration transaction initiated by the agent to close a MIDCOM session. After sending a successful reply, the middlebox will not send further messages to or process further requests from the agent in that session; established policy rules are retained until their lifetimes expire.
Three notification message types are defined: Session Termination Notification (STN) carrying a termination reason; Policy Rule Event Notification (REN) carrying a policy rule identifier and remaining lifetime; and Group Event Notification (GEN) carrying a policy rule group identifier and remaining group lifetime. All contain a middlebox-unique notification identifier.
IP address wildcarding in policy rules is governed by the local policy of the middlebox. Permitting broad wildcards could allow an agent to enable traffic on behalf of addresses it does not control; middleboxes should restrict the range of wildcarding permitted to each authenticated agent.
The MIDCOM protocol must provide authentication of both agent and middlebox, message integrity, and confidentiality. Confidentiality of control messages is optional. The protocol must be capable of operating across untrusted domains and must include mechanisms to mitigate replay attacks.
The session state machine has three states: CLOSED, NOAUTH, and OPEN. A successful SE with mc=0 transitions from CLOSED directly to OPEN; with mc!=0 transitions first to NOAUTH, then to OPEN on a successful second SE. AST, connection failure, or successful ST from any state returns to CLOSED.