Summary

  • RFC 3520 defines an AUTH_SESSION policy element that carries a bounded authorization statement from session signaling into a resource-reservation request. Its identity, integrity, replay state and exact fields help a policy decision; they do not reserve resources or prove session delivery by themselves.
  • A defensible service receipt keeps authorizer scope, exact token bytes, freshness, field matching, local PDP decision, PEP enforcement, RSVP state, SIP preconditions, observed transport and authenticated application outcome separate. The promised outcome—not the earliest signed object—closes the chain.

The token was genuine. The authorizing entity had signed the bytes, the key was accepted, the session identifier correlated with a retained decision, and the requested bandwidth stayed inside the stated ceiling. The resource-control system had every reason to process the request.

The service team still had no receipt for the session.

That is the operational value of RFC 3520. Published in April 2003 on the Standards Track and currently recorded as Proposed Standard, it describes a Session Authorization Policy Element for policy-based per-session authorization and admission control. A process can authorize the reservation of resources, give the host an AUTH_SESSION element, and have the host carry that element inside an RSVP PATH message. Network elements can then verify the request and apply admission policy.

The word “authorize” is precise. It is not a synonym for reserve, deliver, hear, view, consent or complete.

A token is a courier between control planes

Session signaling and resource reservation answer different questions. A SIP-side system can know which media the service has authorized. A router or resource policy server can decide whether the network will admit a reservation. RFC 3520 supplies a structured object that lets evidence travel between those worlds.

The end host is the courier. It obtains the element through a session-signaling protocol and copies it without modification into the RSVP POLICY_DATA object. The host does not gain the authority to reinterpret the grant. Byte preservation is the useful property.

That distinction matters because the host may be untrusted. RFC 3521, the Informational framework accompanying RFC 3520, describes a token that can pass transparently through the host to an edge router. An opaque carrier can preserve an issuer's statement without becoming the issuer, the verifier or the final decision maker.

The first receipt is therefore narrow: these are the bytes the authorizer produced, and these are the bytes the reservation plane received.

The fields define a bounded grant

AUTH_SESSION is not a generic badge. Its initial attribute set can name the authorizing entity, a session identifier, source and destination addresses, start and end times, authorized resources and authentication data.

The resource description can express a maximum bandwidth, an RSVP flow specification, an SDP media description or a DSCP. Source and destination attributes can bind the statement to addresses and port lists. Time attributes can delimit freshness and duration. The session identifier can correlate the request with a decision retained by the authorizer.

Omission has semantics. If no port list is present for a side, all ports are considered valid for that side under the RFC's rules. If a list is present, only those ports are authorized. A review that merely checks for the presence of a token can therefore miss the difference between a deliberately narrow grant and a structurally broad one.

The receipt needs the exact field set, not a dashboard paraphrase such as “QoS authorized.”

Four models place trust in different locations

RFC 3520 uses the framework's coupled, associated and non-associated arrangements. They are not cosmetic deployment labels. They determine how much state the token carries and which external relationship supplies the rest.

In the coupled model, only a SESSION_ID is mandatory. The policy server already participates in both service and resource decisions, so the identifier points back to retained state. The end host remains untrusted, and integrity preservation is still required, but the identifier's format and mechanism are implementation matters.

In the associated model, the token adds the authorizing entity's identity. The edge uses it to find the policy server that owns the underlying media decision. If the edge cannot independently know that the identity denotes a legitimate policy server in its domain, authentication data is required to prevent redirection to a bogus authorizer.

The two-policy-server variant introduces a further administrative boundary. One policy server knows the service authorization; another controls resources. A successful lookup across them is part of the evidence chain, not background plumbing.

In the non-associated model, the verifier may have no retained relationship with the authorizer. The token must carry enough information for an autonomous decision: source, destination, resource characteristics, start time, authorizer identity or credential and authentication data. Optional ports and end time narrow the grant further.

A system cannot audit all four models with one generic “token valid” field. The dependencies are different.

Authenticity does not create authority

AUTHENTICATION_DATA protects the data that precede it in the element. RFC 3520 describes historical shared-key, Kerberos and public-key methods. Public-key processing includes certificate-path and revocation checks followed by signature verification; the document says this establishes integrity, data origin and non-repudiation.

That is still not the same as accepting the signer as an authority over this resource in this domain.

RFC 3520 makes the separation explicit. After establishing the identity of the authorizing entity and validating the service request, the router or Policy Decision Point must consult local policy tables. Their contents are a local matter. If a decision relies on supplementary information, that information must be obtained securely.

Cryptography answers whether an accepted key protected the statement. Local policy answers whether that statement is entitled to influence this resource. The first cannot silently inherit the second.

The RFC's 2003 algorithm requirements belong to the historical specification. They are not current cryptographic deployment advice, and an article about evidence should not turn them into one.

Exact matching survives signature verification

In the non-associated model, all token fields must match the resource request. A mismatch should cause denial. Source and destination addresses in the reservation datagram must match authorized values. Requested resources must not exceed the authorized QoS.

This is a semantic verification step after byte integrity.

A perfectly signed statement for one destination does not authorize another. A valid authorization for a voice flow does not automatically cover a different port or a broader bandwidth request. An accepted authorizer can issue a token whose fields are internally valid but irrelevant to the actual request.

Automation should preserve a comparison record: token field, observed request field, normalization rule, match result and policy consequence. Without that, an audit can prove only that a signature was correct—not that the signature covered the action that occurred.

Freshness depends on clocks or remembered state

RFC 3520 requires either START_TIME or SESSION_ID when constructing the element to prevent replay.

The two choices create different operational liabilities. A session identifier can point to a policy-decision record and internal replay state. Its safety depends on the authorizer retaining and reconciling that state across restart, replication and failover. A start time creates a freshness window. In the non-associated model, policy servers must support NTP synchronization; the RFC warns that unsynchronized clocks can allow replay.

A valid signature on replayed bytes remains valid. Freshness is not a property that cryptography supplies automatically.

The relevant receipt records the time source, observed offset, acceptance window and replay-cache decision, or it records the session identifier's creation, prior use and durable replication. A green “signature verified” event should never overwrite those facts.

RFC 5905 is useful later NTP context, not proof that any RFC 3520 implementation had sound clock discipline.

A policy-unaware router can carry the request onward

RFC 3520 distinguishes policy-aware and policy-unaware RSVP routers. A policy-aware router should send the message to a PDP and wait for a response. A policy-unaware router ignores policy-data objects and continues RSVP processing.

That sentence prevents a large category of false assurance. The presence of AUTH_SESSION on a path does not prove that every hop understood or enforced it. Even within a system designed for policy admission, enforcement coverage is an observed topology fact.

The operator needs to know which nodes are PEPs, which PDP each consulted, which nodes were policy ignorant, and which reservation state they installed. The token's travel history does not answer those questions on its own.

The common layer stays thin: carry the policy object and define how capable nodes process it. The operational layer still has to demonstrate where enforcement actually occurred.

Error Code 02 is not a universal failure ledger

If a PDP fails to verify the element, RFC 3520 requires a policy-control failure, Error Code 02, back to the PEP. The PDP should supply an AUTH_DATA policy element with a more detailed policy error, and the PEP includes it in the RSVP Error.

That receipt is valuable. It identifies one boundary: the authorization object could not be verified.

It does not encode every later failure. Local policy can deny an otherwise verifiable token. A field can mismatch. Resources can be unavailable. End-to-end reservation can remain incomplete. SIP preconditions can remain unmet. Media packets can fail after reservation. The application can reject or mishandle the session.

One error namespace cannot be used as proof that every other layer succeeded merely because it stayed silent.

Reservation completion is not media delivery

RFC 3521's flow is deliberately staged. A session-management server can report that setup is complete or progressing and include a token. The host sends an RSVP PATH. The edge consults a policy server. That server may modify the resources. The edge can wait for end-to-end negotiation, then an RSVP RESV can say the reservation is complete or progressing.

The repeated phrase “or is progressing” is a warning against premature closure. Even the framework keeps decisions and state transitions open.

RFC 3312 adds another useful distinction. SIP QoS preconditions maintain desired and current status. Mandatory preconditions suspend session establishment, and media should not flow while establishment is suspended. A reservation-related event can update current status; it does not erase the need to complete signaling and observe the media outcome.

A reserved queue is not a decoded voice stream. A policy decision is not user consent. A SIP response is not proof that the promised session stayed usable.

Build a receipt chain that can survive a dispute

Preserve the initial session request, authenticated actor and legal or operational principal. Record the authorizer's identity, authority scope, decision version and retained state. Hash the exact token and preserve every field, key or credential reference, validation result and replay decision.

Record the exact source, destination, ports, resource ceiling and lifetime from both token and reservation request. Preserve the comparison and any policy-server modification. Record which PDP decided, which PEP enforced, which nodes ignored policy data, and which RSVP PATH, RESV or Error messages share the same transaction.

Then record SIP desired/current preconditions, the observed transport and the authenticated application result. If billing or a customer promise depends on “completion,” state which receipt triggers it.

The chain should remain legible after failover. A replacement policy server must not approve a replay simply because it lost the first server's correlation state. A clock jump must not widen a grant silently. A topology change must not preserve the word “admitted” while moving the path outside known enforcement.

Evidence boundary

This Article identifies no product, vendor, policy server, router, carrier, operator, customer, user, session, media stream, incident or deployment. It makes no claim about current use, conformance, security, performance, QoS or business outcome.

RFC 3520 is treated as April 2003 Standards Track work currently recorded as Proposed Standard. RFC 3521, RFC 3313 and RFC 5866 retain their own statuses and scopes. RFC 3313's specialized administrative-domain assumptions are not generalized to the public Internet. Later NTP and Diameter documents are comparison evidence only.

Heng Lu's authority and running-code notes are disclosed editorial lenses. They support the distinction between a recorded statement and operational control, and between formal authority and observable outcome. They are not sources of IETF intent.

The narrow conclusion is sufficient: an authorization token can be authentic, fresh, matched and admitted while the session outcome remains unproved.

Sources