Summary

  • RFC 5189's Policy Reserve Rule can succeed while creating no binding, opening no pinhole and changing no packet-processing decision. On a pure firewall it may return empty address and port values by design.
  • A Policy Enable Rule is stronger evidence: it records a local middlebox configuration change. It still does not prove that a packet crossed the rest of the path, reached the remote endpoint or produced the intended application result.

The incident report began with a convincing object: an outside address and port had been allocated for a call. The allocator called the step “firewall opened.” That was the first false equivalence.

MIDCOM defines two different actions because the work happens at two different times. Before all peer details are known, an agent may need to hold an address or a consecutive port range. The Policy Reserve Rule, or PRR, creates that claim on resources. It does not bind the addresses and does not configure a pinhole. RFC 5189 says packet processing remains unchanged.

That negative statement is the centre of the design. A reservation can be valuable and successful without making communication possible. It prevents the reserved tuple from being handed to a conflicting request. It gives a later transaction something stable to consume. It is evidence of custody over scarce middlebox resources, not permission for traffic.

Empty values can be the correct success result

The distinction becomes clearest on a pure packet-filtering firewall. Such a device has no NAT address to reserve. It may process PRR successfully, move the MIDCOM rule identifier into the RESERVED state and return empty values for the inside and outside reservations.

An operations system that treats empty fields as failed work would misread the protocol. A system that treats the successful reply as an open firewall would make the opposite mistake. The correct record says: the semantic reservation transaction succeeded; this device allocated no tuple; packet processing did not change.

The receipt therefore needs more than a green transaction flag. It needs middlebox capability, transaction type, before-and-after rule state, returned tuple values and the action that the specification assigns to that state.

ENABLED is a different authority

The Policy Enable Rule, or PER, is the transaction that affects packet handling. A NAT can install bindings. A firewall can install one or more allow actions. A combined device may do both. PER can refer to an earlier PRR or go directly from an unused identifier to an enabled rule.

When PER successfully consumes a reservation, the middlebox may reuse the same rule identifier. That continuity is convenient, but it is also hazardous for evidence systems. The identifier did not remain in one state: it moved from RESERVED to ENABLED. A log keyed only by the identifier can make later enabled state appear to have existed when the earlier reservation reply was issued.

The record must carry the state transition and transaction time. Identifier equality proves correspondence between the reservation and its replacement. It does not erase their different authority.

If PER fails, RFC 5189 leaves the referenced PRR intact. That creates a third condition: communication was not enabled, yet the resource remains held until expiry or deletion. Cleanup systems need to preserve this distinction or they may leak reservations, retry against a stale assumption, or release an address that another workflow still expects to consume.

A middlebox receipt stops at the middlebox

PER success is meaningful. It reports that the addressed middlebox accepted an atomic request and established the specified local rule. It can identify the returned tuples, direction, protocol, wildcarding and lifetime. None of that is an observation from the far endpoint.

The packet can still fail at another firewall, at routing, at the host, at a transport listener or inside the application. Even on the same box, the RFC's semantic success is not a packet capture. Leadership reporting should therefore separate four layers: resource reserved, rule enabled, packet observed across the device, and remote application outcome.

This is not scepticism about running code. It is respect for the scope of each running component. The middlebox can authoritatively report the rule it installed. Only a traffic observation can report what traversed it, and only the receiving system can report what it accepted.

Lifetimes are granted, not requested

Every rule carries a lifetime. The agent proposes a duration; the middlebox grants a duration bounded by that request and by the maximum advertised at session establishment. Recording the proposal as the expiry contract invents time that the middlebox never granted.

The rule can also end before ordinary expiry. A lifetime-change request of zero deletes it. The middlebox can emit an asynchronous rule event. Another authorized agent may alter a rule. A policy decision point can change. The monitoring object therefore needs requested lifetime, granted lifetime, current remaining lifetime, event source and the time at which each claim was observed.

Closing the MIDCOM session is not equivalent to closing the policy rule. RFC 5189 explicitly retains established rules after normal or asynchronous session termination until their own lifetimes expire or another terminating event occurs. A disconnected controller can coexist with a live pinhole.

That design supports continuity, but it transfers responsibility. If the agent disappears, the remaining rule is no longer explained by a live control session. Operators must be able to trace it to its owner, creation request, granted lifetime and later events without relying on the session that created it.

Ownership and groups constrain who may change reality

The authenticated agent that creates a rule owns it. Ownership remains fixed for the rule lifetime, while local authorization can permit another agent to act on the owner's rules. Every rule belongs to exactly one group, and all members share one owner.

A group is not a free-standing durable policy object. It comes into existence with its first member and disappears with its last. Its lifetime is derived from member lifetimes; a group lifetime transaction can then assign a common bound or terminate every member with a requested zero.

Dashboards that show one group state without member history conceal the mechanism. A group-wide deletion may end a reservation and an enabled pinhole together. The same reply means different traffic consequences for each member because only the enabled rule had changed packet processing.

Atomicity has a boundary

RFC 5189 makes request transactions atomic relative to one another. An agent should not observe a stable intermediate state inside one semantic request. Asynchronous transactions may nevertheless interrupt or terminate processing, and a concrete protocol that splits a semantic transaction can change the original atomicity.

The evidence record should therefore name the semantic operation and the implementation operations that realized it. “Request succeeded” is insufficient if the concrete implementation decomposed the request and later reconciled several device writes.

Conflicts require the same discipline. A conflicting arriving rule is rejected while the existing rule remains. A non-conflicting overlap, even an identical rule, may be accepted. Admission order explains which policy object exists. It does not establish which packets were later seen.

The evidence object operations actually need

Begin with immutable change, session, agent and request identities. Record the authenticated owner, middlebox identity and capabilities, transaction type, rule and group identifiers, prior state and interface scope.

For PRR, retain requested tuple constraints, protocol, port range, parity, returned A1/A2 values and empty values without normalization. For PER, retain the PRR reference or direct-enable path, requested A0/A3 endpoints, direction, wildcarding, bindings and pinholes reported as installed.

For both, store requested, maximum and granted lifetimes. Record conflicts, failures and whether a reservation survived. Append status reads and asynchronous events in order. Keep session termination separate from rule termination.

Finally, join the control record to packet captures on both sides, remote receipt and application result. If those observations do not exist, say that the local rule is established and the outcome is unknown. Do not let the word enabled perform work that only evidence can do.

Sources

  1. RFC 5189 HTML
  2. RFC 5189 text
  3. RFC 5189 record
  4. IETF Datatracker: RFC 5189
  5. RFC 5189 history
  6. RFC 5189 references
  7. RFC 5189 errata
  8. RFC 3989
  9. RFC 3989 record
  10. RFC 3303
  11. RFC 3303 record
  12. RFC 3304
  13. RFC 3304 record
  14. RFC 3198
  15. RFC 3234
  16. RFC 3022
  17. RFC 6887
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy