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 |
GENART Last Call review
(of
-10)
by David Black
Ready w/nits
|
||
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]