Summary

  • RFC 2989 evaluated AAA protocol submissions by capabilities; a required capability did not mean every exchange had to use it.
  • Its tables preserved different NASREQ, ROAMOPS and Mobile IP requirements instead of pretending one checklist row was a universal deployment policy.
  • Transport delivery, syntax and semantic evaluation, accounting responsibility, authorization effect and delivered service were separate receipts.

A table with a jurisdiction

RFC 2989 arrived as the IETF's AAA working group was trying to compare demands from several worlds. Dial access servers, roaming consortia and Mobile IP systems all needed authentication, authorization and accounting. They did not present the same topology, threat model or operational burden.

The document therefore did not begin by defining a new wire protocol. It summarized requirements gathered from NASREQ, ROAMOPS, MOBILEIP and TIA 45.6. General criteria sat beside authentication, authorization, accounting and Mobile IP-specific tables. Columns retained the source communities. Cells used M, S, O, N and B for MUST, SHOULD, MAY, MUST NOT and SHOULD NOT.

That format looks like a procurement scorecard. It can easily be misread as an inventory of deployed facts. Section 1.1 blocked that move.

The requirements, it said, were for evaluating protocol submissions. Their normative words referred to capabilities. A protocol submission that failed a mandatory requirement for a capability it implemented was noncompliant. One that met every MUST and MUST NOT but missed a recommendation was conditionally compliant. One that also met the SHOULD and SHOULD NOT rows was unconditionally compliant.

These were bounded judgments about a design. They were not reports from a running network.

The document made the distinction concrete with confidentiality. Requiring that a protocol support confidentiality was not the same as requiring all protocol traffic to be encrypted. A reviewer could prove that a candidate had a conforming protection mechanism. That proof did not identify which operator enabled it, which objects it covered, which peer negotiated it, which keys were used or which packet crossed a protected channel.

The checklist had jurisdiction over the proposal. The deployment retained jurisdiction over use.

Three columns were not one policy

The general table showed why the source columns mattered. Scalability was mandatory across NASREQ, ROAMOPS and Mobile IP. Failover appeared mandatory in NASREQ and Mobile IP but not as the same marked requirement in ROAMOPS. IPv4 support was mandatory in all three, while IPv6 and certificate transport carried different strengths. Auditability appeared as a NASREQ recommendation.

A blank cell did not say a feature was useless. A mandatory cell did not order every installation to exercise it on every transaction. The matrix preserved what each requirements process had asked of a candidate protocol.

That was a form of minimum initial specification. The shared layer named enough capability for comparison and interoperation without pretending to settle each operator's future decisions. The cost of reading the table without its columns is institutional: a local policy starts masquerading as a universal requirement, or a universal capability becomes presumed operational merely because a document listed it.

RFC 2119 vocabulary sharpened obligations inside a defined scope. It did not enlarge the scope. MUST attached to a protocol capability remained a statement about that capability.

Security ended and persisted at different boundaries

RFC 2989 placed transmission security and object security in adjacent rows, but described different custody.

Transmission-level security was hop by hop. Two communicating AAA peers could authenticate, protect integrity and encrypt their channel. When the receiving AAA entity processed the message, that layer of security was removed. A later hop established a new relationship.

Object-level confidentiality could instead protect one or more attributes for the ultimate target even while the message crossed proxies or brokers. Object-level authentication and integrity were meant to persist across intermediate AAA entities. Covered data could not be modified by those intermediaries.

Support for both mechanisms did not prove their runtime composition. An implementation might contain the code yet leave one path unconfigured. A proxy might terminate one secure hop while preserving an object envelope. The selected object set might omit the field an auditor cares about. A key might be stale. Verification might fail and trigger local fallback.

The criteria told reviewers what the protocol needed to make possible. Only keys, configuration, traces and verification results could show what happened.

Delivery was not interpretation

The reliable-transport clarification is the document's cleanest evidence boundary.

RFC 2989 called for resilience beyond a single transport hop: hop-by-hop retransmission and failover, application control of retransmission, piggybacked acknowledgements and timely AAA responses. It also named a transport acknowledgement that a message was delivered successfully.

Then it separated that acknowledgement from message semantics and syntax evaluation.

A receiver could acknowledge bytes or a message unit at the transport boundary and later reject the encoding, attribute set, state transition or authorization request. A proxy could accept the message locally while the next hop failed. A backup server could be reachable while lacking synchronized session state. A response could arrive on time and still contain a denial.

Reliability therefore needed more than one success bit. The operator had to preserve attempt identity, hop, retransmission, failover choice, transport receipt, parse result, semantic decision and downstream action.

That distinction did not weaken reliable transport. It stopped the transport from being credited with a decision it had not made.

Responsibility required a different acknowledgement

The accounting table used the word delivery again, but its clarification moved the receipt upward.

Guaranteed accounting delivery required an application-layer acknowledgement. RFC 2989 described it as being sent when the receiving server was willing to take responsibility for the message data.

That was more than transport arrival. It was still less than a final invoice or service truth.

The server might accept custody before durable replication. The record might later conflict with another interim record. A timestamp might be ambiguous. Dynamic reauthorization could create several accounting records for one session. The collected usage might support audit or cost allocation without becoming billing. RFC 2989 defined billing separately as preparing an invoice.

Responsibility acceptance, storage, reconciliation, rating, invoice creation, payment and customer experience were a chain. The application acknowledgement closed one link.

Auditability watched actions, not correctness

The document defined an auditable process as one in which it was possible to determine definitively what actions had been performed on AAA packets as they travelled from the home AAA server to the network device and back.

That aim mattered because proxies had different powers. A local proxy could enforce local policy before forwarding a response. A transparent proxy was defined by the absence of additions, deletions or modifications to forwarded information. A proxy broker sat in the message path; a routing broker could return information that let the parties contact one another directly.

An audit trail could record those actions. It could not, by its existence alone, prove that the action was allowed, that a policy was fair, that an assertion identified the correct person, that a NAS applied the returned restriction or that the subscriber obtained service.

Auditability is evidence about transformation and custody. Correctness and outcome need their own tests.

Authentication, authorization and accounting were not synonyms

RFC 2989's terminology prevented another common collapse.

Authentication verified a claimed identity in a mutually known namespace as a message originator or channel endpoint. Authorization determined whether a right could be granted to the presenter of a credential. Accounting collected resource-use information for analysis, audit, billing or cost allocation.

The authentication table even required the protocol not to demand user credentials during every authorization exchange. Identification or an assertion could support authorization. That capability did not make the assertion self-authenticating. It meant the protocol had to carry a decision whose proof might have been established elsewhere.

The authorization table included reject capability, access rules, reauthorization, state reconciliation and disconnect requests. Each was a control surface. None was evidence that a NAS executed the decision or that the desired network effect followed.

The checklist's durable lesson

RFC 2989 did not fail by being a requirements document. Its restraint was the achievement.

It gathered heterogeneous demands into a common comparison surface while stating what the surface could not say. Capability was not invocation. Transport arrival was not interpretation. Application custody was not billing. Auditability was not correctness. Authorization was not delivered access.

Lu Heng's reality-layer lens makes the historical boundary visible: requirement source, RFC text, protocol capability, implementation, configuration, message, intermediary action, decision, device effect and user outcome are connected facts. Authority at one layer cannot silently testify for all the others.

Running code supplies the missing receipts. A deployed system must show which feature was selected, which boundary acknowledged it, what policy acted, what state changed and what result was observed.

The checklist graded the candidate. The network still had to produce the evidence.

Sources