RFC 7075

Realm-Based Redirection In Diameter

📅 published November 2013, from ietf

Realm-Based Redirection In Diameter 🎀

okay bestie, this one is RFC 7075 and it's a Standards Track doc from November 2013 🦋. It's written by T. Tsou and R. Hao, with T. Taylor as editor (Ed.) 💅. Tsou and Taylor are at Huawei Technologies, Hao is at Comcast Cable, and the ISSN is 2070-1721 ✨. It updates RFC 6733 (Updates: 6733) 🌸.

Abstract ✨

so the Diameter protocol has this redirection thing 💅 where an application-independent "redirect agent" can point messages somewhere else. sometimes an operator wants to send messages to a whole alternate domain without listing out individual hosts 🙈. this doc specifies an application-specific mechanism that lets a Diameter server or proxy (a node) do that redirect when the Straightforward-Naming Authority Pointer (S-NAPTR) is not being used for dynamic peer discovery 🔥. the node doing this is called a "Realm-based Redirect Server" 👑.

this memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time Attribute-Value Pairs (AVPs) 💖.

Status of This Memo 🌈

this is an Internet Standards Track document ⭐.

it's a product of the Internet Engineering Task Force (IETF) 🫶. it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 👑. if you want more info on Internet Standards, check Section 2 of RFC 5741 🧚.

for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7075 🍓.

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 🦋.

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication 📜. please read these carefully, because they explain your rights and restrictions with respect to this document 🙏. any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ✨.

Table of Contents 📚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Support of Realm-Based Redirection Within Applications  . . .   4
3.  Realm-Based Redirection . . . . . . . . . . . . . . . . . . .   5
  3.1.  Configuration of the Realm-Based Redirect Server  . . . .   5
  3.2.  Behavior of Diameter Nodes  . . . . . . . . . . . . . . .   6
    3.2.1.  Behavior at the Realm-Based Redirect Server . . . . .   6
    3.2.2.  Proxy Behavior  . . . . . . . . . . . . . . . . . . .   6
    3.2.3.  Client Behavior . . . . . . . . . . . . . . . . . . .   7
  3.3.  The Redirect-Realm AVP  . . . . . . . . . . . . . . . . .   7
  3.4.  DIAMETER_REALM_REDIRECT_INDICATION Protocol Error Code  .   7
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   9

1. Introduction 🧚

the Diameter base protocol [RFC6733] has a basic redirection service that a redirect agent provides 💖. the redirect indication that comes back from the redirect agent is described in Section 6.1.8 and Sections 6.12 through 6.14 of [RFC6733] 📖. it hands the message sender one or more individual hosts as the destination of the redirected message 🌸.

but here's the tea 🫖. imagine an operator who offered a specific service and now doesn't want to anymore 😭. they've set up an alternative domain to provide the service instead 🦋. to make the switch smooth, the original operator keeps a redirect server around to tell the message sender which alternative domain the request should be sent to 💅. the thing is, the original operator shouldn't have to configure that redirect server with a list of hosts to contact in the alternative operator's domain 🙈. the original operator should just be able to give redirect indications for the domain as a whole 👑.

1.1. Terminology 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] ✨.

in this spec, "realm-based redirection" means a mode of operation where a realm, instead of an individual host, is returned as the redirect indication 🦋.

"Realm-based Redirect Server" is the Diameter node (Diameter server or proxy) that returns the realm-based redirection 👑. its behavior is a slight tweak on the basic redirect agent behavior from Section 6.1.8 of [RFC6733] 💜.

this document uses a bunch of terms the same way [RFC6733] does: "Diameter client", "Diameter node", "Diameter peer", "Diameter server", "proxy", "realm" or "domain", "redirect agent", and "session" (as defined in Section 1.2), plus "application", which is defined implicitly by Sections 1.3.4, 2.3, and 2.4 🌈.

2. Support of Realm-Based Redirection Within Applications 💅

the DNS-based dynamic peer discovery mechanism in the Diameter base protocol [RFC6733] gives you a simple way to do realm-based redirection using the S-NAPTR DDDS application [RFC3958] 🧚. when S-NAPTR is used for peer discovery, you can redirect Diameter requests from the original realm to a new realm by updating the existing NAPTR resource records (RRs) for the original realm like this 🦋: the NAPTR RR for the desired application(s) and supported application protocol(s) provided by the new realm has an empty FLAG field, and the REPLACEMENT field holds the new realm to use for the next DNS lookup 🍓. the new realm can be arbitrary 🌸. the restriction in [RFC6733] that the NAPTR replacement field match the domain of the original query does not apply for realm-based redirect purposes 🙈.

however, using DNS-based dynamic peer discovery is optional for Diameter implementations 🫶. for deployments that don't use S-NAPTR peer discovery, support for realm-based redirection needs to be specified as part of the functionality a Diameter application supports 📜. that way, support of the Diameter application (found during the capabilities exchange phase defined in the Diameter base protocol [RFC6733]) implicitly indicates support for the realm-based redirection mechanism ✨. a new application specification can bring in the mechanism specified here by making it mandatory to implement for the application and referencing this specification normatively 👑.

the big deal: if realm-based redirection is an application-specific behavior, a basic redirect agent from [RFC6733] can't do it. it MUST be performed instead by an application-aware Diameter node (Diameter server or proxy), which this doc calls a "Realm-based Redirect Server" 🔥.

an application can say whether realm-based redirection works only on complete sessions that start with the initial message, or on every message within the application, even if earlier messages in the same session weren't redirected 💖. this distinction only matters when realm-based redirection is first kicked off 🧚. in the first case, existing sessions won't get disrupted when realm-based redirection gets deployed 🌈. in the second case, existing sessions will be disrupted if they're stateful 😭.

3. Realm-Based Redirection 🦋

this section specifies an extension to the Diameter base protocol [RFC6733] to get realm-based redirection working 💅. the pieces of this solution are:

  • a new result code, DIAMETER_REALM_REDIRECT_INDICATION (3011) 🌸;
  • a new attribute-value pair (AVP), Redirect-Realm (620) 💖; and
  • associated behavior at Diameter nodes that implement this specification 👑.

this behavior includes the optional use of the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs ✨. in this doc, these AVPs apply to the peer discovered by a node acting on the redirect server's response, which is an extension of their normal usage as described in Sections 6.13 and 6.14 of [RFC6733] 🎀.

Section 3.2.2 and Section 3.2.3 describe how a proxy or client may update its routing table for the application and initial realm after it selects a peer in the new realm following realm-based redirection 🧚. heads up, though: the proxy or client will then automatically route later requests for that application to the new realm (except maybe requests within sessions already established with the initial realm) until the cached routing entry expires 🙈. keep this in mind if the rerouting is meant to be temporary ⏳.

3.1. Configuration of the Realm-Based Redirect Server 🌈

a Diameter node (Diameter server or proxy) acting as a Realm-based Redirect Server MUST be configured as follows to run realm-based redirection 🔥:

  • configured with an application that incorporates realm-based redirection 💅;
  • the Local Action field of the routing table described in Section 2.7 of [RFC6733] is set to LOCAL 🦋;
  • an application-specific field is set to indicate that the required local action is to perform realm-based redirection 🍓;
  • an associated application-specific field is configured with the identities of one or more realms to which the request should be redirected 👑.

3.2. Behavior of Diameter Nodes 💖

3.2.1. Behavior at the Realm-Based Redirect Server

okay so bestie, remember how Section 2 talked about this? 🎀 An application can say realm-based redirection only kicks in for complete sessions starting from the initial message (so established sessions don't get disrupted 🫶), OR it can apply to every single message in the app, even if earlier messages in the same session weren't redirected 👀.

If a Realm-based Redirect Server set up the way Section 3.1 describes gets a request that realm-based redirection applies to, it MUST reply with an answer message that has the 'E' bit set 🔥, and it MUST keep the Hop-by-Hop Identifier in the header. It MUST also include the Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION 💅, and it MUST include the alternate realm identifier(s) it was configured with, each one in its own Redirect-Realm AVP instance ✨.

The Realm-based Redirect Server MAY include a copy of the Redirect-Host-Usage AVP 🧚, and if it does, that AVP SHOULD be set to REALM_AND_APPLICATION. If this AVP gets added, the Redirect-Max-Cache-Time AVP MUST also be included 🌸. Heads up that these AVPs apply to the peer discovered by a node acting on the server's response (more on that in the next section) 👀. This is a bit of an extension of how they normally work, as described in Sections 6.13 and 6.14 of [RFC6733] 💜.

Realm-based redirection MAY be applied even if a Destination-Host AVP is present in the request, depending on the operator-based policy. 🙈

3.2.2. Proxy Behavior

A proxy that follows this spec and gets an answer message with the Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION MUST try to reroute the original request to a server in a realm named by a Redirect-Realm AVP instance in that answer 🦋. If that fails, it MUST forward the indication toward the client 💖. To reroute, it MUST do the following:

  1. Pick one specific realm from the ones listed in the Redirect-Realm AVP instances in the answer message 🌈.
  2. If that worked, find and set up a route to a peer in the realm given by the Redirect-Realm AVP, using the normal discovery steps in Section 5.2 of [RFC6733] 🔍.
  3. If that worked too: A. Update its cache of routing entries for the realm and application the original request was aimed at, taking into account the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs if they're in the answer 🗂️. B. Remove the Destination-Host (if present) and Destination-Realm AVPs from the original request, then add a new Destination-Realm AVP containing the realm picked in the first step 🎀. C. Forward the modified request 🚀.
  4. If either step 2 or step 3 fails and the original answer had more realms, pick another Redirect-Realm AVP instance from that answer and repeat steps 2-3 for the realm it names 😭.

3.2.3. Client Behavior

A client that follows this spec MUST be ready to get either an answer message with a Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION, OR, as a result of proxy action, some other result from a realm that's different from the one it sent the original request to 🫠. When it gets DIAMETER_REALM_REDIRECT_INDICATION, the client SHOULD follow the same steps the previous section lays out for a proxy 💅. The goal is to update its routing table AND get service for the original request 🔥.

3.3. The Redirect-Realm AVP

The Redirect-Realm AVP (620) is of type DiameterIdentity. It specifies a realm where a node that receives a redirect indication containing the result code value DIAMETER_REALM_REDIRECT_INDICATION and the Redirect-Realm AVP SHOULD route the original request 🧚.

3.4. DIAMETER_REALM_REDIRECT_INDICATION Protocol Error Code

The DIAMETER_REALM_REDIRECT_INDICATION (3011) Protocol error code means a server figured out that the request, inside an application that supports realm-based redirection, couldn't be handled locally 🙅‍♀️. The initiator of the request SHOULD send it directly to a peer in a realm that's been named in the response 🎯. When this code is set, the Redirect-Realm AVP MUST be present 💜.

4. Security Considerations ⚠️

The general recommendations in Section 13 of the Diameter base protocol [RFC6733] apply here 🔐. The specific security recommendations for the realm-based redirection defined in this document are below 👇.

Realm-based redirection changes the business relationship between organizations 🏢. Before redirecting a request toward a realm that's different from the initial realm, the client or proxy MUST make sure the authorization checks have been done at each connection along the path toward the realm named in the realm-based redirect indication 🚧. Details on setting up the Diameter authorization path are in Section 2.9 of [RFC6733] 📜. Section 13 of [RFC6733] gives recommendations on how to authenticate and secure each peer-to-peer connection (using TLS, DTLS, or IPsec) along the way, which allows the necessary hop-by-hop authorization checks 🔒.

Even though the administrative domains are assumed to be secure, a compromised Diameter node acting as a Realm-based Redirect Server could redirect a huge number of Diameter requests toward a victim domain, which would then get flooded with unwanted Diameter requests 😱🚨. Secure Diameter peer-to-peer connections and authorization checks are still the discouraged option for this attack, since they'd let a potential victim domain figure out where the attack is coming from 🕵️‍♀️. That alone, though, doesn't stop the DoS attack 💀.

Because realm-based redirection in this document means the Destination-Realm AVP in a client-initiated request can be changed by a Diameter proxy on the path between client and server, any cryptographic algorithm that uses the Destination-Realm AVP as input to the calculation done by the client and server would be broken by this form of redirection 💔. Application specifications that rely on such cryptographic algorithms SHOULD NOT incorporate this realm-based redirection 🙅‍♀️.

5. IANA Considerations 🗂️

This specification allocates a new AVP code, Redirect-Realm (620), in the "AVP Codes" registry under "Authentication, Authorization, and Accounting (AAA) Parameters" 🎀.

This specification allocates a new Result-Code value, DIAMETER_REALM_REDIRECT_INDICATION (3011), in the "Result-Code AVP Values (code 268) - Protocol Errors" registry under "Authentication, Authorization, and Accounting (AAA) Parameters" ✨.

6. Acknowledgements 🫶

Glen Zorn, Sebastien Decugis, Wolfgang Steigerwald, Mark Jones, Victor Fajardo, Jouni Korhonen, Avi Lior, and Lionel Morand contributed comments that helped shape this document 💖. As shepherd, Lionel added a second set of comments that polished the document before it went to the IESG 💅. Benoit Claise picked up extra points that were quickly resolved with Lionel's help 🌸. During IETF Last Call Review, Enrico Marocco caught some important editorial corrections 📝. Stefan Winter contributed text on using S-NAPTR as an alternative method of realm-based redirection already specified in [RFC6733] 🧭. Derek Atkins did a review on behalf of the Security Directorate 🔐. Lionel noted one more correction 🙌.

Finally, this document benefited from comments and discussion raised by IESG members Stewart Bryant, Stephen Farrell, Barry Leiba, Pete Resnick, Jari Arkko, and Sean Turner during IESG review 👑.

The authors are so grateful to Lionel Morand for his active role as document shepherd. At each stage he worked to summarize and resolve comments, which made the editor's role easy. Thank you, Lionel 🥹🫶.

7. References 📚

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.

7.2. Informative References

[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.

Authors' Addresses 📮

Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA

Phone: +1 408 330 4424 EMail: Tina.Tsou.Zouting@huawei.com URI: http://tinatsou.weebly.com/contact.html

Ruibing Hao Comcast Cable One Comcast Center Philadelphia, PA 19103 USA

Phone: +1 215 286 3991(O) EMail: Ruibing_Hao@cable.comcast.com

Tom Taylor (editor) Huawei Technologies Ottawa Canada

EMail: tom.taylor.stds@gmail.com

📦 where this page comes from