Skip to main content

Diameter Overload Control Requirements
draft-ietf-dime-overload-reqs-09

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7068.
Authors Eric McMurry , Ben Campbell
Last updated 2013-07-23 (Latest revision 2013-07-15)
Replaces draft-mcmurry-dime-overload-reqs
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Jouni Korhonen
Shepherd write-up Show Last changed 2013-06-07
IESG IESG state Became RFC 7068 (Informational)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Benoît Claise
IESG note ** No value found for 'doc.notedoc.note' **
Send notices to dime-chairs@tools.ietf.org, draft-ietf-dime-overload-reqs@tools.ietf.org
draft-ietf-dime-overload-reqs-09
sessions.  Any normative or otherwise detailed definition of
            the relative priorities of message types during an overload
            condition will be the responsibility of the application
            specification.

   REQ 26:  The solution MUST NOT prevent a node from prioritizing
            requests based on any local policy, so that certain requests
            are given preferential treatment, given additional
            retransmission, not throttled, or processed ahead of others.

   REQ 27:  The solution MUST NOT provide new vulnerabilities to
            malicious attack, or increase the severity of any existing
            vulnerabilities.  This includes vulnerabilities to DoS and
            DDoS attacks as well as replay and man-in-the middle
            attacks.  Note that the Diameter base specification
            [RFC6733] lacks end to end security and this must be
            considered.

   REQ 28:  The solution MUST NOT depend on being deployed in
            environments where all Diameter nodes are completely
            trusted.  It SHOULD operate as effectively as possible in
            environments where other nodes are malicious; this includes
            preventing malicious nodes from obtaining more than a fair
            share of service.  Note that this does not imply any
            responsibility on the solution to detect, or take
            countermeasures against, malicious nodes.

   REQ 29:  It MUST be possible for a supporting node to make
            authorization decisions about what information will be sent
            to peer nodes based on the identity of those nodes.  This
            allows a domain administrator who considers the load of
            their nodes to be sensitive information to restrict access
            to that information.  Of course, in such cases, there is no
            expectation that the solution itself will help prevent
            overload from that peer node.

   REQ 30:  The solution MUST NOT interfere with any Diameter compliant
            method that a node may use to protect itself from overload
            from non-supporting nodes, or from denial of service
            attacks.

   REQ 31:  There are multiple situations where a Diameter node may be
            overloaded for some purposes but not others.  For example,
            this can happen to an agent or server that supports multiple
            applications, or when a server depends on multiple external
            resources, some of which may become overloaded while others
            are fully available.  The solution MUST allow Diameter nodes
            to indicate overload with sufficient granularity to allow

McMurry & Campbell      Expires January 16, 2014               [Page 22]
Internet-Draft   Diameter Overload Control Requirements        July 2013

            clients to take action based on the overloaded resources
            without unreasonably forcing available capacity to go
            unused.  The solution MUST support specification of overload
            information with granularities of at least "Diameter node",
            "realm", and "Diameter application", and MUST allow
            extensibility for others to be added in the future.

   REQ 32:  The solution MUST provide a method for extending the
            information communicated and the algorithms used for
            overload control.

   REQ 33:  The solution MUST provide a default algorithm that is
            mandatory to implement.

   REQ 34:  The solution SHOULD provide a method for exchanging overload
            and load information between elements that are connected by
            intermediaries that do not support the solution.

8.  IANA Considerations

   This document makes no requests of IANA.

9.  Security Considerations

   A Diameter overload control mechanism is primarily concerned with the
   load and overload related behavior of nodes in a Diameter network,
   and the information used to affect that behavior.  Load and overload
   information is shared between nodes and directly affects the behavior
   and thus is potentially vulnerable to a number of methods of attack.

   Load and overload information may also be sensitive from both
   business and network protection viewpoints.  Operators of Diameter
   equipment want to control visibility to load and overload information
   to keep it from being used for competitive intelligence or for
   targeting attacks.  It is also important that the Diameter overload
   control mechanism not introduce any way in which any other
   information carried by Diameter is sent inappropriately.

   Note that the Diameter base specification [RFC6733] lacks end to end
   security, making verifying the authenticity and ownership of load and
   overload information difficult for non-adjacent nodes.
   Authentication of load and overload information helps to alleviate
   several of the security issues listed in this section.

   This document includes requirements intended to mitigate the effects

McMurry & Campbell      Expires January 16, 2014               [Page 23]
Internet-Draft   Diameter Overload Control Requirements        July 2013

   of attacks and to protect the information used by the mechanism.
   This section discusses potential security considerations for overload
   control solutions.  This discussion provides the motivation for
   several normative requirements described in Section 7.  The
   discussion includes specific references to the normative requirements
   that apply for each issue.

9.1.  Access Control

   To control the visibility of load and overload information, sending
   should be subject to some form of authentication and authorization of
   the receiver.  It is also important to the receivers that they are
   confident the load and overload information they receive is from a
   legitimate source.  REQ 28 requires the solution to work without
   assuming that all Diameter nodes in a network are trusted for the
   purposes of exchanging overload and load information.  REQ 29
   requires the solution to let nodes restrict unauthorized parties from
   seeing overload information.  Note that this implies a certain amount
   of configurability on the nodes supporting the Diameter overload
   control mechanism.

9.2.  Denial-of-Service Attacks

   An overload control mechanism provides a very attractive target for
   denial-of-service attacks.  A small number of messages may affect a
   large service disruption by falsely reporting overload conditions.
   Alternately, attacking servers nearing, or in, overload may also be
   facilitated by disrupting their overload indications, potentially
   preventing them from mitigating their overload condition.

   A design goal for the Diameter overload control mechanism is to
   minimize or eliminate the possibility of using the mechanism for this
   type of attack.  More strongly, REQ 27 forbids the solution from
   introducing new vulnerabilities to malicious attack.  Additionally,
   REQ 30 stipulates that the solution not interfere with other
   mechanisms used for protection against denial of service attacks.

   As the intent of some denial-of-service attacks is to induce overload
   conditions, an effective overload control mechanism should help to
   mitigate the effects of an such an attack.

9.3.  Replay Attacks

   An attacker that has managed to obtain some messages from the
   overload control mechanism may attempt to affect the behavior of
   nodes supporting the mechanism by sending those messages at
   potentially inopportune times.  In addition to time shifting, replay
   attacks may send messages to other nodes as well (target shifting).

McMurry & Campbell      Expires January 16, 2014               [Page 24]
Internet-Draft   Diameter Overload Control Requirements        July 2013

   A design goal for the Diameter overload control solution is to
   minimize or eliminate the possibility of causing disruption by using
   a replay attack on the Diameter overload control mechanism.
   (Allowing a replay attack using the overload control solution would
   violate REQ 27.)

9.4.  Man-in-the-Middle Attacks

   By inserting themselves in between two nodes supporting the Diameter
   overload control mechanism, an attacker may potentially both access
   and alter the information sent between those nodes.  This can be used
   for information gathering for business intelligence and attack
   targeting, as well as direct attacks.

   REQs 27, 28, and 29 imply a need to prevent man-in-the-middle attacks
   on the overload control solution.  A transport using TLS and/or IPSEC
   may be desirable for this purpose.

9.5.  Compromised Hosts

   A compromised host that supports the Diameter overload control
   mechanism could be used for information gathering as well as for
   sending malicious information to any Diameter node that would
   normally accept information from it.  While is is beyond the scope of
   the Diameter overload control mechanism to mitigate any operational
   interruption to the compromised host, REQs 28 and 29 imply a need to
   minimize the impact that a compromised host can have on other nodes
   through the use of the Diameter overload control mechanism.  Of
   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
   mechanism.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", RFC 6733, October 2012.

   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
              RFC 2914, September 2000.

   [RFC3539]  Aboba, B. and J. Wood, "Authentication, Authorization and
              Accounting (AAA) Transport Profile", RFC 3539, June 2003.

McMurry & Campbell      Expires January 16, 2014               [Page 25]
Internet-Draft   Diameter Overload Control Requirements        July 2013

10.2.  Informative References

   [RFC5390]  Rosenberg, J., "Requirements for Management of Overload in
              the Session Initiation Protocol", RFC 5390, December 2008.

   [RFC6357]  Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design
              Considerations for Session Initiation Protocol (SIP)
              Overload Control", RFC 6357, August 2011.

   [TR23.843]
              3GPP, "Study on Core Network Overload Solutions",
              TR 23.843 0.6.0, October 2012.

   [IR.34]    GSMA, "Inter-Service Provider IP Backbone Guidelines",
              IR 34 7.0, January 2012.

   [IR.88]    GSMA, "LTE Roaming Guidelines", IR 88 7.0, January 2012.

   [IR.92]    GSMA, "IMS Profile for Voice and SMS", IR 92 7.0,
              March 2013.

   [TS23.002]
              3GPP, "Network Architecture", TS 23.002 12.0.0,
              September 2012.

   [TS29.272]
              3GPP, "Evolved Packet System (EPS); Mobility Management
              Entity (MME) and Serving GPRS Support Node (SGSN) related
              interfaces based on Diameter protocol", TS 29.272 11.4.0,
              September 2012.

   [TS29.212]
              3GPP, "Policy and Charging Control (PCC) over Gx/Sd
              reference point", TS 29.212 11.6.0, September 2012.

   [TS29.228]
              3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces;
              Signalling flows and message contents", TS 29.228 11.5.0,
              September 2012.

   [TS29.002]
              3GPP, "Mobile Application Part (MAP) specification",
              TS 29.002 11.4.0, September 2012.

Appendix A.  Contributors

   Significant contributions to this document were made by Adam Roach

McMurry & Campbell      Expires January 16, 2014               [Page 26]
Internet-Draft   Diameter Overload Control Requirements        July 2013

   and Eric Noel.

Appendix B.  Acknowledgements

   Review of, and contributions to, this specification by Martin Dolly,
   Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, Robert
   Sparks, Dieter Jacobsohn, Janet Gunn, Jean-Jacques Trottin, Laurent
   Thiebaut, Andrew Booth, and Lionel Morand were most appreciated.  We
   would like to thank them for their time and expertise.

Authors' Addresses

   Eric McMurry
   Tekelec
   17210 Campbell Rd.
   Suite 250
   Dallas, TX  75252
   US

   Email: emcmurry@computer.org

   Ben Campbell
   Tekelec
   17210 Campbell Rd.
   Suite 250
   Dallas, TX  75252
   US

   Email: ben@nostrum.com

McMurry & Campbell      Expires January 16, 2014               [Page 27]