Summary

  • RFC 3182 placed one or more AUTH_DATA elements inside RSVP policy data. A locator pointed toward the applicable policy; a plain name, Kerberos ticket or certificate supplied different grades of identity evidence. None granted network resources by itself.
  • Identity was not immutable end-to-end. For unicast user policy, the locator could survive while credentials changed to the current network node. In multicast, user identity became the current node’s identity and application identity could be the first element or one selected by the Policy Decision Point.
  • Successful authentication remained distinct from authorization, local enforcement, path-wide reservation, packet treatment and application outcome. Later RSVP security analysis made that boundary explicit and exposed confidentiality, roaming and authorization gaps.

A name could finally travel with the reservation

RSVP began with two questions that looked close but were not interchangeable. Did the node have enough resources for a reservation? Was this requester permitted to receive them? RFC 2205 called the first admission control and the second policy control. Both had to succeed, while the policy material remained opaque to the RSVP machinery carrying it.

RFC 3182, published in October 2001 as a Proposed Standard, supplied a vocabulary for the second question. It placed authentication data inside the POLICY_DATA object. A host could attach identity material to PATH or RESV signalling; routers or policy servers could validate that material and decide whether a request met local rules.

The document replaced RFC 2752. This was not a second wave of deployment. The replacement corrected a policy-element codepoint assignment and the width of an error field. A later administrative update in the Datatracker likewise does not make the mechanism new: the record was refreshed in 2026 because a verified erratum exists, not because a 2026 protocol revision appeared.

That erratum matters. The published section 6.3 said a Kerberos ticket should be sent to the KDC to obtain a session key. Verified erratum 2958 corrects the operation: the server extracts the session key from the ticket and uses it to authenticate the user. The distinction prevents a historical description from turning an acknowledged error into the architecture.

The locator was an address to a rulebook

The authentication element had two standard identity types: AUTH_USER for a user and AUTH_APP for an application. Within either element, attributes performed different jobs.

POLICY_LOCATOR carried a distinguished name intended to locate admission policy. CREDENTIAL carried an identifier, Kerberos ticket, X.509 certificate or PGP certificate. A digital-signature attribute could bind the preceding authentication data. A policy-error attribute could return a reason such as unsupported credential type, insufficient privilege, expiry or changed identity.

Those fields formed a sequence, not a single badge. A locator answered where a rule might be found. A credential answered what material a verifier could examine. A signature answered whether protected content matched a key operation. The Policy Decision Point still had to select and apply a policy. The Policy Enforcement Point still had to make the node accept or deny the request.

RFC 2753 made the division explicit. The PDP made policy decisions and could consult directories, authentication systems, accounting or billing databases. The PEP enforced the returned decision. Resource availability could still defeat a policy-approved request; a missing policy object was not supposed to bypass policy evaluation. Identity was one input among time, group, requested bandwidth, local configuration and administrative agreement.

This is where a symbolic reading becomes dangerous. A distinguished name looks official because it is structured. A certificate looks authoritative because it is signed. Neither fact identifies who was entitled to allocate bandwidth under this node’s policy. Authority entered only when an accountable decision-maker connected validated evidence to a rule it was empowered to enforce.

Three credentials did not make one assurance level

The simplest format carried a login or application identifier as plain ASCII or Unicode. RFC 3182 itself warned that this method contained no credential that could be securely authenticated and was inherently less secure. An executable filename such as the document’s vic.exe example described a string. It did not attest to a measured binary, publisher, process owner or unmodified program.

Kerberos carried a service ticket for the next RSVP node or its policy server. The host and verifier had to support Kerberos, know the relevant next-hop or PDP identity, and share the larger realm machinery. The ticket could support authentication within that trust system. It did not carry the resource policy, current capacity or a universal entitlement that every later domain had to honor.

The public-key form carried a certificate and a digital signature. It assumed a protected private key, a trusted certificate authority and a verifier able to validate the certificate. Even then, a successful signature established control of a key under a particular validation context. It did not prove that the certificate remained acceptable under every local policy, that revocation checking had occurred, that the named organization authorized this reservation, or that the requested application was the process actually sending traffic.

RFC 4230 later exposed the cost and missing context. Public-key identity in every signalling message imposed processing and bandwidth overhead; revocation checking required more machinery; Kerberos did not make user identity entirely confidential; and an authenticated principal could still lack authorization. The stronger credential improved one receipt. It did not collapse the chain.

At each hop, the envelope could have a new speaker

The most revealing part of RFC 3182 was not its certificate syntax. It was the rule for generating identity data while a message moved.

For a unicast session’s user policy, the user policy locator was copied from the previous hop, but the authentication credentials represented the current network node. The apparent subject and the current speaker could therefore come from different stages. For multicast user policy, both the locator and the credential represented the current node.

Application identity followed another rule. In unicast it could be copied from the previous hop. In multicast, the application element could be the first one in the message or one chosen by the PDP. A single surviving application identity was consequently not a census of every contributor. It was the output of an ordering or policy choice.

Messages could contain multiple authentication elements. Policy-aware nodes and PDPs could also replace policy information. A later observer who stored only the last AUTH_DATA value would lose whether it originated at the host, described an earlier user locator, authenticated the current router, survived because it arrived first, or was selected by a policy authority.

This was not necessarily corruption. It was how the architecture crossed administrative and multicast boundaries. But legitimate transformation requires provenance. The record needs the incoming element, outgoing element, actor, trust domain, decision, security association and reason for change. Without that custody, “identity verified” has no stable subject.

A policy-unaware hop could carry the packet without judging the identity

Not every RSVP node had to understand policy. RFC 2753 allowed policy enforcement at a subset of nodes, with policy-ignorant nodes relying on trusted policy-capable nodes inside an administrative domain. RFC 3182 said a policy-unaware router could ignore policy objects and continue processing.

That behavior preserved incremental deployment. It also limited what a successful traversal proved. A message passing a router did not show that the router had evaluated the user, certificate, group or entitlement. A later reservation state could coexist with an unevaluated policy object at some hops.

At a policy-capable boundary, the PEP could ask a PDP for a decision and wait. A negative response meant rejection. A positive response allowed ordinary RSVP processing to continue; it still did not guarantee capacity at every later node, scheduler installation, data-plane treatment or application receipt.

The protocol therefore carried several kinds of silence. A policy-unaware node could ignore the data. A policy-capable node could approve it. A resource controller could later reject it for lack of capacity. A downstream node could apply a different policy. Treating all non-error passage as one authorization result would erase the architecture RFC 3182 depended upon.

Error codes preserved disagreement but not its consequences

The policy-error object could say that the credential type was unsupported, privilege was insufficient, the credential had expired or identity had changed. When a PDP could not verify the element, it had to return a policy-control failure to the enforcement point and should add more detail for the RSVP error message.

These codes were useful because they kept failure inside the identity-policy boundary. EXPIRED_CREDENTIAL did not mean resources were unavailable. INSUFFICIENT_PRIVILEGES did not mean a certificate signature failed. IDENTITY_CHANGED admitted that the relevant subject was stateful rather than frozen at session creation.

But the returned error stopped at its own scope. It did not prove that all prior reservation state was removed, that data traffic ceased, that another branch of a multicast tree received the same result, that an application saw the message, or that a later retry used corrected identity. An error receipt must be linked to enforcement and outcome observations rather than used as their substitute.

The current IANA RSVP Parameters registry still records the base POLICY_DATA class and policy-control failure values. That is evidence of coordinated number space. It is not an implementation census, proof that each authentication subtype remains deployed, or evidence that a particular router acted on it.

Integrity protected bytes, not legitimacy

RFC 3182 recommended integrity protection for the policy object when the whole RSVP message lacked it. The scheme could combine evidence about the user with evidence about the originating node and resist modification or replay within its security context.

RFC 4230 later drew the scopes more carefully. The RSVP integrity object protected the larger signalling message, while an integrity object inside POLICY_DATA protected that policy container. Policy-aware routers or PDPs could still modify policy material by design. User- and application-specific information could leak after the first hop. Router-to-router RSVP offered integrity but not general confidentiality.

The consequence is a three-part test. First ask whether protected bytes survived. Then ask which actor was authenticated by the relevant key or ticket. Finally ask whether that actor possessed authority under a current policy. Only the first two are cryptographic questions. A valid digest cannot tell whether the policy was fair, current, lawful or effective.

Inter-domain use sharpened the gap. RFC 2753 expected bilateral agreements and policy-object rewriting at provider boundaries. RFC 4230 found no standardized authorization data adequate to settle roaming policy and no agreed mechanism for QoS reservation authorization in roaming environments. Identity could cross a border while mandate remained local.

The historical lesson was a receipt chain

A defensible record begins with the asserted user or application identity and preserves the raw element. It then records the credential subtype, certificate or ticket validation, key and realm scope, replay and integrity context, and the precise authenticated principal.

The next record is not “success.” It is the policy locator, policy version, controlling administrative domain, other inputs and PDP decision. Then come PEP receipt and enforcement, resource availability, installed RSVP state, per-hop continuation and any later replacement, expiry or identity change.

Only after those control-plane receipts should an observer add scheduler state, packet treatment, path behavior and application-visible result. A reservation can be authorized and still fail for capacity. It can be installed locally and fail elsewhere. It can exist on the path while an application receives unusable service. Conversely, a policy error can be correct without proving the traffic stopped.

The multicast branch requires an additional ledger: all incoming application identities, their order, which PDP selected the survivor and which contributors disappeared from the compacted representation. “First” is not a mandate, and “selected” is not a statement that every receiver or sender shared one identity.

Lu Heng’s distinction between symbolic and execution layers helps explain the discipline, but it is an editorial lens rather than a claim about the RFC authors. RFC 3182 gave identity a place in the packet. Running systems still had to establish who could decide, where the decision applied and whether the promised effect occurred. A name became actionable only through that chain. It never became the chain itself.

Sources and limits

The protocol record is preserved in the RFC 3182 text, RFC Editor record, IETF Datatracker record, Datatracker API record and verified technical erratum 2958. The corrected predecessor boundary comes from RFC 2752.

The control architecture and security context come from RFC 2205, RFC 2750, RFC 2753, RFC 2747, RFC 4230, RFC 4094 and the later RFC 4923. Historical credential context comes from the cited RFC 1510 and RFC 2459. The present registration view is the IANA RSVP Parameters registry.

The analytical separation of symbols, authority and execution is informed by Lu Heng’s essays on reality layers and running-code primacy. The 18-source set was frozen on 2 October 2026 in Asia/Shanghai. It identifies no named implementation, operator, user, application, reservation, attack, deployment, interoperability result, traffic trace or service outcome. Proposed Standard status, a registered value, a valid credential, a PDP approval and local RSVP state each establish only their own layer.