draft-ietf-dime-drmp-04.txt   draft-ietf-dime-drmp-05.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 March 10, 2016 Intended status: Standards Track April 5, 2016
Expires: September 11, 2016 Expires: October 7, 2016
Diameter Routing Message Priority Diameter Routing Message Priority
draft-ietf-dime-drmp-04.txt draft-ietf-dime-drmp-05.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 September 11, 2016. This Internet-Draft will expire on October 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . . . . . . . . . 12
10.2. New registries . . . . . . . . . . . . . . . . . . . . . 12 10.2. New registries . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 13 11.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 13
11.2. Denial of Service Attacks . . . . . . . . . . . . . . . 14 11.2. Denial of Service Attacks . . . . . . . . . . . . . . . 14
11.3. End-to End-Security Issues . . . . . . . . . . . . . . . 14 11.3. End-to End-Security Issues . . . . . . . . . . . . . . . 14
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 14 13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The DOIC solution [RFC7683] for Diameter overload control introduces The Diameter Overload Indication Conveyance (DOIC) solution [RFC7683]
scenarios where Diameter routing decisions made by Diameter nodes can for Diameter overload control introduces scenarios where Diameter
be influenced by the overload state of other Diameter nodes. This routing decisions made by Diameter nodes can be influenced by the
includes the scenarios where Diameter endpoints and Diameter agents overload state of other Diameter nodes. This includes the scenarios
can throttle requests as a result of the target for the request being where Diameter endpoints and Diameter agents can throttle requests as
overloaded. a result of the target for the request being 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 being
period of heavy signaling resulting from a natural disaster being throttled during overload scenarios caused, for example, by a period
throttled during overload scenarios. of heavy signaling resulting from a natural disaster.
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
information other Diameter nodes can factor the relative priority of information other Diameter nodes can factor the relative priority of
requests into routing and throttling decisions. requests into routing and throttling decisions.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
Diversion Diversion
skipping to change at page 3, line 46 skipping to change at page 3, line 46
node. Abatement actions include diversion and throttling. node. Abatement actions include diversion and throttling.
Priority Priority
The relative importance of a Diameter message. A lower priority The relative importance of a Diameter message. A lower priority
value implies a higher relative importance of the message. value implies a higher relative importance of the message.
Throttling Throttling
As defined in [RFC7683]. An abatement treatment that limits the As defined in [RFC7683]. An abatement treatment that limits the
number of requests sent by the DIOC reacting node. Throttling can number of requests sent by the DOIC reacting node. Throttling can
include a Diameter Client choosing to not send requests, or a include a Diameter Client choosing to not send requests, or a
Diameter Agent or Server rejecting requests with appropriate error Diameter Agent or Server rejecting requests with appropriate error
responses. In both cases the result of the throttling is a responses. In both cases the result of the throttling is a
permanent rejection of the transaction. permanent rejection of the transaction.
3. Conventions Used in This Document 3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 4, line 52 skipping to change at page 4, line 52
It is also envisioned that DRMP priority information could be used by It is also envisioned that DRMP priority information could be used by
Diameter endpoints to make resource allocation decisions. For Diameter endpoints to make resource allocation decisions. For
instance, a Diameter Server might choose to use the priority instance, a Diameter Server might choose to use the priority
information to treat higher priority requests ahead of lower priority information to treat higher priority requests ahead of lower priority
requests. requests.
Note: There are a number of application specific definitions Note: There are a number of application specific definitions
indicating various views of application level priority for indicating various views of application level priority for
different requests. Using these application specific priority different requests. Using these application specific priority
AVPs as input to throttling and other Diameter routing decisions Attribute Value Pairs (AVPs) as input to throttling and other
would require Diameter agents to understand all applications and Diameter routing decisions would require Diameter agents to
do application specific parsing of all messages in order to understand all applications and do application specific parsing of
determine the priority of individual messages. This is considered all messages in order to determine the priority of individual
an unacceptable level of complexity to put on elements whose messages. This is considered an unacceptable level of complexity
primary responsibility is to route Diameter messages. to put on elements whose primary responsibility is to route
Diameter messages.
5. Use Cases 5. Use Cases
This section discusses 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
skipping to change at page 6, line 12 skipping to change at page 6, line 12
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
Operators may desire to differentiate network-based services by Operators may desire to differentiate network-based services by
providing a service level agreement that includes preferential providing a service level agreement that includes preferential
Diameter routing behavior. This might, for example, be modeled as Diameter routing behavior. This might, for example, be modeled as
Platinum, Gold and Silver levels of service. Platinum, Gold and Silver levels of service.
In this scenario an operator might offer a Platinum SLA the includes In this scenario an operator might offer a Platinum SLA that includes
ensuring that all signaling for a customer who purchases the Platinum ensuring that all signaling for a customer who purchases the Platinum
service being marked as having a higher priority than signaling service being marked as having a higher priority than signaling
associated with Gold and Silver customers. associated with Gold and Silver customers.
5.4. Application Specific Priorities 5.4. Application Specific Priorities
There are scenarios within Diameter applications where it might be There are scenarios within Diameter applications where it might be
appropriate to give a subset of the transactions for the application appropriate to give a subset of the transactions for the application
a higher priority than other transactions for that application. a higher priority than other transactions for that application.
skipping to change at page 6, line 48 skipping to change at page 6, line 48
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 requests with the same command code have different implied
different implied priorities. 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 an
request resulting from an MME (Mobility Management Entity) Update Location Request (ULR) request resulting from an MME
restoration procedure might be given a higher priority than a ULR (Mobility Management Entity) restoration procedure might be given
(Update Location Request) resulting from an initial attach. a higher priority than a ULR (Update Location Request) 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.
The expected behavior depends on the role (request sender, agent or The expected behavior depends on the role (request sender, agent or
request handler) of the Diameter node handling the request. request handler) of the Diameter node handling the request.
The following behavior is expected during the flow of a Diameter The following behavior is expected during the flow of a Diameter
transaction. transaction.
skipping to change at page 8, line 34 skipping to change at page 8, line 34
answers for higher priority transactions are given preferential answers for higher priority transactions are given preferential
treatment to lower priority transactions. When forwarding the treatment to lower priority transactions. When forwarding the
answer messages, agents generally do not modify the priority answer messages, agents generally do not modify the priority
information present in the received answer messages nor include information present in the received answer messages nor include
the priority information when absent in the received answer the priority information when absent in the received answer
messages. However, in some scenarios, agents can modify the messages. However, in some scenarios, agents can modify the
priority information, for example, edge agents modifying the priority information, for example, edge agents modifying the
priority values set by an adjacent operator. There might be priority values set by an adjacent operator. There might be
other scenarios where a Diameter endpoint does not support the other scenarios where a Diameter endpoint does not support the
DRMP mechanism and agents insert the priority information for DRMP mechanism and agents insert the priority information for
that non supporting endpoint. that non-supporting endpoint.
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 saved default the handler of the answer message uses the priority saved
in the transaction's state. Priority information in the answer in the transaction's state. Priority information in the answer
message is used when present. The priority is used when message is used when present. The priority is used when
allocating resources for processing that occurs after the receipt allocating resources for processing that occurs after the receipt
of the answer message. of the answer message.
7. Extensibility 7. Extensibility
skipping to change at page 9, line 29 skipping to change at page 9, line 29
understand application specific AVPs. understand application specific AVPs.
When available, Diameter nodes SHOULD use routing priority When available, Diameter nodes SHOULD use routing priority
information included in the DRMP AVP when making Diameter overload information included in the DRMP AVP when making Diameter overload
throttling decisions. throttling decisions.
Diameter agents MAY use routing priority information included in the Diameter agents MAY use routing priority information included in the
DRMP AVP when relaying request and answer messages. This includes DRMP AVP when relaying request and answer messages. This includes
the selection of routes and the ordering of messages relayed. the selection of routes and the ordering of messages relayed.
The priority information included in the DRMP AVP in request Note: The priority information included in the DRMP AVP in request
messages applies to both the request message and, by default, messages applies to both the request message and, by default,
answer message associated with the transaction. answer message associated with the transaction.
While done only in exceptional circumstances, Diameter agents MAY While done only in exceptional circumstances, Diameter agents MAY
modify priority information when relaying request and answer modify priority information when relaying request and answer
messages. messages.
There might be scenarios where a Diameter agent does modify Note: There might be scenarios where a Diameter agent does modify
priority information. For instance, an edge agent might need to priority information. For instance, an edge agent might need to
modify the priority values set by an adjacent operator. modify the priority values set by an adjacent operator.
While done only in exceptional circumstances, Diameter agents MAY add While done only in exceptional circumstances, Diameter agents MAY add
priority information when relaying request and answer messages. priority information when relaying request and answer messages.
There might be scenarios where a Diameter endpoint does not Note: There might be scenarios where a Diameter endpoint does not
support the DRMP mechanism and agents insert priority information support the DRMP mechanism and agents insert priority information
for that non supporting endpoint. for that non-supporting endpoint.
Diameter endpoints MAY use routing priority information included in Diameter endpoints MAY use routing priority information included in
the DRMP AVP when making resource allocation decisions for the the DRMP AVP when making resource allocation decisions for the
transaction associated with the request message that contains the transaction associated with the request message that contains the
DRMP information. DRMP information.
Diameter endpoints MAY use routing priority information included in Diameter endpoints MAY use routing priority information included in
the DRMP AVP when making resource allocation decisions for the the DRMP AVP when making resource allocation decisions for the
transaction associated with the answer messages using the DRMP transaction associated with the answer messages using the DRMP
information associated with the transaction. information associated with the transaction.
skipping to change at page 11, line 20 skipping to change at page 11, line 20
9. Attribute Value Pairs 9. Attribute Value Pairs
This section describes the encoding and semantics of the Diameter This section describes the encoding and semantics of the Diameter
Overload Indication Attribute Value Pairs (AVPs) defined in this Overload Indication Attribute Value Pairs (AVPs) defined in this
document. document.
9.1. DRMP AVP 9.1. DRMP AVP
The DRMP (AVP code TBD1) is of type Enumerated. The value of the AVP The DRMP (AVP code TBD1) is of type Enumerated. The value of the AVP
indicates the routing message priority for the transaction. The indicates the routing message priority for the transaction. The
following values are initially defined: following values are defined:
PRIORITY_15 15 PRIORITY_15 is the lowest priority. PRIORITY_15 15 PRIORITY_15 is the lowest priority.
PRIORITY_14 14 PRIORITY_14 is a higher priority than PRIORITY_15 and PRIORITY_14 14 PRIORITY_14 is a higher priority than PRIORITY_15 and
a lower priority than PRIORITY_13. a lower priority than PRIORITY_13.
PRIORITY_13 13 PRIORITY_13 is a higher priority than PRIORITY_14 and PRIORITY_13 13 PRIORITY_13 is a higher priority than PRIORITY_14 and
a lower priority than PRIORITY_12. a lower priority than PRIORITY_12.
PRIORITY_12 12 PRIORITY_12 is a higher priority than PRIORITY_13 and PRIORITY_12 12 PRIORITY_12 is a higher priority than PRIORITY_13 and
skipping to change at page 12, line 46 skipping to change at page 12, line 46
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
DRMP gives Diameter nodes the ability to influence which requests are DRMP gives Diameter nodes the ability to influence which requests are
are throttled during overload scenarios. Improper use of the DRMP throttled during overload scenarios. Improper use of the DRMP
mechanism could result in the malicious Diameter node gaining mechanism could result in the malicious Diameter node gaining
preferential treatment, by reducing the probability of its requests preferential treatment, by reducing the probability of its requests
being throttled, over other Diameter nodes. This would be achieved being throttled, over other Diameter nodes. This would be achieved
by the malicious node inserting artificially high priority values. by the malicious node inserting artificially high priority values.
Diameter does not include features to provide end-to-end Diameter does not include features to provide end-to-end
authentication, integrity protection, or confidentiality. This opens authentication, integrity protection, or confidentiality. This opens
the possibility that malicious or compromised agents in the path of a the possibility that malicious or compromised agents in the path of a
request could modify the DRMP AVP to reflect a priority different request could modify the DRMP AVP to reflect a priority different
than that asserted by the sender of the request. than that asserted by the sender of the request.
11.1. Potential Threat Modes 11.1. Potential Threat Modes
The Diameter protocol involves transactions in the form of requests The Diameter protocol involves transactions in the form of requests
and answers exchanged between clients and servers. These clients and and answers exchanged between clients and servers. These clients and
servers may be peers, that is, they may share a direct transport 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 (e.g., Transmission Control Protocol (TCP) or Stream Control
more intermediaries, known as Diameter Agents. Diameter nodes use Transmission Protocol (SCTP)) connection, or the messages may
TLS, DTLS, or IPsec to authenticate peers, and to provide traverse one or more intermediaries, known as Diameter Agents.
Diameter nodes use Transport Layer Security (TLS), Datagram Transport
Layer Security (DTLS), or IPsec to authenticate peers, and to provide
confidentiality and integrity protection of traffic between peers. confidentiality and integrity protection of traffic between peers.
Nodes can make authorization decisions based on the peer identities Nodes can make authorization decisions based on the peer identities
authenticated at the transport layer. authenticated at the transport layer.
When agents are involved, this presents an effectively transitive When agents are involved, this presents an effectively transitive
trust model. That is, a Diameter client or server can authorize an trust model. That is, a Diameter client or server can authorize an
agent for certain actions, but it must trust that agent to make agent for certain actions, but it must trust that agent to make
appropriate authorization decisions about its peers, and so on. appropriate authorization decisions about its peers, and so on.
Since confidentiality and integrity protection occurs at the Since confidentiality and integrity protection occurs at the
transport layer, agents can read, and perhaps modify, any part of a transport layer, agents can read, and perhaps modify, any part of a
skipping to change at page 14, line 10 skipping to change at page 14, line 12
have a potentially greater impact in this scenario as the priority have a potentially greater impact in this scenario as the priority
indication impacts the handling of all requests at all times, indication impacts the handling of all requests at all times,
independent of the overload status of Diameter nodes in the Diameter independent of the overload status of Diameter nodes in the Diameter
network. network.
11.2. Denial of Service Attacks 11.2. Denial of Service Attacks
The DRMP mechanism does not open direct denial of service attack The DRMP mechanism does not open direct denial of service attack
vectors. Rather, it introduces a mechanism where a node can gain vectors. Rather, it introduces a mechanism where a node can gain
unwarranted preferential treatment. It also introduces a mechanism unwarranted preferential treatment. It also introduces a mechanism
where a node can get degrated service in the scenario where a rogue where a node can get degraded service in the scenario where a rogue
agent changes the priority value included in messages. agent changes the priority value included in messages.
11.3. End-to End-Security Issues 11.3. End-to End-Security Issues
The lack of end-to-end integrity features makes it difficult to The lack of end-to-end integrity features in Diameter [RFC6733] makes
establish trust in DRMP AVPs received from non-adjacent nodes. Any it difficult to establish trust in DRMP AVPs received from non-
agents in the message path may insert or modify DRMP AVPs. Nodes adjacent nodes. Any agents in the message path may insert or modify
must trust that their adjacent peers perform proper checks on DRMP AVPs. Nodes must trust that their adjacent peers perform proper
overload reports from their peers, and so on, creating a transitive- checks on overload reports from their peers, and so on, creating a
trust requirement extending for potentially long chains of nodes. transitive-trust requirement extending for potentially long chains of
Network operators must determine if this transitive trust requirement nodes. Network operators must determine if this transitive trust
is acceptable for their deployments. Nodes supporting DRMP MUST give requirement is acceptable for their deployments. Nodes supporting
operators the ability to select which peers are trusted to deliver DRMP MUST give operators the ability to select which peers are
DRMP AVPs, and whether they are trusted to forward the DRMP AVPs from trusted to deliver DRMP AVPs, and whether they are trusted to forward
non-adjacent nodes. Diameter nodes MUST strip DRMP AVPs from the DRMP AVPs from non-adjacent nodes. Diameter nodes MUST strip
messages received from peers that are not trusted for DRMP purposes. 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 is expected that work on end-to-end Diameter security might make
it easier to establish trust in non-adjacent nodes for DRMP purposes. it easier to establish trust in non-adjacent nodes for DRMP purposes.
Readers should be reminded, however, that the DRMP mechanism allows Readers should be reminded, however, that the DRMP mechanism allows
Diameter agents to modify AVPs in existing messages that are Diameter agents to modify AVPs in existing messages that are
originated by other nodes. If end-to-end security is enabled, there originated by other nodes. If end-to-end security is enabled, there
is a risk that such modification could violate integrity protection. is a risk that such modification could violate integrity protection.
The details of using any future Diameter end-to-end security The details of using any future Diameter end-to-end security
mechanism with DRMP will require careful consideration, and are mechanism with DRMP will require careful consideration, and are
beyond the scope of this document. beyond the scope of this document.
 End of changes. 21 change blocks. 
53 lines changed or deleted 58 lines changed or added

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