RFC 6159
Session-Specific Explicit Diameter Request Routing
RFC 6159: Session-Specific Explicit Diameter Request Routing ✨
okay bestie, so this is an Informational doc, which means it's a Independent Submission (not an official Internet Standard 💅). It came out in April 2011 with ISSN 2070-1721 🎀. The authors are T. Tsou from Huawei Technologies (USA), G. Zorn from Network Zen, and T. Taylor, Ed. from Huawei Technologies 🫶. The title block doesn't list anything it obsoletes or updates, so there's no other RFC it's replacing or patching 🌸.
Abstract 🦋
This doc describes a mechanism that lets specific Diameter proxies stay in the path for every message exchange that makes up a Diameter session. It's giving "stay on the bus until your stop" energy 🚌✨
Status of This Memo 💜
This is not an Internet Standards Track specification. It's published just for info, so don't treat it like a standard 💀
This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about its value for implementation or deployment. Docs approved by the RFC Editor aren't a candidate for any level of Internet Standard; see Section 2 of RFC 5741 🍓
For current status, errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6159 🔥
IESG Note 🙈
Okay so this part is kind of a big deal. Techniques like the ones in this doc were talked about in the IETF Diameter Maintenance and Extensions (DIME) Working Group. The group didn't have consensus that the problems these techniques fix are a real concern in Diameter deployments 😭 Also, there wasn't consensus that the proposed solutions line up with the architectural principles of the Diameter protocol. So the working group decided not to do the work. Nobody formally asked for this from any standards body either. This RFC is basically a continuation of that abandoned work 💀
Readers should know the IETF hasn't reviewed this spec, so it can't say anything about whether it's suitable for a particular purpose or whether it's compatible with the Diameter architecture and other extensions 🫠
Copyright Notice 🎀
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date it was published. Please actually read those, because they spell out your rights and restrictions for this document 🙏
Table of Contents 🧚
1. Introduction ....................................................2
2. Terminology .....................................................3
3. The 3GPP Wireless LAN (WLAN) Access Architecture ................4
3.1. Maintaining the Routing Path ...............................5
4. Diameter Explicit Routing (ER) ..................................6
4.1. Originating a Request (ER-Originator) ......................6
4.2. Relaying and Proxying Requests (ER-Proxy) ..................8
4.3. Receiving Requests (ER-Destination) .......................10
4.4. Diameter Answer Processing ................................11
4.5. Failover and Failback Considerations ......................12
4.6. Attribute-Value Pairs .....................................12
4.6.1. Explicit-Path-Record AVP ...........................12
4.6.1.1. Proxy-Host AVP ............................13
4.6.1.2. Proxy-Realm AVP ...........................13
4.6.2. Explicit-Path AVP ..................................13
4.7. Error Handling ............................................13
5. Example Message Flow ...........................................14
6. RADIUS/Diameter Protocol Interactions ..........................16
7. Security Considerations ........................................17
8. Acknowledgements ...............................................17
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................181. Introduction ✨
So in the Diameter base protocol [RFC3588], routing of request messages is based only on the routing decisions each node makes separately along the path. [RFC5729] added a way to force messages through a specified set of realms using Network Access Identifier (NAI) decoration 🎀 But no other spec gives you a way to force routing through a specific set of agents. So if there are multiple paths from source to destination, nothing guarantees that all messages for a given session take the same one 🛤️ Usually that's fine, but some architectures (like WLAN Third Generation Partnership Project (3GPP) IP access [TS23.234]) need that once certain agents get involved in a session, they can handle every message after that for the session 👑
Here's the tea though: this solution is valid, but it breaks one of Diameter's core vibes, which is how robust its architecture is 😭 With normal Diameter routing, sessions survive failures of agents along the routing path. With the proposals in this doc, routing gets pinned to specific agents, and if one of them fails, the session ends 💀
The authors don't see any interaction between explicit routing and the specific applications it's used with. So in principle, it can be added to existing applications if they support the necessary extensibility, and it can also be used with new applications 🌈
2. 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] 🫶
These terms define the functionality and participants in the routing extensions described in this doc 🧚
- ER Explicit routing. It's the mechanism this spec gives to proxies that the initial message of a session goes through, so they can make sure they stay on the messaging path for all later request messages in that session 🛣️
- ER-Proxy A proxy that implements the ER mechanism, so it can use it to stay in the path for later messages in a session 🦋
- ER-Destination A Diameter node that can take part in ER and that will ultimately consume the request sent by an ER-Originator 🎯
- ER-Originator A Diameter node that starts a session and sends the requests. The ER-Originator can be any Diameter node that sends a request, so a client, server, or proxy that can start sessions and take part in ER 🌸
- Authentication, Authorization, and Accounting (AAA) Relays Other Diameter nodes sitting between the ER-Originator, ER-Proxies, and the ER-Destination. These are existing Diameter agents and proxies that don't take part in ER and don't recognize Explicit-Path Attribute Value Pairs (AVPs) 🙈
3. The 3GPP Wireless LAN (WLAN) Access Architecture 🌈
The 3GPP WLAN IP access architecture [TS23.234] is one example of a system where certain agents (stateful proxies, in this case) have to stay in the forwarding path for all session messages 💜 The 3GPP WLAN interworking architecture extends 3GPP services to the WLAN access side, so a 3GPP subscriber can use a WLAN to get to 3GPP services. Very cool, very useful 🫶
WLAN AAA handles authenticating and authorizing access to the WLAN through the 3GPP system. This access control can either permit or deny a subscriber access to the WLAN system and/or the 3GPP system 🔐
There are two 3GPP WLAN interworking reference models 🍓
- In the non-roaming case, the model includes the WLAN access network and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control as well as charging.
- In the roaming case, the model includes the WLAN access network, the 3GPP AAA proxy in the visited network, and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control. Charging records may be generated by the AAA proxy and/or the AAA server. The AAA proxy relays access control and charging messages to the AAA server. The AAA proxy will also do offline charging, if required.
The roaming case brings up two problems that the Diameter routing mechanism in [RFC3588] doesn't give any unambiguous and standard solution for 😭
- Network Selection Picking an initial message path for the Diameter session through (possibly many) alternative visited networks to the home network 🗺️
- Explicit Routing (ER) Keeping the chosen message path for all messages in the Diameter session 🔒
Picking the initial message path is outside this doc's scope. The way to keep the chosen message path is described in detail below ✨
3.1. Maintaining the Routing Path 🛤️
Once authentication succeeds, a Diameter session gets set up with (at least) these stateful entities:
- the Diameter client in the WLAN access node (e.g., the 3GPP AAA client in the terminal visited network),
- a Diameter proxy in the visited mobile network (e.g., the 3GPP AAA proxy in the terminal visited network), and
- a Diameter server in the user's home realm (e.g., the destination 3GPP AAA server in the terminal home network).
Routing for the initial session request uses the normal Diameter routing tables (Section 2.7 of [RFC3588]) in the 3GPP AAA client, the 3GPP AAA proxy in the visited network, and any intermediate proxies after that. The 3GPP AAA client sends the initial session request to the 3GPP AAA proxy in the visited network. The 3GPP AAA proxy processes the request, then forwards it toward the destination 3GPP AAA server, through an intermediate proxy if necessary. The request may be forwarded through other intermediate proxies in the same way, until it reaches the destination 3GPP AAA server in the terminal home network 🚀
The functions given to the 3GPP AAA proxy include:
- Reporting charging information to the offline charging system in the visited network,
- Policy enforcement based on roaming agreements, and
- Service termination initiated by the visited network's operator.
All of these functions require that state be kept within the visited network. The 3GPP's choice is to keep that state at the 3GPP AAA proxy. That means the proxy must remain in the messaging path for all later messages relating to the same session 💖
4. Diameter Explicit Routing (ER) 🦋
okay bestie, this section is where the Diameter Explicit Routing (ER) magic happens ✨ The idea is that Diameter nodes who opt into ER can stay in the path of every request for a specific session 💅 There's a brand new Explicit-Path AVP that lets ER participants tweak the Destination-Host and/or Destination-Realm AVPs in request messages so routing does the right thing 🎀 The next sections explain how ER extends the request routing in [RFC3588] 🌸 The iconic part? It uses the routing strategies that already exist in [RFC3588] and doesn't force anyone to change them 🫶 It's loose source routing, not strict: later messages in a session get pushed through the participating nodes, but not through any individual non-participating nodes. Only Diameter nodes that actually want to take part in ER get involved in it 💖
4.1. Originating a Request (ER-Originator) 🧚
A Diameter node acting as an ER-Originator for a particular session MUST maintain a local cache that lists all the Diameter identities of the ER-Proxies that request messages have to traverse on the way to the ER-Destination 📝 The identity of a Diameter node is defined in [RFC3588]. The local cache MAY also include the node's realm 🌷 How the cache is structured is up to the implementation, and it SHOULD persist as part of the session attributes or properties 💜
An ER-Originator sending request messages MUST add an Explicit-Path AVP to those requests 🎀 The contents of the cache SHOULD be used to fill the Explicit-Path AVP, with each cached entry represented by its own instance of the Explicit-Path-Record AVP 💅 ER-Proxies along the path of the request message MUST examine the contents of the Explicit-Path AVP and make routing adjustments based on the records in it 🔥 There's an example of the message flow in Section 5. Also, the ER-Originator can be any Diameter node: a client, a server, or a proxy 👑
The ER-Originator can fill its cache either by pre-configuring it or by using the first request message of the session to gather the identities of participating ER-Proxies along the routing path. That second scheme is called Explicit-Path discovery 🔍 Pre-configuring works if the ER-Originator explicitly knows which ER-Proxies the request messages have to traverse. Otherwise, it can use Explicit-Path discovery. It is RECOMMENDED that Explicit-Path discovery be used whenever possible, since pre-configuration is less flexible by nature 🌈
Explicit-Path discovery is useful when the identities of the ER-Proxies aren't known, or when there are several ER-capable proxies (a cluster of proxies) that can be picked dynamically based on other routing policies 🧁 With discovery, the ER-Originator's cache starts out empty. To kick things off, when the ER-Originator sends the first request message of a session, it MUST include the Explicit-Path AVP containing a single Explicit-Path-Record AVP with the identity and/or the realm of the ER-Originator 🫶 The ER-Originator MUST set the Destination-Host and/or Destination-Realm AVP of the request message to the identity and/or the realm of the ER-Destination, respectively, as specified in [RFC3588] 💖
Note: ER-Originator initial request message routing procedures and the process of populating the Destination-Realm may be affected by the User-Name AVP NAI decoration [RFC5729]. NAI decoration is a form of request message source routing, and it defines realms that the request message must traverse before routing towards the ER-Destination. Diameter nodes participating in request message routing must examine and process the User-Name AVP, and modify the Destination-Realm AVP accordingly as long as there are realms left in the decorated NAI. Source routing based upon NAI decoration does not affect Explicit-Path discovery as defined in this document. 🙈
If the path taken by the initial request runs into one or more participating ER-Proxies and a participating ER-Destination, the procedures in Section 4.2 and Section 4.3 make sure that a successful response to that request contains an Explicit-Path AVP. That AVP includes one or more Explicit-Path-Records with the ER-Originator's identity, the identities of all participating ER-Proxies, and the identity of the ER-Destination ✨ The ER-Originator SHOULD populate its local cache with the contents of the Explicit-Path AVP received in this initial answer message 🦋
If the answer message doesn't contain an Explicit-Path AVP, or the Result-Code AVP is set to DIAMETER_ER_NOT_AVAILABLE (Section 4.7), that's the signal for the ER-Originator that the destination of the request doesn't support ER. The ER-Originator SHOULD avoid sending an Explicit-Path AVP in subsequent request messages 🙅♀️
If the initial request message started Explicit-Path discovery, but the Explicit-Path AVP in the answer message only has Explicit-Path-Records for the ER-Originator and ER-Destination, that means there are no Diameter proxies able to take part in ER along the path. In that case, the ER-Originator SHOULD NOT send an Explicit-Path AVP in subsequent request messages of this session 😭 See Section 4.5 for more discussion. This situation may be transient, though, and Explicit-Path discovery may find participating proxies in succeeding sessions. It's up to the ER-Originator to decide whether Explicit-Path discovery should be attempted in succeeding sessions 🧚
Once the ER-Originator's local cache is populated, whether through pre-configuration or Explicit-Path discovery, all request messages for the session MUST include the Explicit-Path AVP using the contents of the local cache 💅 The Explicit-Path AVP MUST contain the Explicit-Path-Records of all the nodes enumerated in the cache, except the ER-Originator's own record 🌸 The identities listed in the Explicit-Path AVP MUST appear in the order they will be traversed in the routing path 🛣️ The last entry in the Explicit-Path AVP MUST be the Explicit-Path-Record of the ER-Destination 👑 On top of that, the value of the Destination-Host (and possibly the Destination-Realm) in the request message MUST be copied from the values of the Proxy-Host AVP and, if present, the Proxy-Realm AVP of the first Explicit-Path-Record AVP in the Explicit-Path AVP 🎀
Note: This makes sure the ER-Originator, plus any AAA relays between the ER-Originator and the first ER-Proxy, will route the message towards the first ER-Proxy, as specified in RFC 3588 [RFC3588]. 💖
Whatever the first ER-Proxy does once it receives the message is covered in Section 4.2, and it mimics what the ER-Originator does 🔥
Answer messages that the ER-Originator gets for subsequent request messages, after the Explicit-Path has been established, SHOULD NOT have an Explicit-Path AVP. If they do, that SHOULD be considered a suspect condition that may be caused by a misbehaving ER participant 🙈 It's up to the ER-Originator whether to keep using the ER scheme when that happens, or to attempt another Explicit-Path discovery in later sessions 🫶
4.2. Relaying and Proxying Requests (ER-Proxy) ✨
okay so the basic move for an ER-Proxy when a request lands is to check whether explicit routing is supported in that request. If it is, the ER-Proxy checks whether it's already a participant in explicit routing for that request. If it's not an existing participant, Explicit-Path discovery is in progress, and it wants to join in, it tacks an Explicit-Path-Record AVP with its own identity onto the end of the Explicit-Path AVP 💅. If it is already a participant, the ER-Proxy pops/removes the Explicit-Path-Record AVP that belongs to itself from the Explicit-Path AVP and then uses the next Explicit-Path-Record AVP for routing from there. The details are below, bestie 🫶
An ER-Proxy is not required to keep local state or cache state about the explicit routing procedure. 🧚 However, it MUST check whether an incoming request contains an Explicit-Path AVP. Here are the cases that can happen:
- No
Explicit-PathAVP in the incoming request? Then the ER-Proxy takes no action beyond processing and forwarding the request as specified in [RFC3588]. Easy, nothing extra 🌸 - If the incoming request does contain an
Explicit-PathAVP, the ER-Proxy MUST check whether its identity is present in that AVP. To figure this out, it matches its identity against theProxy-HostAVP in eachExplicit-Path-Record. If its identity is not present, then:- A. If it wishes to participate in explicit routing, the ER-Proxy MUST verify that Explicit-Path discovery is in progress. It does this by checking that the
Proxy-HostAVP in the firstExplicit-Path-RecordAVP in theExplicit-PathAVP does not match theDestination-HostAVP (if present). If that verification succeeds, or theDestination-HostAVP is absent, the ER-Proxy MAY append a newExplicit-Path-Recordas the last AVP in theExplicit-PathAVP before forwarding the request. The newExplicit-Path-RecordMUST contain aProxy-HostAVP set to the proxy's identity, and MAY contain aProxy-RealmAVP giving the proxy's realm. If, however, theDestination-HostAVP is present and matches theProxy-HostAVP of the firstExplicit-Path-RecordAVP, then theExplicit-Pathcontains an already-defined source route that does not include the ER-Proxy. The ER-Proxy SHOULD process the request as if the ER-Path AVP were absent. 🙈 - B. If the ER-Proxy does not wish to participate in the ER, it SHOULD NOT modify the
Explicit-PathAVP. It SHOULD simply process and forward the request as specified in [RFC3588], using the existing values of theDestination-Hostand/orDestination-RealmAVPs. Non-ER-Proxies and relays that don't support ER and don't recognize theExplicit-PathAVP will take the same action.
- A. If it wishes to participate in explicit routing, the ER-Proxy MUST verify that Explicit-Path discovery is in progress. It does this by checking that the
- If the identity of the ER-Proxy is present in the
Explicit-PathAVP, then:- A. If it is not the first
Explicit-Path-Recordin the AVP, this MUST be considered an error. An answer message with the 'E' bit set and the Result-Code set toDIAMETER_INVALID_PROXY_PATH_STACKMUST be sent back to the ER-Originator (Section 4.7). 💀 - B. If the identity of the ER-Proxy matches the first
Explicit-Path-Record, the ER-Proxy MUST remove this record from theExplicit-PathAVP. It then repopulates theDestination-Hostand possibly theDestination-RealmAVP from the nextExplicit-Path-Recordpresent in theExplicit-PathAVP. Setting theDestination-Hostand possibly theDestination-RealmAVP makes sure that the ER-Proxy, as well as all AAA relays between the current ER-Proxy and the next ER-Proxy listed in theExplicit-PathAVP, route the message towards the next ER-Proxy. Removing the ER-Proxy's record is basically like popping an entry off a stack, represented by theExplicit-PathAVP. Stack vibes 📚
- A. If it is not the first
The behavior specified above also applies to a Diameter node that acts as a relay agent and participates in the ER scheme. 🦋
4.3. Receiving Requests (ER-Destination)
A Diameter node that locally processes requests sent by the ER-Originator (Section 4.1), and is able to support ER (an ER-Destination), MUST check for the presence of an Explicit-Path AVP in the request message. 👑
- If an incoming request does not contain an
Explicit-PathAVP, that's a sign that messages in this session won't use ER. The ER-Destination MUST simply process the request for local consumption and formulate an answer message as specified in [RFC3588]. ✨ - If the incoming request contains an
Explicit-PathAVP, the ER-Destination MUST check whether its identity is present in that AVP. If its identity is not present, which means Explicit-Path discovery is in progress, then:- A. If it wishes to participate in the ER, and subject to paragraph B below, the ER-Destination MUST append a new
Explicit-Path-Recordto theExplicit-PathAVP in the received message. The newExplicit-Path-RecordMUST contain at the least aProxy-HostAVP set to the ER-Destination's identity. The ER-Destination MUST then copy the resultingExplicit-PathAVP to the subsequent answer message. 🎀 - B. If there is only one
Explicit-Path-Recordin the incomingExplicit-PathAVP, that's a sign of a successful Explicit-Path discovery, but with no participating ER-Proxies. The ER-Destination SHOULD NOT copy theExplicit-PathAVP into the subsequent answer message. 🙃 - C. If the ER-Destination supports ER but does not wish to, or cannot, participate, it MAY send a Result-Code AVP set to
DIAMETER_ER_NOT_AVAILABLE, as defined in Section 4.7. The ER-Destination MUST NOT include anyExplicit-PathAVP in the subsequent answer. Diameter servers that don't support ER and don't recognize theExplicit-PathAVP will also leave theExplicit-PathAVP out of the answer message.
- A. If it wishes to participate in the ER, and subject to paragraph B below, the ER-Destination MUST append a new
- If the identity of the ER-Destination matches a record in the
Explicit-PathAVP, then it MUST be the onlyExplicit-Path-Recordpresent in theExplicit-PathAVP. Otherwise, this MUST be considered an error. An answer message with the 'E' bit set and containing anExperimental-Result-CodeAVP set toDIAMETER_INVALID_PROXY_PATH_STACKMUST be sent back to the ER-Originator (Section 4.7). If the identity of the ER-Destination does match the only existingExplicit-Path-Record, then the request reached the ER-Destination by way of a successfully executed explicit route 🎉. The ER-Destination MUST NOT include theExplicit-PathAVP in the subsequent answer message.
4.4. Diameter Answer Processing
There's no requirement on Diameter nodes taking part in ER to give answer messages any special handling or routing. 💅 Answer messages SHOULD be processed normally, as specified in [RFC3588]. Still, a Diameter node acting as an ER-Destination MUST formulate a proper Explicit-Path AVP in answer messages, as described in Section 4.3. 🫶
4.5. Failover and Failback Considerations
If there's no ER-Proxy along the selected path, the answer message MAY contain an Explicit-Path AVP that holds only the Explicit-Route-Records of the ER-Originator and the ER-Destination. That tells you there's no ER support on the Diameter nodes along the path 🥲. It's up to the ER-Originator to keep processing the request without ER support, or to end the session. In that case the ER-Originator SHOULD NOT try Explicit-Path discovery in later request messages of this session. This protects against failback situations where an ER-Proxy suddenly shows up in the path and tries to add a new Explicit-Path-Record to request messages other than the initial one. 🛡️
ngl, letting an ER-Proxy join the session after the initial request only makes sense if the application requirements don't mandate that every participating ER-Proxy receive all of the messages in a session.
Still, depending on local policy, the ER-Originator MAY attempt ER path discovery in later sessions, even if the earlier attempt had no proxy participants. 🔁
If a failover happens in a Diameter node in front of an ER-Proxy after the Explicit-Path is already established, the ER-Originator might get a DIAMETER_UNABLE_TO_DELIVER error. That happens if there are no alternative paths towards the ER-Proxy. In that case, it's up to the ER-Originator to handle the error as specified in the Diameter application or in [RFC3588]. 😭
4.6. Attribute-Value Pairs
The following sections define the AVPs used in the ER process. All of these AVPs MUST have the 'V' bit set and the 'M' bit cleared, with the Vendor-ID field set to 2011 (as assigned by IANA in "Private Enterprise Numbers" registry; see http://www.iana.org/). 🍓
4.6.1. Explicit-Path-Record AVP
The Explicit-Path-Record AVP (AVP Code 35001) is of type Group. The identity added in the Proxy-Host [RFC3588] element of this AVP MUST be the same as the one advertised by the Diameter node in the Origin-Host AVP during the Capabilities Exchange messages. 🌈
Explicit-Path-Record ::= < AVP Header: 35001 >
{ Proxy-Host }
[ Proxy-Realm ]4.6.1.1. Proxy-Host AVP
The Proxy-Host AVP (AVP Code 35004) is of type DiameterIdentity. It identifies the ER node that is inserting the record. The Proxy-Host AVP MUST be present. 🧚
4.6.1.2. Proxy-Realm AVP
The Proxy-Realm AVP (AVP Code 35002) is of type DiameterIdentity, and contains the realm of the ER node inserting the record. The Proxy-Realm AVP MAY be present in the Explicit-Path-Record. If it is present, the realm name included in the value of the Proxy-Host AVP MUST match the value of the Proxy-Realm AVP. 🎀
4.6.2. Explicit-Path AVP
The Explicit-Path AVP (AVP Code 35003) is of type Grouped. This AVP MUST be present in all request messages performing ER. It MAY be present in the answer to the initial session request message if Explicit-Path discovery was successfully executed for the request. 👑
Explicit-Path ::= < AVP Header: 35003 >
1* [ Explicit-Path-Record ]
* [ AVP ]4.7. Error Handling 💅
Okay bestie, ER processing can go sideways 💀, so here are the error conditions that may show up. Every error indication MUST be wrapped up in an instance of the Experimental-Result AVP [RFC3588], with the Vendor-ID AVP set to 2011 and the Experimental-Result-Code set as listed below 💖.
DIAMETER_INVALID_PROXY_PATH_STACK is 3501 🙈. It shows up when a request reaches an ER-Proxy or ER-Destination after an Explicit-Path has been set up, and the first or only Explicit-Path-Record AVP doesn't match that node's identity. The same error also applies to an ER-Destination that gets an Explicit-Path-AVP with more than one Explicit-Path-Record, or with only one Explicit-Path-Record that doesn't match its own identity 🔍.
This error SHOULD be considered a protocol failure, and it SHOULD be handled on a per-hop basis. Diameter proxies may try to fix it if they can 🛠️. Diameter answer messages carrying this error indication MUST have the 'E' bit set and MUST conform to Section 7.2 of [RFC3588] ✨.
DIAMETER_ER_NOT_AVAILABLE is 4501 🌸. An ER-Destination that supports ER routing but can't comply for unknown reasons MAY send an answer message with the Result-Code AVP set to this error code. This error value SHOULD be considered a transient failure, which means later ER attempts may succeed 🦋.
5. Example Message Flow ✨
This example shows how Diameter messages flow with the usual attributes you'd see in an ER scenario 🧚.
The ER-Originator here uses Explicit-Path discovery on the first request, but it could also use a pre-configured cache. Any Diameter node that sends a request can be an ER-Originator, whether it's a client, a server, or a proxy 👑. In this scenario, the ER-Originator's local cache starts out empty 🫶.
The AAA relays between the ER-Proxies, ER-Originator, and ER-Destination may or may not be present. They're drawn to show the routing paths the requests might take before the nodes taking part in ER process them. The AAA relays also stand in for existing Diameter relays or proxies that don't recognize Explicit-Path AVPs, so they don't take part in ER 🌈.
ER- ER- ER- ER-
Originator AAA relays Proxy1 AAA relays Proxy2 Destination
(o.r1 (p.r1 (p.r2 (d.r2
.example) .example) .example) .example)
| | | | |
cache=(empty) | | | | |
------------->|--------->| | | |
(1st request of the session)| | | |
Explicit-Path= | | | |
o.r1.example,r1.example | | |
dest-host=d.r2.example | | | |
dest-realm=r2.example | | | |
| | | | |
| |--------->|--------->| |
| | (forwarded request)| |
| | Explicit-Path= | |
| | record1=o.r1.example,r1.example
| | record2=p.r1.example,r1.example
| | dest-host=d.r2.example |
| | dest-realm=r2.example |
| | | | |
| | | |--------->|
| | | (forwarded request)
| | | Explicit-Path=
| | | record1=o.r1.example,
| | | r1.example
| | | record2=p.r1.example,
| | | r1.example
| | | record3=p.r2.example,
| | | r2.example
| | | dest-host=d.r2.example
| | | dest-realm=r2.example
| | | | |
cache= |<---------|<---------|<---------|<---------|
record1=o.r1.example,r1.example (answer) |
record2=p.r1.example,r1.example Explicit-Path=
record3=p.r2.example,r2.example record1=o.r1.example,r1.example
record4=d.r2.example,r2.example record2=p.r1.example,r1.example
| | record3=p.r2.example,r2.example
| | record4=d.r2.example,r2.example
Note: An originator pre-configuring | | |
its local cache can skip the | | |
exchange above and send the | | |
initial request as shown below. | | |
| | | | |
------------->|--------->| | | |
(subsequent request of the session) | | |
Explicit-Path= | | | |
record1=p.r1.example,r1.example | | |
record2=p.r2.example,r2.example | | |
record3=d.r2.example,r2.example | | |
dest-host=p.r1.example | | | |
dest-realm=r1.example | | | |
| |--------->|--------->| |
| | (forwarded request)| |
| | Explicit-Path= | |
| | record1=p.r2.example,r2.example
| | record2=d.r2.example,r2.example
| | dest-host=p.r2.example |
| | dest-realm=r2.example |
| | | | |
| | | |--------->|
| | | (forwarded request)
| | | Explicit-Path
| | | record1=d.r2.example,
| | | r2.example
| | | dest-host=d.r2.example
| | | dest-realm=r2.example
| | | | |
cache= |<---------|<---------|<---------|<---------|
record1=o.r1.example,r1.example (answer) | |
record2=p.r1.example,r1.example * no Explicit-Path-AVP present
record3=p.r2.example,r2.example | | |
record4=d.r2.example,r2.example | | |
| | | | |
| | | | |
(subsequent request of the session will repeat the process above)
| | | | |
| | | | |
Figure 1: Example ER Message Flow6. RADIUS/Diameter Protocol Interactions 🎀
Nothing needs to happen here for RADIUS/Diameter interaction 🍓. The routing extension in this document is transparent to any translation gateway, and it's only relevant to Diameter routing. The assumption is that if there's a RADIUS proxy chain between Diameter translation agents, the route between those agents stays stable during the session and doesn't invalidate the proxy path stack 💜.
7. Security Considerations 💀
Okay, this part is serious 😭. The security considerations in [RFC3588] apply to this extension. On top of that, this extension raises questions of authorization and can potentially allow a new denial-of-service attack 🚨.
The authorization issue comes up because the proxies that take part in ER are self-selected. Through ER, an ER-Proxy can make sure it monitors every message of a session. That's different from ordinary Diameter routing, where some messages might take an alternate route 👀. The real question is whether the originating party is prepared to extend this extra degree of trust to arbitrary parties along the path. If not, the ER-Originator needs a mechanism to decide whether an ER-Proxy listed in the returned Explicit-Path AVP can be trusted. If it has one, an unwanted ER-Proxy can be deleted from its cache, so it won't show up in the ER-Path AVP in later requests 🚫. This specification assumes that either the originating party is prepared to let arbitrary Diameter nodes along the path attach themselves to the session as ER-Proxies, or the ER-Originator keeps a pre-configured list of ER-Proxies in its cache 🌸.
The potential denial-of-service attack isn't a serious one, because the same result can be achieved more directly 🙄. An attacker controlling a Diameter node along the path of the original request could insert an Explicit-Path-Record containing the identity of another node or a non-existent node, rather than its own identity. Routing later messages of the session through another node could violate the trust assumptions made upstream. Routing subsequent messages to a non-existent node causes them to be lost and terminates the session 💔. It would seem simpler to carry out whatever harm the attacker intends at the subverted Diameter node itself. The advantage of using ER for either attack is that it makes it harder to tell which node misbehaved, but the extra effort to pull off the attack doesn't seem worth the potential gain 🕵️.
8. Acknowledgements 🫶
The authors gratefully acknowledge the contributions of Tony Zhang, Fortune Huang, Rajith R., Victor Fajardo, Jouni Korhonen, Tolga Asveren, Mark Jones, Avi Lior, Steve Norreys, Lionel Morand, Dave Frascone, and Hannes Tschofenig 💜✨.
9. References 📚
9.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
- [RFC5729] Korhonen, J., Ed., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009.
9.2. Informative References
- [TS23.234] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking; System description", TS 23.234 Version 7.4.0, 2006.
Authors' Addresses 🦋
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
EMail: tena@huawei.com
URI: http://tinatsou.weebly.com/contact.html
Glen Zorn
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok 10260
Thailand
Phone: +66 (0) 87-040-4617
EMail: gwz@net-zen.net
Tom Taylor (editor)
Huawei Technologies
1852 Lorraine Ave.
Ottawa
Canada
EMail: tom111.taylor@bell.net📦 where this page comes from
- ietf: rfc6159 2011-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms