Summary

  • RFC 5113 separated discovery of a point of attachment, identity and credential choice, AAA routing, payload routing and service-capability discovery. A single “connected” indicator cannot prove all five.
  • Selection usually occurs before authentication, so keys derived from that authentication cannot protect the initial discovery. Some claims can be confirmed later; others may remain unconfirmable.
  • Realm hints are incomplete error-recovery inputs, not a dynamic routing protocol. Treating advertisements as hints rather than mandates lets a client enforce security policy instead of obeying a forged or stale claim.

The device sees two networks. One appears to offer the right access technology. It chooses an attachment point, selects a Network Access Identifier and presents the corresponding credential. Authentication begins. Only then does it learn that the service it wanted is unreachable, that the security posture differs from expectation, or that the selected identity sent the AAA exchange through the wrong roaming relationship.

The repair is expensive because the choice has already become state. The device must abandon a point of attachment, choose another network or identity and authenticate again. RFC 5113 described this as a structural ordering problem: selection information is most useful before authentication, while authentication is often what could make some of that information trustworthy.

Five surfaces hidden inside one choice

RFC 5113 divided “network selection” into operations that dashboards routinely collapse.

First, the device discovers points of attachment. It may hear advertisements passively or solicit them actively. Link-layer characteristics can be visible while roaming arrangements, service restrictions, end-to-end quality or charging remain unknown.

Second, it selects an identifier and credential. The NAI is not merely a label presented after the network is chosen. Its realm can influence which AAA infrastructure tries to reach the home server.

Third, the AAA conversation follows a route. More than one roaming path can reach the same home realm. Both may authenticate the same identity, while their commercial relationship, service policy and cost differ.

Fourth, payload packets may follow a different tunnel or route from the AAA exchange. Authentication success says that an exchange reached an authority willing to accept the credential. It does not reveal every intermediary or prove the subsequent data path.

Fifth, the network may or may not provide the service, security, quality, Internet access, emergency support or charging policy that motivated the selection.

Each surface needs its own receipt. Otherwise, a green authentication result is asked to certify decisions it never observed.

Identity selection was also route selection

The RFC's most useful conclusion is that credential selection and AAA routing are two views of the same identity-selection problem.

Choosing an identity determines more than who the user claims to be. The realm portion of the NAI helps the access network route the request. A person with credentials in two realms may be able to use different access networks. A single realm may be reachable through direct or indirect roaming relationships. The same credential can therefore be accepted along more than one economic and technical path.

This creates a false simplicity in the phrase “authentication succeeded”. Which identity was chosen? Which realm did it name? Which proxies handled the request? Which roaming agreement determined the payload tunnel? Which price and service policy attached to that path?

None of those questions makes successful authentication meaningless. It makes the receipt narrow. It proves acceptance of a credential in a particular exchange. Leadership error begins when that narrow fact is treated as proof that the preferred path, service or price was selected.

A realm hint was not a route table

RFC 4284 let an EAP identity exchange carry realm hints after a request encountered an unreachable realm. RFC 5113 was explicit about the limits. The list might omit routes because the packet had finite space or because routing information was confidential. A NAS observing it could not rely on the list as complete. The mechanism was not a dynamic routing protocol.

The document's preferred mental model was error recovery. A request fails to route. A core AAA proxy in the default-free zone returns information that may help the peer choose an alternate identity. That is different from continuously advertising a complete, current graph of reachable realms.

The location of the hint generator matters. If a NAS originates hints from a manually maintained realm table, the advertisement can drift from the core routing state. It may advertise an unreachable realm or omit one that has become reachable. When the core proxy that must route the request also generates the recovery hint, the information and the later action share fate.

Fate sharing is not infallibility. It is a narrower accountability improvement: the same control point is responsible for the claim and its use.

Discovery before trust

All the information required for a low-latency choice is wanted before authentication. Yet identity selection and network selection occur before authentication too. A peer disclosing every supported realm at that stage may reveal its credential portfolio in cleartext. An attacker observing the exchange can learn which institutions or providers the device can authenticate to.

The temporal boundary is unavoidable: a dynamic key derived by authentication cannot protect the discovery that must precede that authentication. Preconfigured symmetric keys or signature trust can protect advertisements, but that protection has its own distribution and lifecycle burden.

Later mechanisms can confirm some earlier claims. Channel binding can compare information seen outside the secure method with information vouched for inside it. A secure-association handshake can confirm another subset. But RFC 5113 warned that some advertised parameters may not be confirmable at all. If an attacker can advertise a weaker option that the later exchange never binds, the system faces a bidding-down risk.

The safe posture is therefore not blind obedience. Network advertisements are hints. The client retains a preconfigured security policy and may ignore a hint that conflicts with it. A claimed network name, method or capability does not become mandatory merely because it arrived first.

A successful attachment could still be the wrong outcome

Consider two roaming paths that both accept the credential. One is direct and one passes through a consortium. They can produce different charging, reachable services or payload routes. The access network may not know the user's full preference order; the home provider may not know the current point-of-attachment conditions; the device may not possess fresh price data.

This is not simply a problem of finding “the best network”. Best for whom, under which objective and with which evidence? The user can prefer price, the operator can prefer a commercial relationship, the application can require latency, and the security policy can reject an otherwise attractive attachment.

Route order silently resolves those conflicts when the system does not expose them. Authentication then makes the selected path appear legitimate, even though authentication did not choose the objective.

An operational design should record the objective alongside the outcome. If the client chose for security, show the policy match. If it chose for price, show the charging claim and whether it was later confirmed. If it chose for a service, show service reachability. A result without its objective cannot be audited.

Scalability was part of correctness

Realm discovery cannot be rescued by turning AAA into a probing system. RFC 5113 rejected periodic EAP identity probes as a way for a NAS to refresh a routing table. Probes add load precisely when an AAA server may already be overloaded. Retransmission can amplify the condition, while the returned hint remains incomplete.

Large route tables also create confidentiality and packet-size problems. Complete disclosure may expose commercial relationships. Partial disclosure cannot safely masquerade as completeness. Manual replication to every NAS creates stale-state risk. Source routes assembled from incomplete information may fail or be rejected because the required relationships do not exist.

Correctness therefore includes bounded work. A retry mechanism needs a limit. A hint needs provenance and age. A failure needs a counter rather than an unbounded loop. The network must distinguish “realm unknown here” from “identity rejected” and “path available but policy denied”. Those outcomes lead to different repairs.

The evidence ladder

The sequence is easy to shorten and dangerous to collapse:

  • a visible access point does not prove the desired network is behind it;
  • an advertised realm does not prove current AAA reachability;
  • a chosen NAI does not prove the preferred roaming path;
  • a routed AAA request does not prove authentication success;
  • successful authentication does not prove the advertised parameters;
  • confirmed network identity does not prove service reachability;
  • reachable service does not prove the expected charging policy;
  • a valid AAA route does not prove the intended payload route;
  • a working session does not prove the device selected the best available network.

RFC 5113 did not supply one protocol that closes every rung. Its value was to prevent a partial mechanism from being sold as the whole decision.

Sources