< draft-ietf-dime-drmp-05.txt   draft-ietf-dime-drmp-06.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 April 5, 2016 Intended status: Standards Track May 18, 2016
Expires: October 7, 2016 Expires: November 19, 2016
Diameter Routing Message Priority Diameter Routing Message Priority
draft-ietf-dime-drmp-05.txt draft-ietf-dime-drmp-06.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 October 7, 2016. This Internet-Draft will expire on November 19, 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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. First Responder Related Signaling . . . . . . . . . . . . 5 5.1. First Responder Related Signaling . . . . . . . . . . . . 6
5.2. Emergency Call Related Signaling . . . . . . . . . . . . 5 5.2. Emergency Call Related Signaling . . . . . . . . . . . . 6
5.3. Differentiated Services . . . . . . . . . . . . . . . . . 6 5.3. Differentiated Services . . . . . . . . . . . . . . . . . 6
5.4. Application Specific Priorities . . . . . . . . . . . . . 6 5.4. Application Specific Priorities . . . . . . . . . . . . . 7
6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8
7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 9 8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 10
9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 11 9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 12
9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 12 9.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Considerations When Defining Application Priorities . . . . . 13
10.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.2. New registries . . . . . . . . . . . . . . . . . . . . . 12 11.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11.2. New registries . . . . . . . . . . . . . . . . . . . . . 15
11.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11.2. Denial of Service Attacks . . . . . . . . . . . . . . . 14 12.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 15
11.3. End-to End-Security Issues . . . . . . . . . . . . . . . 14 12.2. Denial of Service Attacks . . . . . . . . . . . . . . . 16
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 12.3. End-to End-Security Issues . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . 15 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . 15 14.1. Normative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Diameter Overload Indication Conveyance (DOIC) solution [RFC7683] The Diameter Overload Indication Conveyance (DOIC) solution [RFC7683]
for Diameter overload control introduces scenarios where Diameter for Diameter overload control introduces scenarios where Diameter
routing decisions made by Diameter nodes can be influenced by the routing decisions made by Diameter nodes can be influenced by the
overload state of other Diameter nodes. This includes the scenarios overload state of other Diameter nodes. This includes the scenarios
where Diameter endpoints and Diameter agents can throttle requests as where Diameter endpoints and Diameter agents can throttle requests as
a result of the target for the request being overloaded. a result of the target for the request being overloaded.
skipping to change at page 3, line 16 skipping to change at page 3, line 18
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 being probability of transactions involving first responders being
throttled during overload scenarios caused, for example, by a period throttled during overload scenarios caused, for example, by a period
of heavy signaling resulting from a natural disaster. 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.
1.1. Applicability
There are two primary considerations that must be addressed for the
mechanism described in this document to work effectively. The first
takes into consideration that the Diameter base protocol defined in
[RFC6733] is designed to transport multiple Diameter applications
and that Diameter nodes can be implemented that support multiple
applications. In order for the 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. See Section 10 for a discussion of some of the
considerations that need to be factored into the setting of DRMP
priorities 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 AVP 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 priority 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.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
Diversion Diversion
As defined in [RFC7683]. An overload abatement treatment where As defined in [RFC7683]. An overload abatement treatment where
the reacting node selects alternate destinations or paths for the reacting node selects alternate destinations or paths for
requests. requests.
DOIC DOIC
skipping to change at page 4, line 47 skipping to change at page 5, line 38
While the primary usage of DRMP defined priorities is for input to While the primary usage of DRMP defined priorities is for input to
Diameter overload control related throttling decisions, it is also Diameter overload control related throttling decisions, it is also
expected that the priority information could also be used for other expected that the priority information could also be used for other
routing related functionality. This might include giving higher routing related functionality. This might include giving higher
priority transactions preferential treatment when selecting routes. priority transactions preferential treatment when selecting routes.
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. It might also use the priority information to as a reason
to fail a request as a result of insufficient resources.
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
Attribute Value Pairs (AVPs) as input to throttling and other Attribute Value Pairs (AVPs) as input to throttling and other
Diameter routing decisions would require Diameter agents to Diameter routing decisions would require Diameter agents to
understand all applications and do application specific parsing of understand all applications and do application specific parsing of
all messages in order to determine the priority of individual all messages in order to determine the priority of individual
messages. This is considered an unacceptable level of complexity messages. This is considered an unacceptable level of complexity
to put on elements whose primary responsibility is to route to put on elements whose primary responsibility is to route
Diameter messages. 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.
It is important to note that for priority information to be reliably
usable, the Diameter nodes sending and consuming DRMP AVPs must have
pre-established trust relationships of the sort described in
Section 12.
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
mechanisms to request a reduction in traffic. This in turn results mechanisms to request a reduction in traffic. This in turn results
in requests being throttled in an attempt to control the overload in requests being throttled in an attempt to control the overload
skipping to change at page 6, line 36 skipping to change at page 7, line 31
than those that occur early in the series. This would recognize that than those that occur early in the series. This would recognize that
there was potentially significant work done by the network already there was potentially significant work done by the network already
that would be lost if those later transactions were throttled. that would be lost if those later transactions were throttled.
There are also scenarios where an agent cannot easily differentiate a There are also scenarios where an agent cannot easily differentiate a
request that starts a session from requests that update or end request that starts a session from requests that update or end
sessions. In these scenarios it might be appropriate to mark the sessions. In these scenarios it might be appropriate to mark the
requests that establish new sessions with a lower priority than requests that establish new sessions with a lower priority than
updates and session ending requests. This also recognizes that more updates and session ending requests. This also recognizes that more
work has already taken place for established sessions and, as a work has already taken place for established sessions and, as a
result, it might be more harmful if the session update and session result, it might be more harmful from a signaling point of view if
ending requests were to be throttled. the session update and session 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
skipping to change at page 7, line 33 skipping to change at page 8, line 30
request sender also saves the priority information with the request sender also saves the priority information with the
transaction state. This will be used when handling the answer transaction state. This will be used when handling the answer
messages. messages.
2. Agents handling the request - Agents use the priority information 2. Agents handling 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 candidates to be throttled is implementation dependent and is
this document. Before forwarding request messages, agents outside the scope of this document. Before forwarding request
generally do not modify the priority information present in the messages, agents generally do not modify the priority information
received request message nor include the priority information present in the received request message nor include the priority
when absent in the received request message. However, in some information when absent in the received request message.
scenarios, agents can modify the priority information, for However, in some scenarios, agents can modify the priority
example, edge agents modifying the priority values set by an information, for example, edge agents modifying the priority
adjacent operator. There might be other scenarios where a values set by an adjacent operator. There might be other
Diameter endpoint does not support the DRMP mechanism and agents scenarios where a Diameter endpoint does not support the DRMP
insert the priority information in the request messages for that mechanism and agents insert the priority information in the
non supporting endpoint. When forwarding the request messages, request messages for that non supporting endpoint. When
the agent also saves the transaction priority in the transaction forwarding the request messages, the agent also saves the
state, either as locally managed state or using the Proxy-Info transaction priority in the transaction state, either as locally
mechanism defined in [RFC6733]. This will be used when handling managed state or using the Proxy-Info mechanism defined in
the associated answer message for the transaction. [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
skipping to change at page 10, line 15 skipping to change at page 11, line 15
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.
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 SHOULD use the priority indicated in the DRMP AVP carried in
answer message, if it exists. Otherwise, the Diameter node MUST use the answer message, if it exists. If there is not DRMP AVP in the
the priority indicated in the DRMP AVP of the associated request answer message then the Diameter node SHOULD use the priority
message. indicated in the DRMP AVP of the associated request message.
Note: One method to determine what priority to apply to an answer 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 when there is no DRMP AVP in the answer message is to save the
priority included in the request message in state associated with priority included in the request message in state associated with
the Diameter transaction. Another is to use the Proxy-Info the Diameter transaction. Another is to use the Proxy-Info
mechanism defined in [RFC6733]. 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.
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 priority value of PRIORITY_10.
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
different default value for transactions that do not have an different default value for transactions that do not have an
explicit priority. In this case, the operator defined local explicit priority. In this case, the operator defined local
policy would override the use of PRIORITY_10 as the default policy would override the use of PRIORITY_10 as the default
priority. priority.
When using DRMP priority information, Diameter nodes MUST use the When using DRMP priority information, Diameter nodes MUST use the
skipping to change at page 11, line 13 skipping to change at page 12, line 15
not insert a DRMP AVP with a priority value of 10. not insert a DRMP AVP with a priority value of 10.
When setting and using priorities, for all integers x,y in [0,15] When setting and using priorities, for all integers x,y in [0,15]
treat PRIORITY_<x> as lower priority than PRIOIRTY_<y> when y<x. treat PRIORITY_<x> as lower priority than PRIOIRTY_<y> when y<x.
Note: As a result PRIORITY_0 is the highest priority. Note: As a result PRIORITY_0 is the highest priority.
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 Pair (AVP) 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 defined: following values are defined:
PRIORITY_15 15 PRIORITY_15 is the lowest priority. PRIORITY_15 15 PRIORITY_15 is the lowest priority.
skipping to change at page 12, line 31 skipping to change at page 13, line 34
+---------+ +---------+
|AVP flag | |AVP flag |
|rules | |rules |
+----+----+ +----+----+
AVP Section | |MUST| AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT| Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------+----+----+ +--------------------------------------------------+----+----+
|DRMP TBD1 x.x Enumerated | | V | |DRMP TBD1 x.x Enumerated | | V |
+--------------------------------------------------+----+----+ +--------------------------------------------------+----+----+
10. IANA Considerations 10. Considerations When Defining Application Priorities
10.1. AVP codes As discussed in 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.
New AVPs defined by this specification are listed in Section 9. All The following are some things to be considered when defining the DRMP
AVP codes are allocated from the 'Authentication, Authorization, and priorities to be used in Diameter networks which support Diameter
Accounting (AAA) Parameters' AVP Codes registry. nodes handling multiple applications.
10.2. New registries 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 use cases, 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 threatment. 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.
11. IANA Considerations
11.1. AVP codes
The new AVP defined by this specification is listed in Section 9.
All AVP codes are allocated from the 'Authentication, Authorization,
and Accounting (AAA) Parameters' AVP Codes registry.
11.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 12. Security Considerations
DRMP gives Diameter nodes the ability to influence which requests are DRMP gives Diameter nodes the ability to influence which requests are
throttled during overload scenarios. Improper use of the DRMP throttled during overload scenarios. In addition, DRMP can be used
mechanism could result in the malicious Diameter node gaining in determining the routing decisions for request messages. Improper
preferential treatment, by reducing the probability of its requests use of the DRMP mechanism could result in the malicious Diameter node
being throttled, over other Diameter nodes. This would be achieved gaining preferential treatment, by reducing the probability of its
by the malicious node inserting artificially high priority values. 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 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 12.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., Transmission Control Protocol (TCP) or Stream Control (e.g., Transmission Control Protocol (TCP) or Stream Control
Transmission Protocol (SCTP)) connection, or the messages may Transmission Protocol (SCTP)) connection, or the messages may
traverse one or more intermediaries, known as Diameter Agents. traverse one or more intermediaries, known as Diameter Agents.
Diameter nodes use Transport Layer Security (TLS), Datagram Transport Diameter nodes use Transport Layer Security (TLS), Datagram Transport
Layer Security (DTLS), or IPsec to authenticate peers, and to provide 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.
skipping to change at page 14, line 7 skipping to change at page 16, line 21
in scope to when one or more Diameter nodes are in an overloaded in scope to when one or more Diameter nodes are in an overloaded
state. state.
The DRMP mechanism can also be used to influence the order in which The DRMP mechanism can also be used to influence the order in which
Diameter messages are handled by Diameter nodes. The above attacks Diameter messages are handled by Diameter nodes. The above attacks
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 12.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 degraded 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 12.3. End-to End-Security Issues
The lack of end-to-end integrity features in Diameter [RFC6733] makes The lack of end-to-end integrity features in Diameter [RFC6733] makes
it difficult to establish trust in DRMP AVPs received from non- it difficult to establish trust in DRMP AVPs received from non-
adjacent nodes. Any agents in the message path may insert or modify adjacent nodes. Any agents in the message path may insert or modify
DRMP AVPs. Nodes must trust that their adjacent peers perform proper DRMP AVPs. Nodes must trust that their adjacent peers perform proper
checks on overload reports from their peers, and so on, creating a checks on overload reports from their peers, and so on, creating a
transitive-trust requirement extending for potentially long chains of transitive-trust requirement extending for potentially long chains of
nodes. Network operators must determine if this transitive trust nodes. Network operators must determine if this transitive trust
requirement is acceptable for their deployments. Nodes supporting requirement is acceptable for their deployments. Nodes supporting
DRMP MUST give operators the ability to select which peers are DRMP MUST give operators the ability to select which peers are
skipping to change at page 14, line 41 skipping to change at page 17, line 7
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.
12. Contributors 13. 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 14. References
13.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>. <http://www.rfc-editor.org/info/rfc6733>.
13.2. Informative References 14.2. Informative References
[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
Morand, "Diameter Overload Indication Conveyance", Morand, "Diameter Overload Indication Conveyance",
RFC 7683, DOI 10.17487/RFC7683, October 2015, RFC 7683, DOI 10.17487/RFC7683, October 2015,
<http://www.rfc-editor.org/info/rfc7683>. <http://www.rfc-editor.org/info/rfc7683>.
[S6a] 3GPP, "Evolved Packet System (EPS); Mobility Management [S6a] 3GPP, "Evolved Packet System (EPS); Mobility Management
Entity (MME) and Serving GPRS Support Node (SGSN) related Entity (MME) and Serving GPRS Support Node (SGSN) related
interfaces based on Diameter protocol", 3GPP TS 29.272 interfaces based on Diameter protocol", 3GPP TS 29.272
10.8.0, June 2013. 10.8.0, June 2013.
 End of changes. 27 change blocks. 
70 lines changed or deleted 174 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/