Realm-Based Redirection In Diameter
updates
- rfc-6733 — Diameter Base Protocol
Extracted elements (19)
An application specification may choose to allow realm-based redirection only on complete sessions beginning with the initial message, or on every message. The former avoids disruption of established stateful sessions; the latter allows redirection mid-session but will disrupt stateful existing sessions.
Realm-based redirection is defined as an application-specific mechanism rather than a function of the application-independent redirect agent defined in RFC 6733. This is because the base redirect agent cannot be application-aware, so a Diameter server or proxy that supports the relevant application must perform the redirection instead.
Support for realm-based redirection is indicated implicitly through application support discovered during the capabilities exchange phase. This avoids the need for a separate negotiation mechanism and ties the capability to applications that explicitly incorporate it by normative reference.
When S-NAPTR DNS-based dynamic peer discovery is used, realm-based redirection is already achievable by updating NAPTR resource records: the NAPTR RR for the desired application has an empty FLAG field and a REPLACEMENT field containing the new realm. This document's mechanism applies only when S-NAPTR peer discovery is not used.
A conforming client MUST be prepared to receive either DIAMETER_REALM_REDIRECT_INDICATION directly or a response from a realm differing from the one originally targeted. Upon receiving DIAMETER_REALM_REDIRECT_INDICATION, the client SHOULD follow the same rerouting steps prescribed for proxies.
A conforming proxy receiving DIAMETER_REALM_REDIRECT_INDICATION MUST attempt to reroute the original request to a server in a realm identified by a Redirect-Realm AVP; if rerouting fails, the proxy MUST forward the indication toward the client.
A Realm-based Redirect Server MUST be configured with an application that incorporates realm-based redirection, the Local Action field set to LOCAL, an application-specific field indicating realm-based redirection, and one or more target realm identities.
Realm-based redirection MAY be applied even if a Destination-Host AVP is present in the request, depending on operator policy.
The Realm-based Redirect Server MAY include a Redirect-Host-Usage AVP (which SHOULD be set to REALM_AND_APPLICATION); if this AVP is added, the Redirect-Max-Cache-Time AVP MUST also be included. This extends the normal usage of these AVPs as defined in RFC 6733 Sections 6.13 and 6.14.
When a Realm-based Redirect Server receives an applicable request, it MUST reply with an answer with the 'E' bit set (maintaining the Hop-by-Hop Identifier), MUST include Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION, and MUST include each alternate realm in a separate Redirect-Realm AVP instance.
DIAMETER_REALM_REDIRECT_INDICATION (result code 3011) is a Protocol Error code indicating that the request within an application supporting realm-based redirection could not be satisfied locally, and the initiator SHOULD direct the request to a peer within a realm identified in the response. When set, the Redirect-Realm AVP MUST be present.
The realm-based redirection extension consists of three elements: a new result code DIAMETER_REALM_REDIRECT_INDICATION (3011), a new AVP Redirect-Realm (620), and associated behavior at Diameter nodes implementing the specification.
The Redirect-Realm AVP (AVP code 620) is of type DiameterIdentity. It specifies a realm to which a node receiving a realm-based redirect indication SHOULD route the original request.
This specification allocates AVP code 620 for the Redirect-Realm AVP in the 'AVP Codes' registry under 'Authentication, Authorization, and Accounting (AAA) Parameters'.
This specification allocates result code value 3011 (DIAMETER_REALM_REDIRECT_INDICATION) in the 'Result-Code AVP Values (code 268) - Protocol Errors' registry under 'Authentication, Authorization, and Accounting (AAA) Parameters'.
A compromised Realm-based Redirect Server could redirect a large number of Diameter requests toward a victim domain, constituting a DoS attack. Use of secure peer-to-peer connections and authorization checks mitigates but does not fully prevent such attacks.
Because a Diameter proxy may change the Destination-Realm AVP during realm-based redirection, any cryptographic algorithm that uses the Destination-Realm AVP as input would be broken. Application specifications relying on such algorithms SHOULD NOT incorporate realm-based redirection.
Before redirecting a request toward a different realm, the client or proxy MUST ensure that authorization checks have been performed at each connection along the path to the realm identified in the redirect indication, per RFC 6733 Section 2.9.
Proxy rerouting on DIAMETER_REALM_REDIRECT_INDICATION: (1) select a realm from Redirect-Realm AVP instances; (2) locate and establish a route to a peer in that realm via normal discovery; (3) update routing cache, remove Destination-Host and Destination-Realm AVPs, add new Destination-Realm, and forward; (4) if steps 2-3 fail, try the next Redirect-Realm AVP instance.