draft-ietf-dime-overload-reqs-00.txt   draft-ietf-dime-overload-reqs-01.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: March 25, 2013 September 21, 2012 Expires: May 16, 2013 November 12, 2012
Diameter Overload Control Requirements Diameter Overload Control Requirements
draft-ietf-dime-overload-reqs-00 draft-ietf-dime-overload-reqs-01
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
mechanisms provided by Diameter are not sufficient for this purpose. mechanisms provided by Diameter are not sufficient for this purpose.
This document describes the limitations of the existing mechanisms, This document describes the limitations of the existing mechanisms,
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 March 25, 2013. This Internet-Draft will expire on May 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Causes of Overload . . . . . . . . . . . . . . . . . . . . 3 1.1. Causes of Overload . . . . . . . . . . . . . . . . . . . . 3
1.2. Effects of Overload . . . . . . . . . . . . . . . . . . . 5 1.2. Effects of Overload . . . . . . . . . . . . . . . . . . . 5
1.3. Overload vs. Network Congestion . . . . . . . . . . . . . 5 1.3. Overload vs. Network Congestion . . . . . . . . . . . . . 5
1.4. Diameter Applications in a Broader Network . . . . . . . . 5 1.4. Diameter Applications in a Broader Network . . . . . . . . 5
1.5. Documentation Conventions . . . . . . . . . . . . . . . . 6 1.5. Documentation Conventions . . . . . . . . . . . . . . . . 6
2. Overload Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 2. Overload Scenarios . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Peer to Peer Scenarios . . . . . . . . . . . . . . . . . . 7 2.1. Peer to Peer Scenarios . . . . . . . . . . . . . . . . . . 7
2.2. Agent Scenarios . . . . . . . . . . . . . . . . . . . . . 9 2.2. Agent Scenarios . . . . . . . . . . . . . . . . . . . . . 9
2.3. Interconnect Scenario . . . . . . . . . . . . . . . . . . 12 2.3. Interconnect Scenario . . . . . . . . . . . . . . . . . . 12
3. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 13 3. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Issues with the Current Mechanisms . . . . . . . . . . . . . . 14 4. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 14
4.1. Problems with Implicit Mechanism . . . . . . . . . . . . . 15 5. Issues with the Current Mechanisms . . . . . . . . . . . . . . 14
4.2. Problems with Explicit Mechanisms . . . . . . . . . . . . 15 5.1. Problems with Implicit Mechanism . . . . . . . . . . . . . 15
5. Diameter Overload Case Studies . . . . . . . . . . . . . . . . 16 5.2. Problems with Explicit Mechanisms . . . . . . . . . . . . 15
5.1. Overload in Mobile Data Networks . . . . . . . . . . . . . 16 6. Diameter Overload Case Studies . . . . . . . . . . . . . . . . 16
5.2. 3GPP Study on Core Network Overload . . . . . . . . . . . 17 6.1. Overload in Mobile Data Networks . . . . . . . . . . . . . 16
6. Solution Requirements . . . . . . . . . . . . . . . . . . . . 17 6.2. 3GPP Study on Core Network Overload . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. Solution Requirements . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 23 9.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 23
8.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 23 9.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 23
8.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 24 9.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 23
8.5. Compromised Hosts . . . . . . . . . . . . . . . . . . . . 24 9.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.5. Compromised Hosts . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
When a Diameter [I-D.ietf-dime-rfc3588bis] server or agent becomes When a Diameter [I-D.ietf-dime-rfc3588bis] server or agent becomes
overloaded, it needs to be able to gracefully reduce its load, overloaded, it needs to be able to gracefully reduce its load,
typically by informing clients to reduce sending traffic for some typically by informing clients to reduce sending traffic for some
period of time. Otherwise, it must continue to expend resources period of time. Otherwise, it must continue to expend resources
skipping to change at page 10, line 42 skipping to change at page 10, line 42
agent may be able to transparently divert some or all Diameter agent may be able to transparently divert some or all Diameter
requests originally bound for server 1 to server 2. requests originally bound for server 1 to server 2.
In most cases, the client does not have detailed knowledge of the In most cases, the client does not have detailed knowledge of the
Diameter topology upstream of the agent. If the agent uses dynamic Diameter topology upstream of the agent. If the agent uses dynamic
discovery to find eligible servers, the set of eligible servers may discovery to find eligible servers, the set of eligible servers may
not be enumerable from the perspective of the client. Therefore, in not be enumerable from the perspective of the client. Therefore, in
most cases the agent needs to deal with any upstream overload issues most cases the agent needs to deal with any upstream overload issues
in a way that is transparent to the client. If one server notifies in a way that is transparent to the client. If one server notifies
the agent that it has become overloaded, the notification should not the agent that it has become overloaded, the notification should not
be passed back to the client in a way where the client could be passed back to the client in a way that the client could
mistakenly perceive the agent itself as being overloaded. If the set mistakenly perceive the agent itself as being overloaded. If the set
of all possible destinations upstream of the agent no longer has of all possible destinations upstream of the agent no longer has
sufficient capacity for incoming load, the agent itself becomes sufficient capacity for incoming load, the agent itself becomes
effectively overloaded. effectively overloaded.
On the other hand, there are cases where the client needs to be able On the other hand, there are cases where the client needs to be able
to select a particular server from behind an agent. For example, if to select a particular server from behind an agent. For example, if
a Diameter request is part of a multiple-round-trip authentication, a Diameter request is part of a multiple-round-trip authentication,
or is otherwise part of a Diameter "session", it may have a or is otherwise part of a Diameter "session", it may have a
DestinationHost AVP that requires the request to be served by server DestinationHost AVP that requires the request to be served by server
skipping to change at page 13, line 9 skipping to change at page 13, line 9
that of multiple network operators using Diameter components that of multiple network operators using Diameter components
connected through an interconnect service, e.g. using IPX. Figure 7 connected through an interconnect service, e.g. using IPX. Figure 7
shows two network operators with an interconnect network in-between. shows two network operators with an interconnect network in-between.
There could be any number of these networks between any two network There could be any number of these networks between any two network
operator's networks. operator's networks.
+-------------------------------------------+ +-------------------------------------------+
| Interconnect | | Interconnect |
| | | |
| +--------------+ +--------------+ | | +--------------+ +--------------+ |
| | Edge Agent 1 |------| Edge Agent 2 | | | | Server 3 |------| Server 4 | |
| +--------------+ +--------------+ | | +--------------+ +--------------+ |
| .' `. | | .' `. |
+------.-'--------------------------`.------+ +------.-'--------------------------`.------+
.' `. .' `.
.-' `. .-' `.
------------.'-----+ +----`.--------------- ------------.'-----+ +----`.---------------
+----------+ | | +----------+ +----------+ | | +----------+
| Server 1 | | | | Server 2 | | Server 1 | | | | Server 2 |
+----------+ | | +----------+ +----------+ | | +----------+
| | | |
Network Operator 1 | | Network Operator 2 Network Operator 1 | | Network Operator 2
-------------------+ +--------------------- -------------------+ +---------------------
Figure 7: Two Network Interconnect Scenario Figure 7: Two Network Interconnect Scenario
The characteristics of the information that an operator would want to The characteristics of the information that an operator would want to
share over such a connection are different than the information share over such a connection are different from the information
shared between components within a network operator's network. shared between components within a network operator's network.
Network operators may not want to convey topology or operational Network operators may not want to convey topology or operational
information, which limits how overload and loading information can be information, which limits how much overload and loading information
sent. For the interconnect scenario shown, Server 2 may want to can be sent. For the interconnect scenario shown, Server 2 may want
signal overload to Server 1, to affect traffic coming from Network to signal overload to Server 1, to affect traffic coming from Network
Operator 1. Operator 1.
This is different than internal to an network operator's network, This case is distinct from those internal to a network operator's
where there may be many more elements in a more complicated topology. network, where there may be many more elements in a more complicated
Also, the elements in the interconnect network may not support topology. Also, the elements in the interconnect network may not
diameter overload control, and the network operators may not want the support diameter overload control, and the network operators may not
interconnect to use overload or loading information intended to pass want the interconnect network to use overload or loading information.
through the interconnect even if the elements in the interconnect They may only want the information to pass through the interconnect
network do support diameter overload control. network without further processing or action by the interconnect
network even if the elements in the interconnect network do support
diameter overload control.
3. Existing Mechanisms 3. Extensibility
Given the variety of scenarios diameter elements can be deployed in,
and the variety of roles they can fulfill with diameter and other
technologies, a single algorithm for handling overload may not be
sufficient. This effort cannot anticipate all possible future
scenarios and roles. Extensibility, particularly of algorithms used
to deal with overload, will be important to cover these cases.
4. Existing Mechanisms
Diameter offers both implicit and explicit mechanisms for a Diameter Diameter offers both implicit and explicit mechanisms for a Diameter
node to learn that a peer is overloaded or unreachable. The implicit node to learn that a peer is overloaded or unreachable. The implicit
mechanism is simply the lack of responses to requests. If a client mechanism is simply the lack of responses to requests. If a client
fails to receive a response in a certain time period, it assumes the fails to receive a response in a certain time period, it assumes the
upstream peer is unavailable, or overloaded to the point of effective upstream peer is unavailable, or overloaded to the point of effective
unavailability. The watchdog mechanism [RFC3539] ensures that a unavailability. The watchdog mechanism [RFC3539] ensures that a
certain rate of transaction responses occur even when there is certain rate of transaction responses occur even when there is
otherwise little or no other Diameter traffic. otherwise little or no other Diameter traffic.
skipping to change at page 14, line 33 skipping to change at page 14, line 44
issues with transport (e.g. congestion propagation and window issues with transport (e.g. congestion propagation and window
management) are managed at that level. But even with a congestion- management) are managed at that level. But even with a congestion-
managed transport, a Diameter node can become overloaded at the managed transport, a Diameter node can become overloaded at the
Diameter protocol or application layers due to the causes described Diameter protocol or application layers due to the causes described
in Section 1.1 and congestion managed transports do not provide in Section 1.1 and congestion managed transports do not provide
facilities (and are at the wrong level) to handle server overload. facilities (and are at the wrong level) to handle server overload.
Transport level congestion management is also not sufficient to Transport level congestion management is also not sufficient to
address overload in cases of multi-hop and multi-destination address overload in cases of multi-hop and multi-destination
signaling. signaling.
4. Issues with the Current Mechanisms 5. Issues with the Current Mechanisms
The currently available Diameter mechanisms for indicating an The currently available Diameter mechanisms for indicating an
overload condition are not adequate to avoid service outages due to overload condition are not adequate to avoid service outages due to
overload. This may, in turn, contribute to broader congestion overload. This inadequacy may, in turn, contribute to broader
collapse due to unresponsive Diameter nodes causing application or congestion collapse due to unresponsive Diameter nodes causing
transport layer retransmissions. In particular, they do not allow a application or transport layer retransmissions. In particular, they
Diameter agent or server to shed load as it approaches overload. At do not allow a Diameter agent or server to shed load as it approaches
best, a node can only indicate that it needs to entirely stop overload. At best, a node can only indicate that it needs to
receiving requests, i.e. that it has effectively failed. Even that entirely stop receiving requests, i.e. that it has effectively
is problematic due to the inability to indicate durational validity failed. Even that is problematic due to the inability to indicate
on the transient errors available in the base Diameter protocol. durational validity on the transient errors available in the base
Diameter offers no mechanism to allow a node to indicate different Diameter protocol. Diameter offers no mechanism to allow a node to
overload states for different categories of messages, for example, if indicate different overload states for different categories of
it is overloaded for one Diameter application but not another. messages, for example, if it is overloaded for one Diameter
application but not another.
4.1. Problems with Implicit Mechanism 5.1. Problems with Implicit Mechanism
The implicit mechanism doesn't allow an agent or server to inform the The implicit mechanism doesn't allow an agent or server to inform the
client of a problem until it is effectively too late to do anything client of a problem until it is effectively too late to do anything
about it. The client does not know to take action until the upstream about it. The client does not know to take action until the upstream
node has effectively failed. A Diameter node has no opportunity to node has effectively failed. A Diameter node has no opportunity to
shed load early to avoid collapse in the first place. shed load early to avoid collapse in the first place.
Additionally, the implicit mechanism cannot distinguish between Additionally, the implicit mechanism cannot distinguish between
overload of a Diameter node and network congestion. Diameter treats overload of a Diameter node and network congestion. Diameter treats
the failure to receive an answer as a transport failure. the failure to receive an answer as a transport failure.
4.2. Problems with Explicit Mechanisms 5.2. Problems with Explicit Mechanisms
The Diameter specification is ambiguous on how a client should handle The Diameter specification is ambiguous on how a client should handle
receipt of a DIAMETER_TOO_BUSY response. The base specification receipt of a DIAMETER_TOO_BUSY response. The base specification
[I-D.ietf-dime-rfc3588bis] indicates that the sending client should [I-D.ietf-dime-rfc3588bis] indicates that the sending client should
attempt to send the request to a different peer. It makes no attempt to send the request to a different peer. It makes no
suggestion that a the receipt of a DIAMETER_TOO_BUSY response should suggestion that a the receipt of a DIAMETER_TOO_BUSY response should
affect future Diameter messages in any way. affect future Diameter messages in any way.
The Authentication, Authorization, and Accounting (AAA) Transport The Authentication, Authorization, and Accounting (AAA) Transport
Profile [RFC3539] recommends that a AAA node that receives a "Busy" Profile [RFC3539] recommends that a AAA node that receives a "Busy"
skipping to change at page 16, line 19 skipping to change at page 16, line 28
the downstream peer. (The Diameter specification is inconsistent the downstream peer. (The Diameter specification is inconsistent
about whether a protocol error MAY or SHOULD be handled by an agent, about whether a protocol error MAY or SHOULD be handled by an agent,
rather than forwarded downstream.) If a downstream peer receives the rather than forwarded downstream.) If a downstream peer receives the
DIAMETER_TOO_BUSY response, it may stop sending all requests to the DIAMETER_TOO_BUSY response, it may stop sending all requests to the
agent for some period of time, even though the agent may still be agent for some period of time, even though the agent may still be
able to deliver requests to other upstream peers. able to deliver requests to other upstream peers.
DIAMETER_UNABLE_TO_DELIVER also has no mechanisms for specifying the DIAMETER_UNABLE_TO_DELIVER also has no mechanisms for specifying the
scope or cause of the failure, or the durational validity. scope or cause of the failure, or the durational validity.
5. Diameter Overload Case Studies 6. Diameter Overload Case Studies
5.1. Overload in Mobile Data Networks 6.1. Overload in Mobile Data Networks
As the number of Third Generation (3G) and Long Term Evolution (LTE) As the number of Third Generation (3G) and Long Term Evolution (LTE)
enabled smartphone devices continue to expand in mobility networks, enabled smartphone devices continue to expand in mobility networks,
there have been situations where high signaling traffic load led to there have been situations where high signaling traffic load led to
overload events at the Diameter-based Home Location Registries (HLR) overload events at the Diameter-based Home Location Registries (HLR)
and/or Home Subscriber Servers (HSS). The root causes of the HLR and/or Home Subscriber Servers (HSS). The root causes of the HLR
congestion events were manifold but included hardware failure and congestion events were manifold but included hardware failure and
procedural errors. The result was high signaling traffic load on the procedural errors. The result was high signaling traffic load on the
HLR and HSS. HLR and HSS.
The 3GPP standards specification[need citation] for the end-to-end The 3GPP standards specification[need citation] for the end-to-end
signaling call flows in 3G and LTE, from the end user device signaling call flows in 3G and LTE, from the end user device
traversing through the radio and the core networks to the HLR/HSS, traversing through the radio and the core networks to the HLR/HSS,
did not have an equivalent load control mechanism which is provided did not have an equivalent load control mechanism to those provided
in the more traditional SS7 elements in GSM [need citation]. The in the more traditional SS7 elements in GSM [need citation]. The
capabilities specified in the 3GPP standards do not adequately capabilities specified in the 3GPP standards do not adequately
address the abnormal condition where excessively high signaling address the abnormal condition where excessively high signaling
traffic load situations are experienced. traffic load situations are experienced.
Smartphones contribute much more heavily to the continuation of a Smartphones contribute much more heavily, relative to non-
registration surge due to their very aggressive registration smartphones, to the continuation of a registration surge due to their
algorithms. The aggressive smartphone logic is designed to: very aggressive registration algorithms. The aggressive smartphone
logic is designed to:
a. always have voice and data registration, and a. always have voice and data registration, and
b. constantly try to be on 3G or LTE data (and thus on 3G voice or b. constantly try to be on 3G or LTE data (and thus on 3G voice or
VoLTE) for their added benefits. VoLTE) for their added benefits.
Non-smartphones typically have logic to wait for a time period after Non-smartphones typically have logic to wait for a time period after
registering successfully on voice and data. registering successfully on voice and data.
The smartphone aggressive registration is problematic in two ways: The smartphone aggressive registration is problematic in two ways:
o first by generating excessive signaling load towards the HLR that o first by generating excessive signaling load towards the HLR that
is ten times that from a non-smartphone, is ten times that from a non-smartphone,
o and second by causing continual registration attempts when a o and second by causing continual registration attempts when a
network failure affects registrations through the 3G data network. network failure affects registrations through the 3G data network.
5.2. 3GPP Study on Core Network Overload 6.2. 3GPP Study on Core Network Overload
A study in 3GPP SA2 on core network overload has produced the A study in 3GPP SA2 on core network overload has produced the
technical report [TR23.843]. This enumerates several causes of technical report [TR23.843]. This enumerates several causes of
overload in mobile core networks including portions that are signaled overload in mobile core networks including portions that are signaled
using Diameter. This document is a work in progress and is not using Diameter. This document is a work in progress and is not
complete. However, it is useful for pointing out scenarios and the complete. However, it is useful for pointing out scenarios and the
general need for an overload control mechanism for Diameter. general need for an overload control mechanism for Diameter.
It is common for mobile networks to employ more than one radio It is common for mobile networks to employ more than one radio
technology and to do so in an overlay fashion with multiple technology and to do so in an overlay fashion with multiple
skipping to change at page 17, line 35 skipping to change at page 17, line 45
along with LTE). This presents opportunities for traffic storms when along with LTE). This presents opportunities for traffic storms when
issues occur on one overlay and not another as all devices that had issues occur on one overlay and not another as all devices that had
been on the overlay with issues switch. This causes a large amount been on the overlay with issues switch. This causes a large amount
of Diameter traffic as locations and policies are updated. of Diameter traffic as locations and policies are updated.
Another scenario called out by this study is a flood of registration Another scenario called out by this study is a flood of registration
and mobility management events caused by some element in the core and mobility management events caused by some element in the core
network failing. This flood of traffic from end nodes falls under network failing. This flood of traffic from end nodes falls under
the network initiated traffic flood category. There is likely to the network initiated traffic flood category. There is likely to
also be traffic resulting directly from the component failure in this also be traffic resulting directly from the component failure in this
case. case. A similar flood can occur when elements or components recover
as well.
Subscriber initiated traffic floods are also indicated in this study Subscriber initiated traffic floods are also indicated in this study
as an overload mechanism where a large number of mobile devices as an overload mechanism where a large number of mobile devices
attempting to access services at the same time, such as in response attempting to access services at the same time, such as in response
to an entertainment event or a catastrophic event. to an entertainment event or a catastrophic event.
While this study is concerned with the broader effects of these While this 3GPP study is concerned with the broader effects of these
scenarios on wireless networks and their elements, they have scenarios on wireless networks and their elements, they have
implications specifically for Diameter signaling. One of the goals implications specifically for Diameter signaling. One of the goals
of this document is to provide guidance for a core mechanism that can of this document is to provide guidance for a core mechanism that can
be used to mitigate the scenarios called out by this study. be used to mitigate the scenarios called out by this study.
6. Solution Requirements 7. Solution Requirements
This section proposes requirements for an improved mechanism to This section proposes requirements for an improved mechanism to
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 5 and supporting the scenarios described in
Section 2 Section 2
REQ 1: The overload mechanism MUST provide a communication method REQ 1: The overload mechanism MUST provide a communication method
for Diameter nodes to exchange overload information. for Diameter nodes to exchange overload information.
REQ 2: The overload mechanism MUST be useable with any existing or REQ 2: The overload mechanism MUST be useable with any existing or
future Diameter application. It MUST NOT require future Diameter application. It MUST NOT require
specification changes for existing Diameter applications. specification changes for existing Diameter applications.
REQ 3: The overload mechanism MUST limit the impact of overload on REQ 3: The overload mechanism MUST limit the impact of overload on
skipping to change at page 18, line 41 skipping to change at page 19, line 9
REQ 6: The mechanism designers SHOULD seek to minimize the amount REQ 6: The mechanism designers SHOULD seek to minimize the amount
of new configuration required in order to work. For of new configuration required in order to work. For
example, it is better to allow peers to advertise or example, it is better to allow peers to advertise or
negotiate support for the mechanism, rather than to require negotiate support for the mechanism, rather than to require
this knowledge to be configured at each node. this knowledge to be configured at each node.
REQ 7: The overload mechanism MUST ensure that the system remains REQ 7: The overload mechanism MUST ensure that the system remains
stable. When the offered load drops from above the overall stable. When the offered load drops from above the overall
capacity of the network to below the overall capacity, the capacity of the network to below the overall capacity, the
throughput MUST stabilize and become equal to the offered throughput MUST stabilize and become equal to the offered
load. load. Note that this also requires that the mechanism MUST
allow nodes to shed load without introducing oscillations.
REQ 8: The mechanism MUST allow nodes to shed load without REQ 8: Supporting nodes MUST be able to distinguish current
introducing oscillations. Note that this requirement overload information from stale information, and SHOULD make
implies a need for supporting nodes to be able to decisions using the most currently available information.
distinguish current overload information from stale
information, and to make decisions using the most currently
available information.
REQ 9: The mechanism MUST function across fully loaded as well as REQ 9: The mechanism MUST function across fully loaded as well as
quiescent transport connections. This is partially derived quiescent transport connections. This is partially derived
from the requirements for stability and hysteresis control from the requirements for stability and hysteresis control
above. above.
REQ 10: Consumers of overload state indications MUST be able to REQ 10: Consumers of overload state indications MUST be able to
determine when the overload condition improves or ends. determine when the overload condition improves or ends.
REQ 11: The overload mechanism MUST be scalable. That is, it MUST REQ 11: The overload mechanism MUST be scalable. That is, it MUST
skipping to change at page 19, line 34 skipping to change at page 19, line 45
for an overloaded node to send overload information every for an overloaded node to send overload information every
time it received a new request would introduce substantial time it received a new request would introduce substantial
work. Existing messaging is likely to have the work. Existing messaging is likely to have the
characteristic of increasing as an overload condition characteristic of increasing as an overload condition
approaches, allowing for the possibility of increased approaches, allowing for the possibility of increased
feedback for information piggybacked on it. feedback for information piggybacked on it.
REQ 14: Some scenarios that result in overload involve a rapid REQ 14: Some scenarios that result in overload involve a rapid
increase of traffic with little time between normal levels increase of traffic with little time between normal levels
and overload inducing levels. The mechanism SHOULD provide and overload inducing levels. The mechanism SHOULD provide
for increased feedback when traffic levels increase. The for rapid feedback when traffic levels increase.
mechanism MUST NOT do this in such a way that it increases
the number of messages while at high loads.
REQ 15: The mechanism MUST NOT interfere with the congestion control REQ 15: The mechanism MUST NOT interfere with the congestion control
mechanisms of underlying transport protocols. For example, mechanisms of underlying transport protocols. For example,
a mechanism that opened additional TCP connections when the a mechanism that opened additional TCP connections when the
network is congested would reduce the effectiveness of the network is congested would reduce the effectiveness of the
underlying congestion control mechanisms. underlying congestion control mechanisms.
REQ 16: The mechanism MUST operate without malfunction in an REQ 16: The mechanism MUST operate without malfunction in an
environment with a mix of nodes that do, and nodes that do environment with a mix of nodes that do, and nodes that do
not, support the mechanism. not, support the mechanism.
REQ 17: In a mixed environment with nodes that support the overload REQ 17: In a mixed environment with nodes that support the overload
control mechanism and that do not, the mechanism MUST NOT control mechanism and that do not, the mechanism MUST result
result in less useful throughput than would have resulted if in at least as much useful throughput as would have resulted
it were not present. It SHOULD result in less severe if the mechanism were not present. It SHOULD result in less
congestion in this environment. severe congestion in this environment.
REQ 18: In a mixed environment of nodes that support the overload REQ 18: In a mixed environment of nodes that support the overload
control mechanism and that do not, users and operators of control mechanism and that do not, users and operators of
nodes that do not support the mechanism MUST NOT benefit nodes that do not support the mechanism MUST NOT benefit
from the mechanism more than users and operators of nodes from the mechanism more than users and operators of nodes
that support the mechanism. that support the mechanism.
REQ 19: It MUST be possible to use the mechanism between nodes in REQ 19: It MUST be possible to use the mechanism between nodes in
different realms and in different administrative domains. different realms and in different administrative domains.
skipping to change at page 21, line 15 skipping to change at page 21, line 26
REQ 26: The specification for the overload mechanism SHOULD offer REQ 26: The specification for the overload mechanism SHOULD offer
guidance on which message types might be desirable to send guidance on which message types might be desirable to send
or process over others during times of overload, based on or process over others during times of overload, based on
Diameter-specific considerations. For example, it may be Diameter-specific considerations. For example, it may be
more beneficial to process messages for existing sessions more beneficial to process messages for existing sessions
ahead of new sessions. ahead of new sessions.
REQ 27: The mechanism MUST NOT prevent a node from prioritizing REQ 27: 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, or processed ahead of others. retransmission, not throttled, or processed ahead of others.
REQ 28: The overload mechanism MUST NOT provide new vulnerabilities REQ 28: The overload mechanism MUST NOT provide new vulnerabilities
to malicious attack, or increase the severity of any to malicious attack, or increase the severity of any
existing vulnerabilities. This includes vulnerabilities to existing vulnerabilities. This includes vulnerabilities to
DoS and DDoS attacks as well as replay and man-in-the middle DoS and DDoS attacks as well as replay and man-in-the middle
attacks. attacks.
REQ 29: The mechanism MUST provide a means to match an overload REQ 29: The mechanism MUST provide a means to match an overload
indication with the node that originated it. In particular, indication with the node that originated it. In particular,
the mechanism MUST allow a node to distinguish between the mechanism MUST allow a node to distinguish between
skipping to change at page 22, line 35 skipping to change at page 22, line 44
REQ 34: The mechanism MUST provide a method for extending the REQ 34: 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 35: 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. A separate mechanism or extension of the mechanism. A separate mechanism or extension of the
mechanism to support this may be warranted for this. mechanism to support this may be warranted for this.
7. IANA Considerations 8. IANA Considerations
This document makes no requests of IANA. This document makes no requests of IANA.
8. 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
information is shared between nodes and directly affects the behavior information is shared between nodes and directly affects the behavior
and thus is potentially vulnerable to a number of methods of attack. and thus is potentially vulnerable to a number of methods of attack.
Load and overload information may also be sensitive from both Load and overload information may also be sensitive from both
business and network protection viewpoints. Operators of Diameter business and network protection viewpoints. Operators of Diameter
equipment want to control visibility to load and overload information equipment want to control visibility to load and overload information
to keep it from being used for competitive intelligence or for to keep it from being used for competitive intelligence or for
targeting attacks. It is also important that the Diameter overload targeting attacks. It is also important that the Diameter overload
control mechanism not introduce any way in which any other control mechanism not introduce any way in which any other
information carried by Diameter is sent inappropriately. information carried by Diameter is sent inappropriately.
This document includes requirements intended to mitigate the effects This document includes requirements intended to mitigate the effects
of attacks and to protect the information used by the mechanism. of attacks and to protect the information used by the mechanism.
8.1. Access Control 9.1. Access Control
To control the visibility of load and overload information, sending To control the visibility of load and overload information, sending
should be subject to some form of authentication and authorization of should be subject to some form of authentication and authorization of
the receiver. It is also important to the receivers that they are the receiver. It is also important to the receivers that they are
confident the load and overload information they receive is from a confident the load and overload information they receive is from a
legitimate source. Note that this implies a certain amount of legitimate source. Note that this implies a certain amount of
configurability on the nodes supporting the Diameter overload control configurability on the nodes supporting the Diameter overload control
mechanism. mechanism.
8.2. Denial-of-Service Attacks 9.2. Denial-of-Service Attacks
An overload control mechanism provides a very attractive target for An overload control mechanism provides a very attractive target for
denial-of-service attacks. A small number of messages may affect a denial-of-service attacks. A small number of messages may affect a
large service disruption by falsely reporting overload conditions. large service disruption by falsely reporting overload conditions.
Alternately, attacking servers nearing, or in, overload may also be Alternately, attacking servers nearing, or in, overload may also be
facilitated by disrupting their overload indications, potentially facilitated by disrupting their overload indications, potentially
preventing them from mitigating their overload condition. preventing them from mitigating their overload condition.
A design goal for the Diameter overload control mechanism is to A design goal for the Diameter overload control mechanism is to
minimize or eliminate the possibility of using the mechanism for this minimize or eliminate the possibility of using the mechanism for this
type of attack. type of attack.
As the intent of some denial-of-service attacks is to induce overload As the intent of some denial-of-service attacks is to induce overload
conditions, an effective overload control mechanism should help to conditions, an effective overload control mechanism should help to
mitigate the effects of an such an attack. mitigate the effects of an such an attack.
8.3. Replay Attacks 9.3. Replay Attacks
An attacker that has managed to obtain some messages from the An attacker that has managed to obtain some messages from the
overload control mechanism may attempt to affect the behavior of overload control mechanism may attempt to affect the behavior of
nodes supporting the mechanism by sending those messages at nodes supporting the mechanism by sending those messages at
potentially inopportune times. In addition to time shifting, replay potentially inopportune times. In addition to time shifting, replay
attacks may send messages to other nodes as well (target shifting). attacks may send messages to other nodes as well (target shifting).
A design goal for the Diameter overload control mechanism is to A design goal for the Diameter overload control mechanism is to
minimize or eliminate the possibility of causing disruption by using minimize or eliminate the possibility of causing disruption by using
a replay attack on the Diameter overload control mechanism. a replay attack on the Diameter overload control mechanism.
8.4. Man-in-the-Middle Attacks 9.4. Man-in-the-Middle Attacks
By inserting themselves in between two nodes supporting the Diameter By inserting themselves in between two nodes supporting the Diameter
overload control mechanism, an attacker may potentially both access overload control mechanism, an attacker may potentially both access
and alter the information sent between those nodes. This can be used and alter the information sent between those nodes. This can be used
for information gathering for business intelligence and attack for information gathering for business intelligence and attack
targeting, as well as direct attacks. targeting, as well as direct attacks.
A design goal for the Diameter overload control mechanism is to A design goal for the Diameter overload control mechanism is to
minimize or eliminate the possibility of causing disruption man-in- minimize or eliminate the possibility of causing disruption man-in-
the-middle attacks on the Diameter overload control mechanism. A the-middle attacks on the Diameter overload control mechanism. A
transport using TLS and/or IPSEC may be desirable for this. transport using TLS and/or IPSEC may be desirable for this.
8.5. Compromised Hosts 9.5. Compromised Hosts
A compromised host that supports the Diameter overload control A compromised host that supports the Diameter overload control
mechanism could be used for information gathering as well as for mechanism could be used for information gathering as well as for
sending malicious information to any Diameter node that would sending malicious information to any Diameter node that would
normally accept information from it. While is is beyond the scope of normally accept information from it. While is is beyond the scope of
the Diameter overload control mechanism to mitigate any operational the Diameter overload control mechanism to mitigate any operational
interruption to the compromised host, a reasonable design goal is to interruption to the compromised host, a reasonable design goal is to
minimize the impact that a compromised host can have on other nodes minimize the impact that a compromised host can have on other nodes
through the use of the Diameter overload control mechanism. Of through the use of the Diameter overload control mechanism. Of
course, a compromised host could be used to cause damage in a number course, a compromised host could be used to cause damage in a number
of other ways. This is out of scope for a Diameter overload control of other ways. This is out of scope for a Diameter overload control
mechanism. mechanism.
9. References 10. References
9.1. Normative References 10.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-dime-rfc3588bis] [I-D.ietf-dime-rfc3588bis]
Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34
(work in progress), June 2012. (work in progress), June 2012.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000. RFC 2914, September 2000.
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539, June 2003. Accounting (AAA) Transport Profile", RFC 3539, June 2003.
9.2. Informative References 10.2. Informative References
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in [RFC5390] Rosenberg, J., "Requirements for Management of Overload in
the Session Initiation Protocol", RFC 5390, December 2008. the Session Initiation Protocol", RFC 5390, December 2008.
[TR23.843] [TR23.843]
3GPP, "Study on Core Network Overload Solutions", 3GPP, "Study on Core Network Overload Solutions",
TR 23.843 0.4.0, April 2011. TR 23.843 0.6.0, October 2012.
Appendix A. Contributors Appendix A. Contributors
Significant contributions to this document were made by Adam Roach Significant contributions to this document were made by Adam Roach
and Eric Noel. and Eric Noel.
Appendix B. Acknowledgements Appendix B. Acknowledgements
Review of, and contributions to, this specification by Martin Dolly, Review of, and contributions to, this specification by Martin Dolly,
Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, and Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, Robert
Robert Sparks were most appreciated. We would like to thank them for Sparks, Dieter Jacobsohn, and Janet Gunn were most appreciated. We
their time and expertise. would like to thank them for their time and expertise.
Authors' Addresses Authors' Addresses
Eric McMurry Eric McMurry
Tekelec Tekelec
17210 Campbell Rd. 17210 Campbell Rd.
Suite 250 Suite 250
Dallas, TX 75252 Dallas, TX 75252
US US
 End of changes. 40 change blocks. 
89 lines changed or deleted 100 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/