draft-ietf-dime-drmp-02.txt   draft-ietf-dime-drmp-03.txt 
Diameter Maintenance and Extensions (DIME) S. Donovan Diameter Maintenance and Extensions (DIME) S. Donovan
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track November 11, 2015 Intended status: Standards Track February 2, 2016
Expires: May 14, 2016 Expires: August 5, 2016
Diameter Routing Message Priority Diameter Routing Message Priority
draft-ietf-dime-drmp-02.txt draft-ietf-dime-drmp-03.txt
Abstract Abstract
When making routing and resource allocation decisions, Diameter nodes When making routing and resource allocation decisions, Diameter nodes
currently have no generic mechanism to determine the relative currently have no generic mechanism to determine the relative
priority of Diameter messages. This document addresses this by priority of Diameter messages. This document addresses this by
defining a mechanism to allow Diameter endpoints to indicate the defining a mechanism to allow Diameter endpoints to indicate the
relative priority of Diameter transactions. With this information relative priority of Diameter transactions. With this information
Diameter nodes can factor that priority into routing, resource Diameter nodes can factor that priority into routing, resource
allocation and overload abatement decisions. allocation and overload abatement decisions.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 14, 2016. This Internet-Draft will expire on August 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. First Responder Related Signaling . . . . . . . . . . . . 5 5.1. First Responder Related Signaling . . . . . . . . . . . . 5
5.2. Emergency Call Related Signaling . . . . . . . . . . . . 5 5.2. Emergency Call Related Signaling . . . . . . . . . . . . 5
5.3. Differentiated Services . . . . . . . . . . . . . . . . . 5 5.3. Differentiated Services . . . . . . . . . . . . . . . . . 6
5.4. Application Specific Priorities . . . . . . . . . . . . . 6 5.4. Application Specific Priorities . . . . . . . . . . . . . 6
6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7
7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 8 8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 8
9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 11 9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 11
9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 12 9.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . 13
10.2. New registries . . . . . . . . . . . . . . . . . . . . . 12 10.2. New registries . . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.2. Denial of Service Attacks . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.3. End-to End-Security Issues . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 13 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The DOIC solution [RFC7683] for Diameter overload control introduces The DOIC solution [RFC7683] for Diameter overload control introduces
scenarios where Diameter routing decisions made by Diameter nodes can scenarios where Diameter routing decisions made by Diameter nodes can
be influenced by the overload state of other Diameter nodes. This be influenced by the overload state of other Diameter nodes. This
includes the scenarios where Diameter endpoints and Diameter agents includes the scenarios where Diameter endpoints and Diameter agents
can throttle requests as a result of the target for the request being can throttle requests as a result of the target for the request being
overloaded. overloaded.
With currently available mechanisms these Diameter nodes do not have With currently available mechanisms these Diameter nodes do not have
a mechanism to differentiate request message priorities when making a mechanism to differentiate request message priorities when making
these throttling decisions. As such, all requests are treated the these throttling decisions. As such, all requests are treated the
same meaning that all requests have the same probability of being same, meaning that all requests have the same probability of being
throttled. throttled.
There are scenarios where treating all requests the same can cause There are scenarios where treating all requests the same can cause
issues. For instance it might be considered important to reduce the issues. For instance it might be considered important to reduce the
probability of transactions involving first responders during a probability of transactions involving first responders during a
period of heavy signaling resulting from a natural disaster being period of heavy signaling resulting from a natural disaster being
throttled during overload scenarios. throttled during overload scenarios.
This document defines a mechanism that allows Diameter nodes to This document defines a mechanism that allows Diameter nodes to
indicate the relative priority of Diameter transactions. With this indicate the relative priority of Diameter transactions. With this
skipping to change at page 5, line 12 skipping to change at page 5, line 12
different requests. Using these application specific priority different requests. Using these application specific priority
AVPs as input to throttling and other Diameter routing decisions AVPs as input to throttling and other Diameter routing decisions
would require Diameter agents to understand all applications and would require Diameter agents to understand all applications and
do application specific parsing of all messages in order to do application specific parsing of all messages in order to
determine the priority of individual messages. This is considered determine the priority of individual messages. This is considered
an unacceptable level of complexity to put on elements whose an unacceptable level of complexity to put on elements whose
primary responsibility is to route Diameter messages. primary responsibility is to route Diameter messages.
5. Use Cases 5. Use Cases
This section discussed various scenarios where Diameter transactions This section discusses various scenarios where Diameter transactions
can benefit from the use of priority information. can benefit from the use of priority information.
5.1. First Responder Related Signaling 5.1. First Responder Related Signaling
Natural disasters can result in a considerable increase in usage of Natural disasters can result in a considerable increase in usage of
network resources. This can be made worse if the disaster results in network resources. This can be made worse if the disaster results in
a loss of network capacity. a loss of network capacity.
The combination of added load and reduced capacity can lead to The combination of added load and reduced capacity can lead to
Diameter nodes becoming overloaded and, as a result, the use of DOIC Diameter nodes becoming overloaded and, as a result, the use of DOIC
skipping to change at page 5, line 34 skipping to change at page 5, line 34
in requests being throttled in an attempt to control the overload in requests being throttled in an attempt to control the overload
scenario and prevent the overloaded node from failing. scenario and prevent the overloaded node from failing.
There is the need for first responders and other individuals There is the need for first responders and other individuals
responsible for handling the after effects of the disaster to be responsible for handling the after effects of the disaster to be
assured that they can gain access to the network resources in order assured that they can gain access to the network resources in order
to communicate both between themselves and with other network to communicate both between themselves and with other network
resources. resources.
Signaling associated with first responders needs to be given a higher Signaling associated with first responders needs to be given a higher
priority to help ensure they can most effectively do their job. priority to help ensure they can most effectively do their jobs.
The United States Wireless Priority Services (WPS) and Government The United States Wireless Priority Services (WPS) and Government
Emergency Telecommunications Service (GETS) are examples of systems Emergency Telecommunications Service (GETS) are examples of systems
designed to address these first responder needs. designed to address the command and control aspects of these first
responder needs.
5.2. Emergency Call Related Signaling 5.2. Emergency Call Related Signaling
Similar to the first responder scenario, there is also signaling Similar to the first responder scenario, there is also signaling
associated with emergency calls. Given the critical nature of these associated with emergency calls. Given the critical nature of these
emergency calls, this signaling should also be given preferential emergency calls, this signaling should also be given preferential
treatment when possible. treatment when possible.
5.3. Differentiated Services 5.3. Differentiated Services
skipping to change at page 6, line 42 skipping to change at page 6, line 47
ending requests were to be throttled. ending requests were to be throttled.
There are also scenarios where the priority of requests for There are also scenarios where the priority of requests for
individual command codes within an application depends on the context individual command codes within an application depends on the context
that exists when the request is sent. There isn't always information that exists when the request is sent. There isn't always information
in the message from which this context can be determined by Diameter in the message from which this context can be determined by Diameter
nodes other than the node that originates the request. nodes other than the node that originates the request.
This is similar to the scenario where a series of requests are needed 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 to access a network service. It is different in that the series of
requests involve different application command-codes. In this requests involve different application command codes. In this
scenario it is requests with the same command-code that have scenario it is requests with the same command code that have
different implied priorities. different implied priorities.
One example of this is in the 3GPP application [S6a] where a ULR One example of this is in the 3GPP application [S6a] where a ULR
request resulting from an MME restoration procedure might be given request resulting from an MME restoration procedure might be given
a higher priority than a ULR resulting from an initial attach. a higher priority than a ULR resulting from an initial attach.
6. Theory of Operation 6. Theory of Operation
This section outlines the envisioned usage of DRMP. This section outlines the envisioned usage of DRMP.
skipping to change at page 7, line 31 skipping to change at page 7, line 35
transaction state. This will be used when handling the answer transaction state. This will be used when handling the answer
messages. messages.
2. Agents handing the request - Agents use the priority information 2. Agents handing the request - Agents use the priority information
when making routing decisions. This can include determining when making routing decisions. This can include determining
which requests to route first, which requests to throttle and which requests to route first, which requests to throttle and
where the request is routed. For instance, requests with higher where the request is routed. For instance, requests with higher
priority might have a lower probability of being throttled. The priority might have a lower probability of being throttled. The
mechanism for how the agent determines which requests are mechanism for how the agent determines which requests are
throttled is implementation dependent and is outside the scope of throttled is implementation dependent and is outside the scope of
this document. The agent also records the transaction priority this document. The agent also saves the transaction priority in
in the transaction state. This will be used when handling the the transaction state, either as locally managed state or using
associated answer message for the transaction. 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 3. Request handler - The handler of the request, be it a Diameter
Server or a Diameter Client, can use the priority information to Server or a Diameter Client, can use the priority information to
determine how to handle the request. This could include determine how to handle the request. This could include
determining the order in which requests are handled and resources determining the order in which requests are handled and resources
that are applied to handling of the request. that are applied to handling of the request.
4. Answer sender - The handler of the request is also the sender of 4. Answer sender - The handler of the request is also the sender of
the answer. The answer sender uses the priority information the answer. The answer sender uses the priority information
received in the request message when sending the answer. This received in the request message when sending the answer. This
implies that answers for higher priority transactions are given implies that answers for higher priority transactions are given
preferential treatment to lower priority transactions. The preferential treatment to lower priority transactions. The
answer sender also has the option of including priority answer sender also has the option of including priority
information in the answer message. This is done what the answer information in the answer message. This is done when the answer
message needs to have a different priority than the priority message needs to have a different priority than the priority
carried in the request message. 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 5. Agent handling the answer - By default, agents handling answer
messages use the priority information stored with the transaction messages use the priority information stored with the transaction
state to determine the priority of relaying the answer message. state to determine the priority of relaying the answer message.
However, priority information included in the answer message, However, priority information included in the answer message,
when present, is used in place of the stored priority when present, is used in place of the stored priority
information. The use of priority information implies that information. The use of priority information implies that
answers for higher priority transactions are given preferential answers for higher priority transactions are given preferential
treatment to lower priority transactions. treatment to lower priority transactions.
6. Answer handler - The answer handler uses the same method as the 6. Answer handler - The answer handler uses the same method as the
agent to determine the priority of the answer message. By agent to determine the priority of the answer message. By
default the handler of the answer message uses the priority of default the handler of the answer message uses the priority saved
the transaction. Priority information in the answer message is in the transaction's state. Priority information in the answer
used when present. The priority is used when allocating message is used when present. The priority is used when
resources for processing that occurs after the receipt of the allocating resources for processing that occurs after the receipt
answer message. of the answer message.
7. Extensibility 7. Extensibility
This document does not define extensibility mechanisms that are This document does not define extensibility mechanisms that are
specific to the DRMP mechanism. As a result, any extension that specific to the DRMP mechanism. As a result, any extension that
requires new AVPs will be required to use existing Diameter requires new AVPs will be required to use existing Diameter
extensibility mechanisms defined in [RFC6733] extensibility mechanisms defined in [RFC6733].
8. Normative Behavior 8. Normative Behavior
This section contains the normative behavior associated with Diameter This section contains the normative behavior associated with Diameter
Resource Message Priority (DRMP). Resource Message Priority (DRMP).
When routing priority information is available, Diameter nodes SHOULD When routing priority information is available, Diameter nodes SHOULD
include Diameter routing message priority in the DRMP AVP in all include Diameter routing message priority in the DRMP AVP in all
Diameter request messages. Diameter request messages.
skipping to change at page 9, line 29 skipping to change at page 9, line 33
Diameter endpoints MAY include the DRMP AVP in answer messages. This Diameter endpoints MAY include the DRMP AVP in answer messages. This
is done when the priority for the answer message needs to have a is done when the priority for the answer message needs to have a
different priority than the priority carried in the request message. different priority than the priority carried in the request message.
When determining the priority to apply to answer messages, Diameter When determining the priority to apply to answer messages, Diameter
nodes MUST use the priority indicated in the DRMP AVP carried in the nodes MUST use the priority indicated in the DRMP AVP carried in the
answer message, if it exists. Otherwise, the Diameter node MUST use answer message, if it exists. Otherwise, the Diameter node MUST use
the priority indicated in the DRMP AVP of the associated request the priority indicated in the DRMP AVP of the associated request
message. 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 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 Diameter nodes MUST have a default priority to apply to transactions
that do not have an explicit priority set in the DRMP AVP. that do not have an explicit priority set in the DRMP AVP.
Diameter nodes SHOULD use the PRIORITY_10 priority as this default Diameter nodes SHOULD use the PRIORITY_10 priority as this default
value. value.
Diameter nodes MUST support the ability for the default priority to Diameter nodes MUST support the ability for the default priority to
be modified through local configuration interfaces. be modified through local configuration interfaces.
Note: There are scenarios where operators might want to specify a Note: There are scenarios where operators might want to specify a
skipping to change at page 13, line 7 skipping to change at page 13, line 16
New AVPs defined by this specification are listed in Section 9. All New AVPs defined by this specification are listed in Section 9. All
AVP codes are allocated from the 'Authentication, Authorization, and AVP codes are allocated from the 'Authentication, Authorization, and
Accounting (AAA) Parameters' AVP Codes registry. Accounting (AAA) Parameters' AVP Codes registry.
10.2. New registries 10.2. New registries
There are no new IANA registries introduced by this document. There are no new IANA registries introduced by this document.
11. Security Considerations 11. Security Considerations
The DRMP could be used to get better access to services. This could DRMP gives Diameter nodes the ability to influence which requests are
result in one segment of a Diameter network gaining assess to are throttled during overload scenarios. Improper use of the DRMP
services that would otherwise be given to other segments of the mechanism could result in the malicious Diameter node gaining
Diamter network. 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 12. Contributors
The following people contributed substantial ideas, feedback, and The following people contributed substantial ideas, feedback, and
discussion to this document: discussion to this document:
o Janet P. Gunn o Janet P. Gunn
13. References 13. References
 End of changes. 19 change blocks. 
34 lines changed or deleted 130 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/