draft-ietf-dime-overload-reqs-05.txt   draft-ietf-dime-overload-reqs-06.txt 
Network Working Group E. McMurry Network Working Group E. McMurry
Internet-Draft B. Campbell Internet-Draft B. Campbell
Intended status: Standards Track Tekelec Intended status: Standards Track Tekelec
Expires: August 29, 2013 February 25, 2013 Expires: October 19, 2013 April 17, 2013
Diameter Overload Control Requirements Diameter Overload Control Requirements
draft-ietf-dime-overload-reqs-05 draft-ietf-dime-overload-reqs-06
Abstract Abstract
When a Diameter server or agent becomes overloaded, it needs to be When a Diameter server or agent becomes overloaded, it needs to be
able to gracefully reduce its load, typically by informing clients to able to gracefully reduce its load, typically by informing clients to
reduce sending traffic for some period of time. Otherwise, it must reduce sending traffic for some period of time. Otherwise, it must
continue to expend resources parsing and responding to Diameter continue to expend resources parsing and responding to Diameter
messages, possibly resulting in congestion collapse. The existing messages, possibly resulting in congestion collapse. The existing
Diameter mechanisms, listed in Section 3 are not sufficient for this Diameter mechanisms, listed in Section 3 are not sufficient for this
purpose. This document describes the limitations of the existing purpose. This document describes the limitations of the existing
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 August 29, 2013. This Internet-Draft will expire on October 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 39 skipping to change at page 2, line 39
7. Solution Requirements . . . . . . . . . . . . . . . . . . . . 19 7. Solution Requirements . . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 24 9.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 24
9.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 24 9.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 24
9.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 25 9.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 25
9.5. Compromised Hosts . . . . . . . . . . . . . . . . . . . . 25 9.5. Compromised Hosts . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 26
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
When a Diameter [RFC6733] server or agent becomes overloaded, it When a Diameter [RFC6733] server or agent becomes overloaded, it
needs to be able to gracefully reduce its load, typically by needs to be able to gracefully reduce its load, typically by
informing clients to reduce sending traffic for some period of time. informing clients to reduce sending traffic for some period of time.
Otherwise, it must continue to expend resources parsing and Otherwise, it must continue to expend resources parsing and
responding to Diameter messages, possibly resulting in congestion responding to Diameter messages, possibly resulting in congestion
collapse. The existing mechanisms provided by Diameter are not collapse. The existing mechanisms provided by Diameter are not
skipping to change at page 19, line 18 skipping to change at page 19, line 18
control Diameter overload, with the goals of improving the issues control Diameter overload, with the goals of improving the issues
described in Section 4 and supporting the scenarios described in described in Section 4 and supporting the scenarios described in
Section 2 Section 2
REQ 1: The overload control mechanism MUST provide a communication REQ 1: The overload control mechanism MUST provide a communication
method for Diameter nodes to exchange load and overload method for Diameter nodes to exchange load and overload
information. information.
REQ 2: The mechanism MUST allow Diameter nodes to support overload REQ 2: The mechanism MUST allow Diameter nodes to support overload
control regardless of which Diameter applications they control regardless of which Diameter applications they
support. support. Diameter clients must be able to use the received
load and overload information to support graceful behavior
during an overload condition. Graceful behavior under
overload conditions is best described by REQ 3.
REQ 3: The overload control mechanism MUST limit the impact of REQ 3: The overload control mechanism MUST limit the impact of
overload on the overall useful throughput of a Diameter overload on the overall useful throughput of a Diameter
server, even when the incoming load on the network is far in server, even when the incoming load on the network is far in
excess of its capacity. The overall useful throughput under excess of its capacity. The overall useful throughput under
load is the ultimate measure of the value of an overload load is the ultimate measure of the value of an overload
control mechanism. control mechanism.
REQ 4: Diameter allows requests to be sent from either side of a REQ 4: Diameter allows requests to be sent from either side of a
connection and either side of a connection may have need to connection and either side of a connection may have need to
skipping to change at page 21, line 41 skipping to change at page 21, line 41
congestion. The mechanism MUST result in at least as much congestion. The mechanism MUST result in at least as much
useful throughput as would have resulted if the overload useful throughput as would have resulted if the overload
control mechanism was not in place. control mechanism was not in place.
REQ 22: The mechanism MUST provide a way for an node to throttle the REQ 22: The mechanism MUST provide a way for an node to throttle the
amount of traffic it receives from an peer node. This amount of traffic it receives from an peer node. This
throttling SHOULD be graded so that it can be applied throttling SHOULD be graded so that it can be applied
gradually as offered load increases. Overload is not a gradually as offered load increases. Overload is not a
binary state; there may be degrees of overload. binary state; there may be degrees of overload.
REQ 23: REMOVED REQ 23: The mechanism MUST provide sufficient information to enable
REQ 24: The mechanism MUST provide sufficient information to enable
a load balancing node to divert messages that are rejected a load balancing node to divert messages that are rejected
or otherwise throttled by an overloaded upstream node to or otherwise throttled by an overloaded upstream node to
other upstream nodes that are the most likely to have other upstream nodes that are the most likely to have
sufficient capacity to process them. sufficient capacity to process them.
REQ 25: The mechanism MUST provide a mechanism for indicating load REQ 24: The mechanism MUST provide a mechanism for indicating load
levels even when not in an overloaded condition, to assist levels even when not in an overloaded condition, to assist
nodes making decisions to prevent overload conditions from nodes making decisions to prevent overload conditions from
occurring. occurring.
REQ 26: The base specification for the overload control mechanism REQ 25: The base specification for the overload control mechanism
SHOULD offer general guidance on which message types might SHOULD offer general guidance on which message types might
be desirable to send or process over others during times of be desirable to send or process over others during times of
overload, based on application-specific considerations. For overload, based on application-specific considerations. For
example, it may be more beneficial to process messages for example, it may be more beneficial to process messages for
existing sessions ahead of new sessions. Some networks may existing sessions ahead of new sessions. Some networks may
have a requirement to give priority to requests associated have a requirement to give priority to requests associated
with emergency sessions. Any normative or otherwise with emergency sessions. Any normative or otherwise
detailed definition of the relative priorities of message detailed definition of the relative priorities of message
types during an overload condition will be the types during an overload condition will be the
responsibility of the application specification. responsibility of the application specification.
REQ 27: The mechanism MUST NOT prevent a node from prioritizing REQ 26: The mechanism MUST NOT prevent a node from prioritizing
requests based on any local policy, so that certain requests requests based on any local policy, so that certain requests
are given preferential treatment, given additional are given preferential treatment, given additional
retransmission, not throttled, or processed ahead of others. retransmission, not throttled, or processed ahead of others.
REQ 28: The overload control mechanism MUST NOT provide new REQ 27: The overload control mechanism MUST NOT provide new
vulnerabilities to malicious attack, or increase the vulnerabilities to malicious attack, or increase the
severity of any existing vulnerabilities. This includes severity of any existing vulnerabilities. This includes
vulnerabilities to DoS and DDoS attacks as well as replay vulnerabilities to DoS and DDoS attacks as well as replay
and man-in-the middle attacks. Note that the Diameter base and man-in-the middle attacks. Note that the Diameter base
specification [RFC6733] lacks end to end security and this specification [RFC6733] lacks end to end security and this
must be considered. must be considered.
REQ 29: REMOVED REQ 28: The mechanism MUST NOT depend on being deployed in
REQ 30: The mechanism MUST NOT depend on being deployed in
environments where all Diameter nodes are completely environments where all Diameter nodes are completely
trusted. It SHOULD operate as effectively as possible in trusted. It SHOULD operate as effectively as possible in
environments where other nodes are malicious; this includes environments where other nodes are malicious; this includes
preventing malicious nodes from obtaining more than a fair preventing malicious nodes from obtaining more than a fair
share of service. Note that this does not imply any share of service. Note that this does not imply any
responsibility on the mechanism to detect, or take responsibility on the mechanism to detect, or take
countermeasures against, malicious nodes. countermeasures against, malicious nodes.
REQ 31: It MUST be possible for a supporting node to make REQ 29: It MUST be possible for a supporting node to make
authorization decisions about what information will be sent authorization decisions about what information will be sent
to peer nodes based on the identity of those nodes. This to peer nodes based on the identity of those nodes. This
allows a domain administrator who considers the load of allows a domain administrator who considers the load of
their nodes to be sensitive information to restrict access their nodes to be sensitive information to restrict access
to that information. Of course, in such cases, there is no to that information. Of course, in such cases, there is no
expectation that the overload control mechanism itself will expectation that the overload control mechanism itself will
help prevent overload from that peer node. help prevent overload from that peer node.
REQ 32: The mechanism MUST NOT interfere with any Diameter compliant REQ 30: The mechanism MUST NOT interfere with any Diameter compliant
method that a node may use to protect itself from overload method that a node may use to protect itself from overload
from non-supporting nodes, or from denial of service from non-supporting nodes, or from denial of service
attacks. attacks.
REQ 33: There are multiple situations where a Diameter node may be REQ 31: There are multiple situations where a Diameter node may be
overloaded for some purposes but not others. For example, overloaded for some purposes but not others. For example,
this can happen to an agent or server that supports multiple this can happen to an agent or server that supports multiple
applications, or when a server depends on multiple external applications, or when a server depends on multiple external
resources, some of which may become overloaded while others resources, some of which may become overloaded while others
are fully available. The mechanism MUST allow Diameter are fully available. The mechanism MUST allow Diameter
nodes to indicate overload with sufficient granularity to nodes to indicate overload with sufficient granularity to
allow clients to take action based on the overloaded allow clients to take action based on the overloaded
resources without unreasonably forcing available capacity to resources without unreasonably forcing available capacity to
go unused. The mechanism MUST support specification of go unused. The mechanism MUST support specification of
overload information with granularities of at least overload information with granularities of at least
"Diameter node", "realm", and "Diameter application", and "Diameter node", "realm", and "Diameter application", and
MUST allow extensibility for others to be added in the MUST allow extensibility for others to be added in the
future. future.
REQ 34: The mechanism MUST provide a method for extending the REQ 32: The mechanism MUST provide a method for extending the
information communicated and the algorithms used for information communicated and the algorithms used for
overload control. overload control.
REQ 35: The mechanism SHOULD provide a method for exchanging REQ 33: The mechanism MUST provide a default algorithm that is
mandatory to implement.
REQ 34: The mechanism SHOULD provide a method for exchanging
overload and load information between elements that are overload and load information between elements that are
connected by intermediaries that do not support the connected by intermediaries that do not support the
mechanism. mechanism.
REQ 36: The mechanism MUST provide a default algorithm that is
mandatory to implement.
8. IANA Considerations 8. IANA Considerations
This document makes no requests of IANA. This document makes no requests of IANA.
9. Security Considerations 9. Security Considerations
A Diameter overload control mechanism is primarily concerned with the A Diameter overload control mechanism is primarily concerned with the
load and overload related behavior of nodes in a Diameter network, load and overload related behavior of nodes in a Diameter network,
and the information used to affect that behavior. Load and overload and the information used to affect that behavior. Load and overload
 End of changes. 18 change blocks. 
23 lines changed or deleted 22 lines changed or added

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