RFC 7944

Diameter Routing Message Priority

📅 published August 2016, from ietf

RFC 7944: Diameter Routing Message Priority 🎀

Okay bestie, here's the header info first so you know the basics 💅

  • Number and title: RFC 7944, "Diameter Routing Message Priority"
  • Author: S. Donovan, Oracle
  • Category: Standards Track
  • Date: August 2016
  • ISSN: 2070-1721
  • Stream: Internet Engineering Task Force (IETF)
  • Obsoletes and updates: the title block doesn't list any RFCs that this one obsoletes or updates 🦋

Abstract ✨

Okay so when Diameter nodes are making routing and resource allocation calls, they currently have no generic way to tell how important each Diameter message is 🙈 This doc fixes that by defining a mechanism that lets Diameter endpoints flag the relative priority of their Diameter transactions. With that info, nodes can bring priority into their routing, resource allocation, and overload abatement decisions. It's giving main character energy 👑

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7944.

Copyright (c) 2016 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) in effect on the date of publication of this document. Please review these documents carefully, since they spell out your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Applicability . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   4
3.  Conventions Used in This Document . . . . . . . . . . . . . .   4
4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
5.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   6
  5.1.  First-Responder-Related Signaling . . . . . . . . . . . .   6
  5.2.  Emergency-Call-Related Signaling  . . . . . . . . . . . .   6
  5.3.  Differentiated Services . . . . . . . . . . . . . . . . .   7
  5.4.  Application-Specific Priorities . . . . . . . . . . . . .   7
6.  Theory of Operation . . . . . . . . . . . . . . . . . . . . .   8
7.  Extensibility . . . . . . . . . . . . . . . . . . . . . . . .  10
8.  Normative Behavior  . . . . . . . . . . . . . . . . . . . . .  10
9.  Attribute Value Pairs . . . . . . . . . . . . . . . . . . . .  12
  9.1.  DRMP AVP  . . . . . . . . . . . . . . . . . . . . . . . .  12
  9.2.  Attribute Value Pair Flag Rules . . . . . . . . . . . . .  13
10. Considerations When Defining Application Priorities . . . . .  14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
  11.1.  AVP Codes  . . . . . . . . . . . . . . . . . . . . . . .  15
12. Security Considerations . . . . . . . . . . . . . . . . . . .  15
  12.1.  Potential Threat Modes . . . . . . . . . . . . . . . . .  15
  12.2.  Denial-of-Service Attacks  . . . . . . . . . . . . . . .  16
  12.3.  End-to-End Security Issues . . . . . . . . . . . . . . .  16
13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
  13.1.  Normative References . . . . . . . . . . . . . . . . . .  17
  13.2.  Informative References . . . . . . . . . . . . . . . . .  17
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

1. Introduction ✨

So the Diameter Overload Indication Conveyance (DOIC) solution [RFC7683] for Diameter overload control creates situations where a Diameter node's routing choices can get shaped by whether some other Diameter node is overloaded. This covers cases where Diameter endpoints and Diameter Agents start throttling requests because the request's target is overloaded 🌊

Right now, these nodes have no way to tell request messages apart by priority when they make those throttling calls. Every request gets treated the same, which means every request has the same chance of getting throttled 😭

That can be a real problem. Imagine a period of heavy signaling after a natural disaster causes overload. You'd really want transactions involving first responders to be less likely to get throttled in that situation 🚨

This document defines a mechanism that lets Diameter nodes indicate the relative priority of their Diameter transactions. Once nodes have that info, they can factor the relative priority of requests into both routing and throttling decisions 🎀

1.1. Applicability

There are two main things that have to work for this mechanism to be effective 💖 The first is that the Diameter base protocol defined in [RFC6733] is built to carry multiple Diameter applications, and Diameter nodes can be implemented to support multiple applications. For the Diameter Routing Message Priority (DRMP) mechanism to work, the priorities defined for all messages across all applications used in a Diameter administrative domain must be defined in a consistent and coordinated way, and the default priority has to be taken into account. Section 10 talks through some of the things to factor in when setting DRMPs for Diameter applications, so go read that too 🧠

Note that this consideration does not apply to Diameter networks where all Diameter nodes only support a single application.

Without this cross-application priority design, it's possible for messages from one application to get unwarranted preferential treatment over messages from other applications 🙃

This mechanism also depends on the messages that carry the DRMP Attribute Value Pair (AVP) being inserted into Diameter messages by trusted nodes within the Diameter administrative domain. As Section 12 explains, misbehaving nodes can use the DRMP mechanism to get unwarranted preferential treatment 😤

When messages cross Diameter administrative boundaries, care should be taken to either strip or modify the DRMP values in those messages. If the priority definitions differ between the two Diameter administrative domains, then messages from a foreign domain could end up getting unwarranted preferential treatment 👀

2. Terminology and Abbreviations 📚

Diversion

As defined in [RFC7683]. This is an overload abatement treatment where the reacting node picks alternate destinations or paths for requests.

DOIC

Diameter Overload Indication Conveyance.

DRMP

Diameter Routing Message Priority.

Overload Abatement

As defined in [RFC7683]. This is a reaction to receiving an overload report that results in a reduction in the traffic sent to the reporting node. Abatement actions include diversion and throttling.

Priority

The relative importance of a Diameter message. A lower-priority value implies a higher relative importance of the message. Yes, lower number means more important, so flip your brain for a sec 🔄

Throttling

As defined in [RFC7683]. This is an abatement treatment that limits the number of requests sent by the DOIC reacting node. Throttling can include a Diameter Client choosing not to send requests, or a Diameter Agent or Server rejecting requests with appropriate error responses. In both cases, the result of throttling is a permanent rejection of the transaction 💀

3. Conventions Used in This Document 📐

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].

The interpretation from RFC 2119 does not apply to the above listed words when they are not used in all caps. So lowercase "must" is just regular English, not a rule 🤓

4. Problem Statement 🧩

With overload control mechanisms being introduced, Diameter nodes will be required to make decisions about which Diameter request messages should be throttled when other Diameter nodes are overloaded 🌪️

Right now there's no generic mechanism for indicating which request messages should get preferential treatment when those throttling decisions happen 🙈

So as a result, all messages are treated equally and, as such, they all have an equal probability of being throttled. Not iconic 💀

There are a bunch of scenarios where it makes sense for an application to mark a request as higher priority than other application requests. We'll get into those in the next section ✨

This document defines a mechanism for applications to indicate priority for individual transactions. That lowers the chance those transactions get throttled, as long as there are other lower-priority transactions that are eligible for throttling 🦋

The main use for DRMP-defined priorities is as input to throttling decisions related to Diameter overload control. But the priority info is also expected to be useful for other routing-related stuff too. That could include giving higher-priority transactions preferential treatment when selecting routes 🛣️

DRMP info could also help Diameter endpoints make resource allocation decisions. For example, a Diameter Server might use the priority information to handle higher-priority requests ahead of lower-priority ones. It might also use that priority info as a reason to fail a request because resources are insufficient 🧁

Note: There are a number of application-specific definitions that show different views of application-level priority for different requests. Using these application-specific priority AVPs as input to throttling and other Diameter routing decisions would force Diameter Agents to understand all applications and do application-specific parsing of all messages just to figure out the priority of individual messages. That's considered an unacceptable level of complexity for elements whose main job is routing Diameter messages 😵‍💫

5. Use Cases 🎀

This section walks through various scenarios where Diameter transactions can benefit from priority information 💅

It's really important to note that for priority information to be reliably usable, the Diameter nodes that send and consume DRMP AVPs must have pre-established trust relationships of the sort described in Section 12 🫶

Okay so natural disasters can totally spike how much network stuff people use 😭, and it gets even worse if the disaster also knocks out network capacity. Not ideal, bestie. 💀

That mix of extra load and less capacity can push Diameter nodes into overload, and then DOIC mechanisms kick in to ask for less traffic. Requests start getting throttled so the overloaded node doesn't fall over. 🫠

First responders and everyone dealing with the aftermath need to be sure they can actually get onto the network, both to talk to each other and to reach other network resources. That's giving high-stakes energy 🚨

Signaling for first responders needs a higher priority so they can do their jobs as effectively as possible. 🦸‍♀️

The United States Wireless Priority Services (WPS) and Government Emergency Telecommunications Service (GETS) are examples of systems built for the command and control side of these first responder needs. Iconic work 👑

Same vibe as the first responder situation: there's also signaling tied to emergency calls. Since these calls are so critical, that signaling should also get preferential treatment whenever that's possible. 🫶

5.3. Differentiated Services 💎

Operators might want to set themselves apart by offering a service level agreement (SLA) that includes preferential Diameter routing behavior. This could be modeled as Platinum, Gold, and Silver levels of service. ✨

So picture this: an operator offers a Platinum SLA that makes sure all signaling for a Platinum customer is marked with a higher priority than the signaling for Gold and Silver customers. Main character energy for the top tier 💅

5.4. Application-Specific Priorities 🧩

There are situations inside Diameter applications where it can make sense to give some transactions for that application a higher priority than the rest. 🌸

For example, say a user needs a series of transactions to get access to network services. It might make sense to mark the later transactions in that series at a higher priority than the early ones. The reasoning is that the network has already done a lot of work, and that work would be wasted if those later transactions got throttled. Ate that logic 🙌

There are also cases where an agent can't easily tell a request that starts a session apart from requests that update or end sessions. In those cases, it might make sense to mark the requests that set up new sessions at a lower priority than updates and session-ending requests. The thinking is that established sessions have already had more work put into them, so it would be more harmful to throttle the session update and session-ending requests. 🥺

And then there are cases where the priority of requests for individual command codes within an application depends on the context at the moment the request is sent. Often the message doesn't carry enough info for Diameter nodes other than the originating node to figure out that context. 🤔

This is similar to the series-of-requests scenario, except the series here uses different application command codes. In this case, requests with the same command code can have different implied priorities. 🔄

One example of this is in the 3GPP application [S6a], where an Update Location Request (ULR) that results from a Mobility Management Entity (MME) restoration procedure might get a higher priority than a ULR that results from an initial attach.

Basically, a ULR from an MME restoration gets a higher priority than a ULR from an initial attach. Same command code, different vibes 💜

6. Theory of Operation 🎀

This section lays out how DRMP is meant to be used. 📖

What happens depends on the role of the Diameter node handling the request: request sender, agent, or request handler. 🧚

Here's the expected flow of a Diameter transaction, step by step:

  1. Request sender 💌 -- The sender of a request, whether that's a Diameter Client or a Diameter Server, figures out the relative priority of the request and puts that priority info into the request. How that priority gets determined is application specific and out of scope for this specification. The request sender also saves the priority info in the transaction state so it can be used later when handling the answer messages.
  2. Agents handling the request 🚦 -- Agents use the priority info when making routing decisions. That can include deciding which requests to route first, which ones to throttle, and where they get routed. For instance, higher-priority requests might have a lower chance of being throttled. How an agent decides which requests are candidates for throttling is implementation dependent and out of scope for this document. Before forwarding request messages, agents generally don't change the priority info that's already in the received request, and they don't add priority info when it's missing from the received request. There are exceptions, though: in some scenarios agents can change the priority info, like edge agents changing priority values that were set by an adjacent operator. There might also be cases where a Diameter endpoint doesn't support the DRMP mechanism, so agents insert the priority info into requests for that non-supporting endpoint. When forwarding requests, the agent also saves the transaction priority in the transaction state, either as locally managed state or by using the Proxy-Info mechanism defined in [RFC6733]. That gets used when handling the associated answer message for the transaction. 🫶
  3. Request handler 🛠️ -- The handler of the request, whether that's a Diameter Server or a Diameter Client, can use the priority info to decide how to handle the request. That can include deciding the order requests get handled in and which resources get applied to handling each request. 📋
  4. Answer sender 📬 -- The handler of the request is also the sender of the answer. The answer sender uses the priority info received in the request when sending the answer, which means answers for higher-priority transactions get preferential treatment over lower-priority ones. The answer sender also has the option to include priority info in the answer message. That's done when the answer needs a different priority than the one carried in the request. The priority included by the answer sender is application specific. 💖
  5. Agent handling the answer 🔁 -- By default, agents handling answer messages use the priority info stored with the transaction state to decide the priority for relaying the answer. But if priority info is included in the answer message, it's used in place of the stored priority. Using priority info means answers for higher-priority transactions get preferential treatment over lower-priority ones. When forwarding answer messages, agents generally don't change the priority info in the received answer, and they don't add priority info when it's missing. Same exceptions as before: in some scenarios agents can modify the priority info, such as edge agents changing values set by an adjacent operator. And if a Diameter endpoint doesn't support the DRMP mechanism, agents insert the priority info for that non-supporting endpoint. ✨
  6. Answer handler 🎯 -- The answer handler uses the same method the agent uses to determine the priority of the answer message. By default, the handler uses the priority saved in the transaction's state. If priority info is present in the answer message, that's used instead. The priority then gets applied when allocating resources for processing that happens after the answer message is received. 🌈

7. Extensibility 🧩

This document doesn't define any extensibility mechanisms specific to DRMP. So if an extension needs new AVPs, it has to use the existing Diameter extensibility mechanisms defined in [RFC6733]. Plenty of tools in the box, just not new DRMP-specific ones 🧰💅

8. Normative Behavior ✨

okay so this section is where all the rules live 💅 it's the normative behavior for DRMP, and yes, the capital words are doing real work here bestie 🫶

When routing priority information is available, Diameter nodes SHOULD include Diameter routing message priority in the DRMP AVP in all Diameter request messages.

Note: how the priority value gets picked for the request is application specific, and that is totally out of scope for this spec 🙈

The priority marking scheme does not require the Diameter Agents to understand application-specific AVPs. no understanding needed, it just works 🦋

When available, Diameter nodes SHOULD use routing priority information included in the DRMP AVP when making Diameter overload throttling decisions. 🌸

Diameter Agents MAY use routing priority information included in the DRMP AVP when relaying request and answer messages. this covers picking routes and ordering the messages that get relayed 🧚

Note: the priority in the DRMP AVP of a request applies to the request AND, by default, the answer for that transaction. main character energy for the whole conversation 👑

While done only in exceptional circumstances, Diameter Agents MAY modify priority information when relaying request and answer messages. 🔥

Note: yes it can happen! an edge agent might need to change the priority values set by an adjacent operator 💀

While done only in exceptional circumstances, Diameter Agents MAY add priority information when relaying request and answer messages. 🎀

Note: this is for when an endpoint doesn't support DRMP at all, so the agent inserts priority info on its behalf 🫶

Diameter endpoints MAY use routing priority information included in the DRMP AVP when making resource allocation decisions for the transaction associated with the request message that contains the DRMP information. 💜

Diameter endpoints MAY use routing priority information included in the DRMP AVP when making resource allocation decisions for the transaction associated with the answer messages, using the DRMP information associated with the transaction. ✨

Diameter endpoints MAY include the DRMP AVP in answer messages. this is done when the answer needs a different priority than the one in the request 🦋

When determining the priority to apply to answer messages, Diameter nodes SHOULD use the priority indicated in the DRMP AVP carried in the answer message, if it exists. if there is no DRMP AVP in the answer, then the Diameter node SHOULD use the priority indicated in the DRMP AVP of the associated request message. 🌈

Note: one way to figure out the answer priority when the answer has no DRMP AVP is to save the request's priority in the state for that Diameter transaction. another option is the Proxy-Info mechanism defined in [RFC6733]. ✨

Diameter nodes MUST have a default priority to apply to transactions that do not have an explicit priority set in the DRMP AVP. this one is non-negotiable 🔥

In order to guarantee consistent handling of messages from non-upgraded Diameter Clients, Diameter nodes SHOULD use the PRIORITY_10 priority as this default priority value. 🍓

PRIORITY_10 is a midrange priority that corresponds to "normal" traffic, so it's a suitable default for most deployments, while still letting different Diameter applications designate other priorities for lower- and higher-priority traffic. it's giving balanced 💖

Note: this does not mean a DRMP AVP gets added to the message. the message is simply treated the same as one carrying a DRMP AVP with a priority value of PRIORITY_10 🙈

Diameter nodes MUST support the ability for the default priority to be modified through local configuration interfaces. 🔥

Note: operators might want a different default for transactions that have no explicit priority. in that case, the operator-defined local policy overrides PRIORITY_10 as the default 🧚

When using DRMP information, Diameter nodes MUST use the default priority for transactions that do not have priority specified in a DRMP AVP. 💅

Note: this guidance doesn't make a Diameter Agent insert a DRMP AVP into the message. it just tells the node how to treat that transaction when its priority is compared with other requests. when an agent relays the request, it will NOT insert a DRMP AVP with a priority value of 10. 🙈

When setting and using priorities, for all integers x,y in [0,15], treat PRIORITY_<x> as lower priority than PRIORITY_<y> when y<x. 🌸

Note: so PRIORITY_0 is the highest priority. literally the queen 👑✨

9. Attribute Value Pairs 🎀

this section is all about how the Diameter Routing Message Priority AVP gets encoded and what it means. it's the nitty gritty, but iykyk 🫶

9.1. DRMP AVP 💜

The DRMP (AVP code 301) is of type Enumerated. the value of the AVP tells you the routing message priority for the transaction. these values are defined:

PRIORITY_15 15  PRIORITY_15 is the lowest priority.

PRIORITY_14 14  PRIORITY_14 is a higher priority than PRIORITY_15 and
   a lower priority than PRIORITY_13.

PRIORITY_13 13  PRIORITY_13 is a higher priority than PRIORITY_14 and
   a lower priority than PRIORITY_12.

PRIORITY_12 12  PRIORITY_12 is a higher priority than PRIORITY_13 and
   a lower priority than PRIORITY_11.

PRIORITY_11 11  PRIORITY_11 is a higher priority than PRIORITY_12 and
   a lower priority than PRIORITY_10.

PRIORITY_10 10  PRIORITY_10 is a higher priority than PRIORITY_11 and
   a lower priority than PRIORITY_9.

PRIORITY_9 9  PRIORITY_9 is a higher priority than PRIORITY_10 and a
   lower priority than PRIORITY_8.

PRIORITY_8 8  PRIORITY_8 is a higher priority than PRIORITY_9 and a
   lower priority than PRIORITY_7.

PRIORITY_7 7  PRIORITY_7 is a higher priority than PRIORITY_8 and a
   lower priority than PRIORITY_6.

PRIORITY_6 6  PRIORITY_6 is a higher priority than PRIORITY_7 and a
   lower priority than PRIORITY_5.

PRIORITY_5 5  PRIORITY_5 is a higher priority than PRIORITY_6 and a
   lower priority than PRIORITY_4.

PRIORITY_4 4  PRIORITY_4 is a higher priority than PRIORITY_5 and a
   lower priority than PRIORITY_3.

PRIORITY_3 3  PRIORITY_3 is a higher priority than PRIORITY_4 and a
   lower priority than PRIORITY_2.

PRIORITY_2 2  PRIORITY_2 is a higher priority than PRIORITY_3 and a
   lower priority than PRIORITY_1.

PRIORITY_1 1  PRIORITY_1 is a higher priority than PRIORITY_2 and a
   lower priority than PRIORITY_0.

PRIORITY_0 0  Priority 0 is the highest priority.

9.2. Attribute Value Pair Flag Rules 🦋

                                                         +---------+
                                                         |AVP Flag |
                                                         |Rules    |
                                                         +----+----+
                              AVP   Section              |    |MUST|
       Attribute Name         Code  Defined  Value Type  |MUST| NOT|
      +--------------------------------------------------+----+----+
      |DRMP                    301  9.1      Enumerated  |    | V  |
      +--------------------------------------------------+----+----+

10. Considerations When Defining Application Priorities 💅

as we talked about in Section 1.1, it is important that the definition of priority values used by all applications within a single Diameter administrative domain is done in a consistent and coordinated way. 🫶

these are some things to think about when defining the DRMPs for Diameter networks where nodes handle multiple applications. 🌈

  1. as with any prioritization scheme, higher-priority messages can block lower-priority messages from ever being handled. in a Diameter network this often means those transactions get retried, which can create more traffic than the network would have handled without DRMP. yikes 😭

one potential guideline to stop lower-priority messages from getting starved is to have higher-priority messages make up a relatively small portion of what the network handles under normal conditions. 🧚

Note: there are scenarios, like first responder messages, where blocking lower-priority messages is a requirement. no cap, that's serious 🚨
  1. when setting priorities for any of the use cases in Section 5, it is important to use the same priority values across applications. for example, when defining priority for the first responder use case in Section 5.1 and the emergency call use case in Section 5.2, one high-priority value might be used for all first responder messages, say PRIORITY_2, and a slightly lower-priority value, say PRIORITY_3, might be used for emergency-call-related messages. these values should be specified for these use cases across all applications used within the Diameter administrative domain. 🎀
Note: the values mentioned here are strictly for illustrative purposes. the actual values used for these use cases are likely to be different. 🙈
  1. messages without the DRMP AVP get default priority value treatment. this includes messages from Diameter Clients that haven't been updated to support DRMP. it might also include messages from foreign administrative domains if the DRMP AVPs are stripped from messages crossing the Diameter administrative domains. 🦋
  2. the process used to roll out DRMP into a Diameter network should also be taken into consideration. messages of the same type within the same application might get different treatment depending on whether they come from nodes that are upgraded to support DRMP or nodes that haven't been upgraded yet. 💜

11. IANA Considerations 🌸

11.1. AVP Codes 🍓

The new AVP defined by this specification is listed in Section 9. All AVP codes are allocated from the "AVP Codes" subregistry of the "Authentication, Authorization, and Accounting (AAA) Parameters" registry. ✨

12. Security Considerations 🔥

okay this one is SERIOUS bestie, no skipping 😭🚨

DRMP gives Diameter nodes the ability to influence which requests are throttled during overload scenarios. on top of that, DRMP can be used when deciding routing for request messages. improper use of the DRMP mechanism could let a malicious Diameter node get preferential treatment, lowering the chance its requests get throttled compared to other Diameter nodes. that would happen if the malicious node inserts priority values that are artificially high. 💀

Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. this opens the possibility that malicious or compromised agents in the path of a request could modify the DRMP AVP to reflect a priority different from the one asserted by the sender of the request. 🙈😭

12.1. Potential Threat Modes ✨

okay so Diameter is all about requests and answers going back and forth between clients and servers 💌 these can be peers, which means they share a direct transport connection (like TCP or SCTP 🔌), or the messages can hop through one or more middlemen called Diameter Agents 🧚

Diameter nodes use TLS, DTLS, or IPsec to authenticate peers and keep traffic confidential and tamper-proof 🔐 nodes can then make authorization decisions based on the peer identities authenticated at the transport layer 💅

but here's the tea 🫖 when agents are involved, trust gets effectively transitive. a Diameter Client or Server can authorize an agent for certain actions, but it has to trust that agent to make good authorization decisions about its own peers, and so on down the line 🌸 and since confidentiality and integrity protection happen at the transport layer, agents can read, and maybe modify, any part of a Diameter message, including the DRMP AVP 😭

there are a few ways an attacker could try to exploit the DRMP mechanism 👀 a malicious or compromised Diameter node might insert invalid priority values, either to get preferential treatment (from higher values) or degraded treatment (from lower values) for that node 🙈

a similar attack is when a malicious or compromised Diameter Agent changes the priority value, so the sending node gets either preferential or degraded service 💀

the DRMP mechanism can be used to help with overload throttling decisions 🧯 when it is, the above attacks are only limited in scope to when one or more Diameter nodes are in an overloaded state 🫶

the DRMP mechanism can also be used to influence the order in which Diameter messages are handled by Diameter nodes 📬 the above attacks could have a potentially greater impact here, because the priority indication affects the handling of all requests at all times, no matter the overload status of Diameter nodes in the network 😱

12.2. Denial-of-Service Attacks 🛡️

the DRMP mechanism does not open direct denial-of-service attack vectors 🙌 instead, it introduces a way for a node to gain unwarranted preferential treatment 👑 it also introduces a way for a node to get degraded service in the scenario where a rogue agent changes the priority value included in messages 🥀

12.3. End-to-End Security Issues 🔐

the lack of end-to-end integrity features in Diameter [RFC6733] makes it really hard to establish trust in DRMP AVPs received from non-adjacent nodes 😩 any agents in the message path may insert or modify DRMP AVPs, periodt 💅

nodes have to trust that their adjacent peers do proper checks on overload reports from their peers, and so on, which creates a transitive-trust requirement stretching across potentially long chains of nodes 🔗 network operators must figure out whether this transitive trust requirement is acceptable for their deployments 🧐

Nodes supporting DRMP MUST give operators the ability to select which peers are trusted to deliver DRMP AVPs, and whether they are trusted to forward the DRMP AVPs from non-adjacent nodes. Diameter nodes MUST strip DRMP AVPs from messages received from peers that are not trusted for DRMP purposes. 🚨

it's expected that work on end-to-end Diameter security might make it easier to establish trust in non-adjacent nodes for DRMP purposes ✨ but readers should remember that the DRMP mechanism lets Diameter Agents modify AVPs in existing messages that were originated by other nodes 🫣 if end-to-end security is enabled, there's a risk that such modification could violate integrity protection 💔 the details of using any future Diameter end-to-end security mechanism with DRMP will need careful consideration and are beyond the scope of this document 🧚‍♀️

13. References 📚

13.1. Normative References 🎀

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
           Ed., "Diameter Base Protocol", RFC 6733,
           DOI 10.17487/RFC6733, October 2012,
           <http://www.rfc-editor.org/info/rfc6733>.

13.2. Informative References 🦋

[RFC7683]  Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
           Morand, "Diameter Overload Indication Conveyance",
           RFC 7683, DOI 10.17487/RFC7683, October 2015,
           <http://www.rfc-editor.org/info/rfc7683>.

[S6a]      3GPP, "Evolved Packet System (EPS); Mobility Management
           Entity (MME) and Serving GPRS Support Node (SGSN) related
           interfaces based on Diameter protocol", 3GPP TS
           29.272, 14.0.0, June 2016,
           <http://www.3gpp.org/ftp/Specs/html-info/29272.htm>.

Contributors 🌷

the following person contributed substantial ideas, feedback, and discussion to this document 🫶

  • Janet P. Gunn

Author's Address 🏡

Steve Donovan
Oracle
7460 Warren Parkway
Frisco, Texas  75034
United States of America

Email: srdonovan@usdonovans.com
📦 where this page comes from