Internet Engineering Task Force (IETF) S. Donovan Request for Comments: 7944 Oracle Category: Standards Track August 2016 ISSN: 2070-1721 Diameter Routing Message Priority
AbstractWhen making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information, Diameter nodes can factor that priority into routing, resource allocation, and overload abatement decisions. 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 Notice 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, as they describe 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 are provided without warranty as described in the Simplified BSD License.
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 RFC7683] for Diameter overload control introduces scenarios where Diameter routing decisions made by Diameter nodes can be influenced by the overload state of other Diameter nodes. This includes the scenarios where Diameter endpoints and Diameter Agents can throttle requests as a result of the target for the request being overloaded. With currently available mechanisms, these Diameter nodes do not have a mechanism to differentiate request message priorities when making these throttling decisions. As such, all requests are treated the same, meaning that all requests have the same probability of being throttled.
There are scenarios where treating all requests the same can cause issues. For instance, it might be considered important to reduce the probability of transactions involving first responders being throttled during overload scenarios caused, for example, by a period of heavy signaling resulting from a natural disaster. This document defines a mechanism that allows Diameter nodes to indicate the relative priority of Diameter transactions. With this information, other Diameter nodes can factor the relative priority of requests into routing and throttling decisions. RFC6733] is designed to transport multiple Diameter applications and that Diameter nodes can be implemented that support multiple applications. In order 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 fashion, taking the default priority into account. See Section 10 for a discussion of some of the considerations that need to be factored into the setting of DRMPs used by Diameter applications. 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 taken into consideration, it is possible for messages for one application to gain unwarranted preferential treatment over messages for other applications. This mechanism also depends on all of the messages that carry the DRMP Attribute Value Pair (AVP) that are inserted into Diameter messages by trusted nodes within the Diameter administrative domain. As discussed in Section 12, misbehaving nodes have the ability to use the DRMP mechanism to gain unwarranted preferential treatment. When messages cross Diameter administrative boundaries, care should be taken to either strip or modify the DRMP values in these messages. If the priority definitions vary between the two Diameter administrative domains, then it is possible for messages from a foreign domain to gain unwarranted preferential treatment.
RFC7683]. An overload abatement treatment where the reacting node selects alternate destinations or paths for requests. DOIC Diameter Overload Indication Conveyance. DRMP Diameter Routing Message Priority. Overload Abatement As defined in [RFC7683]. Reaction to receipt of an overload report resulting in a reduction in 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. Throttling As defined in [RFC7683]. An abatement treatment that limits the number of requests sent by the DOIC reacting node. Throttling can include a Diameter Client choosing to not send requests or a Diameter Agent or Server rejecting requests with appropriate error responses. In both cases, the result of the throttling is a permanent rejection of the transaction. RFC2119]. The interpretation from RFC 2119 does not apply for the above listed words when they are not used in all caps.
One example of this is in the 3GPP application [S6a] where an Update Location Request (ULR) resulting from a Mobility Management Entity (MME) restoration procedure might be given a higher priority than a ULR resulting from an initial attach. RFC6733]. This will be used when handling the associated answer message for the transaction.
3. Request handler -- The handler of the request, be it a Diameter Server or a Diameter Client, can use the priority information to determine how to handle the request. This could include determining the order in which requests are handled and resources that are applied to the handling of the request. 4. Answer sender -- The handler of the request is also the sender of the answer. The answer sender uses the priority information received in the request message when sending the answer. This implies that answers for higher-priority transactions are given preferential treatment over lower-priority transactions. The answer sender also has the option of including priority information in the answer message. This is done when the answer message needs to have a different priority than the priority carried in the request message. The priority included by the answer sender is application specific. 5. Agent handling the answer -- By default, agents handling answer messages use the priority information stored with the transaction state to determine the priority of relaying the answer message. However, priority information included in the answer message, when present, is used in place of the stored priority information. The use of priority information implies that answers for higher-priority transactions are given preferential treatment over lower-priority transactions. When forwarding the answer messages, agents generally do not modify the priority information present in the received answer messages nor include the priority information when absent in the received answer messages. However, in some scenarios, agents can modify the priority information, for example, edge agents modifying the priority values set by an adjacent operator. There might be other scenarios where a Diameter endpoint does not support the DRMP mechanism, and agents insert the priority information for that non-supporting endpoint. 6. Answer handler -- The answer handler uses the same method as the agent to determine the priority of the answer message. By default, the handler of the answer message uses the priority saved in the transaction's state. Priority information in the answer message is used when present. The priority is used when allocating resources for processing that occurs after the receipt of the answer message.
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 priority for the answer message needs to have a different priority than the priority carried in the request message. 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 not DRMP AVP in the answer message, then the Diameter node SHOULD use the priority indicated in the DRMP AVP of the associated request message. Note: One method to determine what priority to apply to an answer when there is no DRMP AVP in the answer message is to save the priority included in the request message in the state associated with the Diameter transaction. Another is to use 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. 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 and thus would be a suitable default for most deployments, while still allowing different Diameter applications to designate other priorities for lower- and higher-priority traffic. Note: This does not imply that a DRMP AVP is added to the message. Rather, the message is treated the same as a message that has 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: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator-defined local
policy would override the use of PRIORITY_10 as the default priority. 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 on the handling of messages without a priority does not result in a Diameter Agent inserting a DRMP AVP into the message. Rather, it gives guidance on how that specific transaction should be treated when its priority is compared with other requests. When a Diameter 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: As a result, PRIORITY_0 is the highest priority.
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.1 Enumerated | | V | +--------------------------------------------------+----+----+
Section 1.1, it is important that the definition of priority values used by all applications within a single Diameter administrative domain be done in a consistent and coordinated manner. The following are some things to be considered when defining the DRMPs to be used in Diameter networks that support Diameter nodes handling multiple applications. 1. As with any prioritization scheme, it is possible for higher- priority messages to block lower-priority messages from ever being handled. In a Diameter network, this will often result in those Diameter transactions being retried. This can result in more traffic than the network would have handled without use of the DRMP mechanism. One potential guideline to prevent unwanted starving of lower- priority messages is to have higher-priority messages represent a relatively small portion of messages handled by the Diameter network under normal scenarios. Note that there are scenarios, such as first responder messages, where the blocking of lower-priority messages is a requirement. 2. When setting priorities for any of the use cases outlined in Section 5, it is important to use the same priority values across applications. For instance, when defining priority for the first responder use case discussed in Section 5.1 and the emergency call use case discussed 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 that the values mentioned here are strictly for illustrative purposes. The actual values used for these use cases are likely to be different. 3. Messages without the DRMP AVP will be given default priority value treatment. This will include messages from Diameter Clients that have not been updated to support the DRMP mechanism. It might also include messages from foreign administrative domains if the DRMP AVPs are stripped from messages crossing the Diameter administrative domains.
4. The process used to introduce the DRMP mechanism 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 those messages are sent from nodes that are upgraded to support the DRMP mechanism versus nodes that have not yet been upgraded to support the DRMP mechanism. Section 9. All AVP codes are allocated from the "AVP Codes" subregistry of the "Authentication, Authorization, and Accounting (AAA) Parameters" registry.
When agents are involved, this presents an effectively transitive trust model. That is, a Diameter Client or Server can authorize an agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on. Since confidentiality and integrity protection occurs at the transport layer, agents can read, and perhaps modify, any part of a Diameter message, including the DRMP AVP. There are several ways an attacker might attempt to exploit the DRMP mechanism. A malicious or compromised Diameter node might insert invalid priority values resulting in either preferential treatment, resulting from higher values, or degraded treatment resulting from lower values, for that node. A similar attack involves a malicious or compromised Diameter Agent changing the priority value resulting in the sending Diameter node getting either preferential or degraded service. The DRMP mechanism can be used to aid in overload throttling decisions. When this is the case, then the above attacks are 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 have a potentially greater impact in this scenario as the priority indication impacts the handling of all requests at all times, independent of the overload status of Diameter nodes in the Diameter network. RFC6733] makes it difficult to establish trust in DRMP AVPs received from non- adjacent nodes. Any agents in the message path may insert or modify DRMP AVPs. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive-trust requirement extending for potentially long chains of nodes. Network operators must determine if 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 is expected that work on end-to-end Diameter security might make it easier to establish trust in non-adjacent nodes for DRMP purposes. Readers should be reminded, however, that the DRMP mechanism allows Diameter Agents to modify AVPs in existing messages that are originated by other nodes. If end-to-end security is enabled, there is a risk that such modification could violate integrity protection. The details of using any future Diameter end-to-end security mechanism with DRMP will require careful consideration and are beyond the scope of this document. [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>. [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>.