Clarifications on the Routing of Diameter Requests Based on the Username and the Realm
updates
- rfc-3588 — Diameter Base Protocol
Extracted elements (18)
Backwards compatibility is maintained by design: non-compliant Diameter agents will not advertise support for new applications that implement the enhanced routing solution, and will therefore be bypassed rather than causing failures.
Decorated NAIs replicate NAI-based routing enforcement from RADIUS-based roaming networks (RFC 2486) into Diameter. Publicly available 3GPP and WiMAX specifications already assumed this functionality was fully supported by RFC 3588, necessitating this clarification.
Internationalized realm names (IDN) in NAIs should only be converted to ASCII-compatible encoding when DNS infrastructure is queried, not during Decorated NAI realm-placement processing. This keeps the NAI value unchanged during routing.
The answer processing path is intentionally left unmodified; only request routing is affected. This limits the scope of changes required to Diameter proxy implementations and preserves RFC 3588 answer handling semantics.
NAI decoration is not limited to network access authentication and authorization; it can be used with any Diameter application whose commands are proxiable and include the User-Name AVP with an NAI.
The Diameter Base Protocol (RFC 3588) NAI usage is based on RFC 4282, which allows multiple realms but does not define how Decorated NAIs should be handled by Diameter agents; this specification fills that gap.
This specification does not define a new Diameter application; it defines behavior common across all Diameter applications that require request routing based on Decorated NAIs. Existing non-compliant deployments are bypassed rather than broken.
After updating the User-Name AVP per the Decorated NAI, the Diameter agent MUST update the Destination-Realm AVP to match the new realm extracted from the updated User-Name AVP.
If the User-Name AVP contains a Decorated NAI, the Diameter agent MUST process the NAI as defined in RFC 4282 and update the value of the User-Name AVP accordingly.
If the User-Name AVP is present but the NAI is not decorated, the Diameter agent proceeds with normal RFC 3588 message processing without modifying the AVPs.
Implementations compliant with this specification MUST have a uniform way of interpreting Decorated NAIs. The character '!' (hexadecimal 0x21) is used to separate realms in the list of decorated realms within the NAI.
When a Diameter agent receives a request whose Destination-Realm it processes locally, it MUST inspect whether the User-Name AVP contains a Decorated NAI before handling the message locally.
A Decorated NAI is an NAI containing multiple realms used to specify a source route, formatted according to Section 2.7 of RFC 4282. Realms are separated by '!' and the final realm (home realm) follows '@' in the NAI.
After a Diameter agent processes a Decorated NAI, the request message is sent to the next hop using the normal request routing rules defined in RFC 3588, with the updated User-Name and Destination-Realm AVPs.
When a Diameter client originates a request, the Destination-Realm AVP is populated with the realm part of the NAI in the User-Name AVP (the realm given after the '@' character). The NAI may or may not be decorated at origination.
A malicious node may purposely create a malformed list of realms in a Decorated NAI, causing routing through realms unrelated to the original exchange or through non-existent realms. The request may traverse several hops before the invalid realm is discovered, creating unnecessary routing overhead.
NAI decoration is used in AAA infrastructures where Diameter messages traverse NAS-to-server paths via AAA brokers or proxies. The security of the end-to-end AAA communication relies on the security properties of all intermediate brokers and proxies.
A Diameter proxy processing a received request transitions through: (1) check if Destination-Realm is local; (2) inspect User-Name AVP for decoration; (3) if decorated, strip outermost realm from NAI and update Destination-Realm AVP; (4) forward using RFC 3588 routing. If not decorated, skip to normal RFC 3588 processing.