Diameter Maintenance and Extensions (DIME) S. Donovan
Internet-Draft Oracle
Intended status: Standards Track February 2, 2016
Expires: August 5, 2016

Diameter Routing Message Priority
draft-ietf-dime-drmp-03.txt

Abstract

When 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 5, 2016.

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.


Table of Contents

1. Introduction

The DOIC solution [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 during a period of heavy signaling resulting from a natural disaster being throttled during overload scenarios.

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.

2. Terminology and Abbreviations

Diversion


As defined in [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 DIOC 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.

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 RFC 2119 [RFC2119].

RFC 2119 [RFC2119] interpretation does not apply for the above listed words when they are not used in all-caps format.

4. Problem Statement

With the introduction of overload control mechanisms, Diameter nodes will be required to make decisions regarding which Diameter request messages should be throttled as a result of overloaded Diameter nodes.

There is currently no generic mechanism to indicate which request messages should be given preferential treatment when these throttling decisions are made.

As a result, all messages are treated equally and, as such, have an equal probability of being throttled.

There are a number of scenarios where it is appropriate for an application to mark a request as being of a higher priority than other application requests. These are discussed in the next section.

This document defines a mechanism for applications to indicate priority for individual transactions, reducing the probability of those transactions being throttled if there are other lower priority transactions that are eligible for throttling treatment.

While the primary usage of DRMP defined priorities is for input to Diameter overload control related throttling decisions, it is also expected that the priority information could also be used for other routing related functionality. This might include giving higher priority transactions preferential treatment when selecting routes.

It is also envisioned that DRMP priority information could be used by Diameter endpoints to make resource allocation decisions. For instance, a Diameter Server might choose to use the priority information to treat higher priority requests ahead of lower priority requests.

5. Use Cases

This section discusses various scenarios where Diameter transactions can benefit from the use of priority information.

5.1. First Responder Related Signaling

Natural disasters can result in a considerable increase in usage of network resources. This can be made worse if the disaster results in a loss of network capacity.

The combination of added load and reduced capacity can lead to Diameter nodes becoming overloaded and, as a result, the use of DOIC mechanisms to request a reduction in traffic. This in turn results in requests being throttled in an attempt to control the overload scenario and prevent the overloaded node from failing.

There is the need for first responders and other individuals responsible for handling the after effects of the disaster to be assured that they can gain access to the network resources in order to communicate both between themselves and with other network resources.

Signaling associated with first responders needs to be given a higher priority to help ensure they can most effectively do their jobs.

The United States Wireless Priority Services (WPS) and Government Emergency Telecommunications Service (GETS) are examples of systems designed to address the command and control aspects of these first responder needs.

5.2. Emergency Call Related Signaling

Similar to the first responder scenario, there is also signaling associated with emergency calls. Given the critical nature of these emergency calls, this signaling should also be given preferential treatment when possible.

5.3. Differentiated Services

Operators may desire to differentiate network-based services by providing a service level agreement that includes preferential Diameter routing behavior. This might, for example, be modeled as Platinum, Gold and Silver levels of service.

In this scenario an operator might offer a Platinum SLA the includes ensuring that all signaling for a customer who purchases the Platinum service being marked as having a higher priority than signaling associated with Gold and Silver customers.

5.4. Application Specific Priorities

There are scenarios within Diameter applications where it might be appropriate to give a subset of the transactions for the application a higher priority than other transactions for that application.

For instance, when there is a series of transactions required for a user to gain access to network services, it might be appropriate to mark transactions that occur later in the series at a higher priority than those that occur early in the series. This would recognize that there was potentially significant work done by the network already that would be lost if those later transactions were throttled.

There are also scenarios where an agent cannot easily differentiate a request that starts a session from requests that update or end sessions. In these scenarios it might be appropriate to mark the requests that establish new sessions with a lower priority than updates and session ending requests. This also recognizes that more work has already taken place for established sessions and, as a result, it might be more harmful if the session update and session ending requests were to be throttled.

There are also scenarios where the priority of requests for individual command codes within an application depends on the context that exists when the request is sent. There isn't always information in the message from which this context can be determined by Diameter nodes other than the node that originates the request.

This is similar to the scenario where a series of requests are needed to access a network service. It is different in that the series of requests involve different application command codes. In this scenario it is requests with the same command code that have different implied priorities.

6. Theory of Operation

This section outlines the envisioned usage of DRMP.

The expected behavior depends on the role (request sender, agent or request handler) of the Diameter node handling the request.

The following behavior is expected during the flow of a Diameter transaction.

  1. Request sender - The sender of a request, be it a Diameter Client or a Diameter Server, determines the relative priority of the request and includes that priority information in the request. The method for determining the relative priority is application specific and is outside the scope of this specification. The request sender also saves the priority information with the transaction state. This will be used when handling the answer messages.
  2. Agents handing the request - Agents use the priority information when making routing decisions. This can include determining which requests to route first, which requests to throttle and where the request is routed. For instance, requests with higher priority might have a lower probability of being throttled. The mechanism for how the agent determines which requests are throttled is implementation dependent and is outside the scope of this document. The agent also saves the transaction priority in the transaction state, either as locally managed state or using the Proxy-Info mechanism defined in [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 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 to 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 to lower priority transactions.
  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.

7. Extensibility

This document does not define extensibility mechanisms that are specific to the DRMP mechanism. As a result, any extension that requires new AVPs will be required to use existing Diameter extensibility mechanisms defined in [RFC6733].

8. Normative Behavior

This section contains the normative behavior associated with Diameter Resource Message Priority (DRMP).

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

The priority marking scheme SHOULD NOT require the Diameter Agents to understand application specific AVPs.

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 includes the selection of routes and the ordering of messages relayed.

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 MUST use the priority indicated in the DRMP AVP carried in the answer message, if it exists. Otherwise, the Diameter node MUST use the priority indicated in the DRMP AVP of the associated request message.

Diameter nodes MUST have a default priority to apply to transactions that do not have an explicit priority set in the DRMP AVP.

Diameter nodes SHOULD use the PRIORITY_10 priority as this default value.

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

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

When setting and using priorities, PRIORITY_0 MUST be treated as the highest priority.

When setting and using priorities, PRIORITY_1 MUST be treated as a lower priority than PRIORITY_0 and a higher priority than PRIORITY_2.

When setting and using priorities, PRIORITY_2 MUST be treated as a lower priority than PRIORITY_1 and a higher priority than PRIORITY_3.

When setting and using priorities, PRIORITY_3 MUST be treated as a lower priority than PRIORITY_2 and a higher priority than PRIORITY_4.

When setting and using priorities, PRIORITY_4 MUST be treated as a lower priority than PRIORITY_3 and a higher priority than PRIORITY_5.

When setting and using priorities, PRIORITY_5 MUST be treated as a lower priority than PRIORITY_4 and a higher priority than PRIORITY_6.

When setting and using priorities, PRIORITY_6 MUST be treated as a lower priority than PRIORITY_5 and a higher priority than PRIORITY_7.

When setting and using priorities, PRIORITY_7 MUST be treated as a lower priority than PRIORITY_6 and a higher priority than PRIORITY_8.

When setting and using priorities, PRIORITY_8 MUST be treated as a lower priority than PRIORITY_7 and a higher priority than PRIORITY_9.

When setting and using priorities, PRIORITY_9 MUST be treated as a lower priority than PRIORITY_8 and a higher priority than PRIORITY_10.

When setting and using priorities, PRIORITY_10 MUST be treated as a lower priority than PRIORITY_9 and a higher priority than PRIORITY_11.

When setting and using priorities, PRIORITY_11 MUST be treated as a lower priority than PRIORITY_10 and a higher priority than PRIORITY_12.

When setting and using priorities, PRIORITY_12 MUST be treated as a lower priority than PRIORITY_11 and a higher priority than PRIORITY_13.

When setting and using priorities, PRIORITY_13 MUST be treated as a lower priority than PRIORITY_12 and a higher priority than PRIORITY_14.

When setting and using priorities, PRIORITY_14 MUST be treated as a lower priority than PRIORITY_13 and a higher priority than PRIORITY_15.

When setting and using priorities, PRIORITY_15 MUST be the lowest priority.

9. Attribute Value Pairs

This section describes the encoding and semantics of the Diameter Overload Indication Attribute Value Pairs (AVPs) defined in this document.

9.1. DRMP AVP

The DRMP (AVP code TBD1) is of type Enumerated. The value of the AVP indicates the routing message priority for the transaction. The following values are initially 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                   TBD1  x.x      Enumerated  |    | V  |
   +--------------------------------------------------+----+----+

          

10. IANA Considerations

10.1. AVP codes

New AVPs defined by this specification are listed in Section 9. All AVP codes are allocated from the 'Authentication, Authorization, and Accounting (AAA) Parameters' AVP Codes registry.

10.2. New registries

There are no new IANA registries introduced by this document.

11. Security Considerations

DRMP gives Diameter nodes the ability to influence which requests are are throttled during overload scenarios. Improper use of the DRMP mechanism could result in the malicious Diameter node gaining preferential treatment, by reducing the probability of its requests being throttled, over other Diameter nodes. This would be achieved by the malicious node inserting artificially high priority values.

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

11.1. Potential Threat Modes

The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers, that is, they may share a direct transport (e.g., TCP or SCTP) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPsec to authenticate peers, and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer.

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.

11.2. Denial of Service Attacks

The DRMP mechanism does not open direct denial of service attack vectors. Rather, it introduces a mechanism where a node can gain unwarranted preferential treatment. It also introduces a mechanism where a node can get degrated service in the scenario where a rogue agent changes the priority value included in messages.

11.3. End-to End-Security Issues

The lack of end-to-end integrity features 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.

12. Contributors

The following people contributed substantial ideas, feedback, and discussion to 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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J. and G. Zorn, "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012.

13.2. Informative References

[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, DOI 10.17487/RFC4412, February 2006.
[RFC7683] Korhonen, J., Donovan, S., Campbell, B. and L. Morand, "Diameter Overload Indication Conveyance", RFC 7683, DOI 10.17487/RFC7683, October 2015.
[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 10.8.0, June 2013.

Author's Address

Steve Donovan Oracle 7460 Warren Parkway Frisco, Texas 75034 United States EMail: srdonovan@usdonovans.com