Summary

  • RFC 6345 does not require a relay to maintain per-client state. The authentication agent nevertheless records the relay’s address and port, and the endpoints still manage their PANA session.
  • Credential protection and delivery remain separate obligations. The standard’s security analysis allows disruption of the exchange without successful impersonation of the client.
  • A low-state intermediary is an architectural economy, not evidence that configuration, capacity, recovery or accountability costs have disappeared.

The saving needs a boundary

Imagine evaluating a small network component on the promise that it keeps no state for individual clients. The appeal is immediate: fewer records to allocate, expire and recover at that point in the system. But a purchase decision turns misleading if the comparison ends at the component’s enclosure. Someone still has to know where a reply belongs.

This is an analytical purchasing scenario, not an account of a vendor quotation. It exposes a useful question in PANA, the Protocol for Carrying Authentication for Network Access. A relay can be economical precisely because it does not become the complete admission system. The economy deserves credit. It also deserves an honest perimeter.

The official record for RFC 6345 identifies the August 2011 document as a Proposed Standard. It describes a relay for a client and authentication agent that cannot reach each other through ordinary IP routing. A joining device with only a link-local IPv6 address supplies the motivating example. Its nearby parent can carry the authentication exchange toward a more distant agent. That is a documented design case, not a count of installations still using it.

The resulting question is not whether a relay should be made more complicated. It is whether the proposed simplification has been priced at the point where obligations remain. A central function can serve many lightweight edge devices efficiently. The same concentration can make its capacity, configuration and repair process important to all of them. Neither consequence is measured merely by counting records absent from an edge box.

The session did not disappear

The division in RFC 6345 is concrete. The PANA Relay Element, or PRE, need not maintain per-client state. The PANA Authentication Agent, or PAA, retains the PRE’s IP address and UDP port as an additional attribute of the session. Client coordinates travel in PaC-Information; the inner PANA message travels in Relayed-Message without its IP and UDP headers. Reply delivery uses that separation.

The additional relay coordinates matter before an observer even reaches the cryptography. A client address and port can recur behind different relays. The agent needs the relay context to distinguish initiating clients. A short field can therefore carry a substantial operational meaning: it locates an exchange within the network that brought it to the agent. It is not an inventory of people or a permanent identity for the device.

A verified correction makes the custody of that information unusually visible. Technical erratum 2996, reported in October 2011 and verified in September 2012, corrects the reply’s destination-port source to PaC-Information. The original sentence pointed to Relayed-Message. The correction identifies where the port actually resides; it does not create another authentication check or move a credential.

That small change is a useful antidote to the idea that all fields travelling together provide interchangeable evidence. An implementation can preserve the inner message faithfully and still need the right surrounding information to deliver it. A reviewer who verifies only the integrity of the payload has not inspected every condition under which the payload becomes usable.

Nor does the outer relay message establish a second reliability engine. Its session and sequence fields are zero, and PRY itself is not retransmitted. A retransmitted inner PANA message can instead travel in a new relay envelope. The absence of an outer sequence must not be read as the absence of sequencing in the actual endpoint protocol.

The base RFC 5191 places session handling, message validity and retransmission at the PANA endpoints. It also distinguishes the client, authentication agent, possible backend authentication infrastructure and enforcement point. Successful authentication with an exported master session key can establish a PANA security association. Without that key-producing result, the association is not created. The diagram is a division of work, not a list of synonyms for one trusted machine.

A resource estimate should respect the same division. Per-client memory avoided at the PRE is a specific saving. It does not measure packet-processing work, configured peer relationships or the additional state at the PAA. It also says nothing by itself about the engineering effort needed when a client can reach the parent but its admission exchange does not finish. A narrow saving can be real without being the system’s total saving.

An intact credential can accompany a failed service

The relay’s security story is easy to exaggerate in either direction. Calling the relay untrusted does not mean it can authenticate as any client. Calling endpoint authentication protected does not mean the relay cannot cause trouble.

The RFC’s threat analysis preserves that distinction. A rogue relay can interfere with delivery and change the agent’s stored relay return coordinates in the described circumstances. Completing initial authentication as the victim still requires the victim’s credentials; after authentication with a key-generating EAP method, spoofed inner messages fail integrity checks. These are properties and qualifications in the specification, not a claim that every implementation is flawless.

The operating implication is less dramatic than a stolen credential and more awkward than a clean security pass. An organization can avoid unauthorized admission while legitimate admission remains unavailable. The security team’s conclusion and the user’s complaint may both be correct. A process that admits only one of those observations will misdiagnose the boundary.

For example, a recovery policy built exclusively around replacing credentials could leave a delivery problem untouched. Conversely, changing a delivery path is not sufficient evidence to reset authentication requirements. These are hypothetical policy errors, not reported incidents. Their significance is that the two remedies belong to different owners and depend on different evidence.

An availability budget therefore needs a question beyond whether an adversary obtained a key. Can legitimate devices complete the exchange under the conditions the organization intends to support? If not, where does the failure begin, who can observe it, and who has authority to alter that part of the path? No percentage or universal answer follows from the RFC. The questions follow from keeping authentication and carriage distinct.

Optional does not mean unassigned

RFC 6345 makes cryptographic protection of the PRE–PAA segment optional at the protocol level. It nevertheless discusses residual risks that need physical or cryptographic mitigation and controls on legitimate peers. The deployment does not become responsibility-free because one particular protection is not universally mandatory.

Its historical IPsec discussion also distinguishes manually configured key management, with a replay-protection limitation, from IKE using preshared secrets, which it recommends supporting. Describing every use of a preshared secret as replay-unsafe would erase that distinction. Equally, the document’s 2011 choices should not be repackaged as a contemporary hardening recipe without a current, deployment-specific security assessment.

This is where procurement language can quietly exceed the engineering statement. “Optional” can describe a protocol’s interoperability requirement, an implementation feature, a deployment choice or a support contract. Those are four different decisions. The person removing a control from a bill of materials should know which decision is actually theirs to make.

A thin relay also needs a bounded role. The specification assumes at most one PRE and leaves dynamic PAA discovery by that relay outside its scope. An operator cannot derive an arbitrary chain of relays, automatic discovery or seamless recovery merely from support for the relay message. Additional capabilities require their own evidence rather than a generous reading of a familiar protocol name.

Discovery is not permission to weaken admission

The neighboring RFC 5192 gives DHCP a way to provide ordered candidate PAA addresses. Clients are to try them in the supplied order. Yet the options must not negotiate whether PANA authentication is required. Their presence or absence cannot safely be promoted into a choice to abandon the stronger admission process.

That is a useful constraint on the influence of a helper. Discovery can point a client toward a conversation without owning the rule that says whether the conversation is necessary. A delivery convenience should not silently inherit security policy. The same discipline applies to the relay’s location: being where messages pass is not equivalent to deciding who should be admitted.

Address interpretation needs care too. When channel binding uses a PAA address, the address visible to the client through the PRE differs from the one visible to the authentication server. The relay specification requires that circumstance to be considered. It notes a comparable case for a non-relayed, multihomed agent. A mismatch is consequently a question about the chosen binding model, not automatic evidence of an intruder.

Later specification work shows the relay was more than an isolated abstraction. The February 2016 home-and-building RPL profile in RFC 7733 places PANA and EAP-TLS in an authentication stack and gives the parent the relay role unless it is itself the authentication server. That proves a documented profile choice. It does not establish present market share, current product conformance or observed reliability.

A smaller component is not a smaller obligation

Lu Heng’s essay on minimal specification and local decisions argues for narrow common rules and verifiable boundaries. It explicitly says that a single administrative domain is a setting where its model is less directly applicable. It would be a category error to use that essay to deny a network operator’s legitimate admission function.

The more defensible application is analytical: keep the common transport role narrow, then identify the responsibilities that narrowness leaves elsewhere. His discussion of control and liability supplies a separate accountability lens. Neither essay evaluates PANA. The connection here is Daniel Kade’s interpretation, not an attributed protocol verdict or a legal finding.

For a buyer, the decisive comparison is not a philosophical contest between centralization and decentralization. It is between two complete operating arrangements. One may need fewer edge records and more capable central support; another may place more work near the client. Costs, recovery constraints and actual performance would need evidence from those arrangements. The standards alone cannot choose a winner.

They can prevent one bad comparison. A stateless relay is not the absence of a system that remembers. It is a particular place where remembering is unnecessary—and a reason to look carefully at the places where it remains necessary.