draft-ietf-dime-overload-reqs-12.txt   draft-ietf-dime-overload-reqs-13.txt 
Network Working Group E. McMurry Network Working Group E. McMurry
Internet-Draft B. Campbell Internet-Draft B. Campbell
Intended status: Informational Tekelec Intended status: Informational Tekelec
Expires: March 14, 2014 September 10, 2013 Expires: April 3, 2014 September 30, 2013
Diameter Overload Control Requirements Diameter Overload Control Requirements
draft-ietf-dime-overload-reqs-12 draft-ietf-dime-overload-reqs-13
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 a progressively more severe overload
Diameter mechanisms are not sufficient for this purpose. This condition. The existing Diameter mechanisms are not sufficient for
document describes the limitations of the existing mechanisms. this purpose. This document describes the limitations of the
Requirements for new overload management mechanisms are also existing mechanisms. Requirements for new overload management
provided. mechanisms are also provided.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 14, 2014. This Internet-Draft will expire on April 3, 2014.
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 3, line 13 skipping to change at page 3, line 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
A Diameter [RFC6733] node is said to be overloaded when it has A Diameter [RFC6733] node is said to be overloaded when it has
insufficient resources to successfully process all of the Diameter insufficient resources to successfully process all of the Diameter
requests that it receives. When a node becomes overloaded, it needs requests that it receives. When a node becomes overloaded, it needs
to be able to gracefully reduce its load, typically by informing to be able to gracefully reduce its load, typically by informing
clients to reduce sending traffic for some period of time. 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 a
collapse. The existing mechanisms provided by Diameter are not progressively more severe overload condition. The existing
sufficient for this purpose. This document describes the limitations mechanisms provided by Diameter are not sufficient for this purpose.
of the existing mechanisms, and provides requirements for new This document describes the limitations of the existing mechanisms,
overload management mechanisms. and provides requirements for new overload management mechanisms.
This document draws on the work done on SIP overload control This document draws on the work done on SIP overload control
([RFC5390], [RFC6357]) as well as on experience gained via overload ([RFC5390], [RFC6357]) as well as on experience gained via overload
handling in Signaling System No. 7 (SS7) networks and studies done by handling in Signaling System No. 7 (SS7) networks and studies done by
the Third Generation Partnership Project (3GPP) (Section 3). the Third Generation Partnership Project (3GPP) (Section 3).
Diameter is not typically an end-user protocol; rather it is Diameter is not typically an end-user protocol; rather it is
generally used as one component in support of some end-user activity. generally used as one component in support of some end-user activity.
For example, a SIP server might use Diameter to authenticate and For example, a SIP server might use Diameter to authenticate and
skipping to change at page 4, line 18 skipping to change at page 4, line 18
has insufficient resources to successfully process all of the traffic has insufficient resources to successfully process all of the traffic
it is receiving. Resources include all of the capabilities of the it is receiving. Resources include all of the capabilities of the
element used to process a request, including CPU processing, memory, element used to process a request, including CPU processing, memory,
I/O, and disk resources. It can also include external resources such I/O, and disk resources. It can also include external resources such
as a database or DNS server, in which case the CPU, processing, as a database or DNS server, in which case the CPU, processing,
memory, I/O, and disk resources of those elements are effectively memory, I/O, and disk resources of those elements are effectively
part of the logical element processing the request. part of the logical element processing the request.
External resources can include upstream Diameter nodes; for example, External resources can include upstream Diameter nodes; for example,
a Diameter agent can become effectively overloaded if one or more a Diameter agent can become effectively overloaded if one or more
upstream nodes are overloaded. While overload is not the same thing upstream nodes are overloaded.
as network congestion, network congestion can reduce a Diameter nodes
ability to process and respond to requests, thus contributing to
overload.
A Diameter node can become overloaded due to request levels that A Diameter node can become overloaded due to request levels that
exceed its capacity, a reduction of available resources ( for exceed its capacity, a reduction of available resources ( for
example, a local or upstream hardware failure) or a combination of example, a local or upstream hardware failure) or a combination of
the two. the two.
Overload can occur for many reasons, including: Overload can occur for many reasons, including:
Inadequate capacity: When designing Diameter networks, that is, Inadequate capacity: When designing Diameter networks, that is,
application layer multi-node Diameter deployments, it can be very application layer multi-node Diameter deployments, it can be very
difficult to predict all scenarios that may cause elevated difficult to predict all scenarios that may cause elevated
traffic. It may also be more costly to implement support for some traffic. It may also be more costly to implement support for some
scenarios than a network operator may deem worthwhile. This scenarios than a network operator may deem worthwhile. This
results in the likelihood that a Diameter network will not have results in the likelihood that a Diameter network will not have
adequate capacity to handle all situations. adequate capacity to handle all situations.
Dependency failures: A Diameter node can become overloaded because a Dependency failures: A Diameter node can become overloaded because a
resource on which it is dependent has failed or become overloaded, resource on which it depends has failed or become overloaded,
greatly reducing the logical capacity of the node. In these greatly reducing the logical capacity of the node. In these
cases, even minimal traffic might cause the node to go into cases, even minimal traffic might cause the node to go into
overload. Examples of such dependency overloads include DNS overload. Examples of such dependency overloads include DNS
servers, databases, disks, and network interfaces. servers, databases, disks, and network interfaces.
Component failures: A Diameter node can become overloaded when it is Component failures: A Diameter node can become overloaded when it is
a member of a cluster of servers that each share the load of a member of a cluster of servers that each share the load of
traffic, and one or more of the other members in the cluster fail. traffic, and one or more of the other members in the cluster fail.
In this case, the remaining nodes take over the work of the failed In this case, the remaining nodes take over the work of the failed
nodes. Normally, capacity planning takes such failures into nodes. Normally, capacity planning takes such failures into
skipping to change at page 5, line 34 skipping to change at page 5, line 32
DoS attacks: An attacker, wishing to disrupt service in the network, DoS attacks: An attacker, wishing to disrupt service in the network,
can cause a large amount of traffic to be launched at a target can cause a large amount of traffic to be launched at a target
element. This can be done from a central source of traffic or element. This can be done from a central source of traffic or
through a distributed DoS attack. In all cases, the volume of through a distributed DoS attack. In all cases, the volume of
traffic well exceeds the capacity of the element, sending the traffic well exceeds the capacity of the element, sending the
system into overload. system into overload.
1.3. Effects of Overload 1.3. Effects of Overload
Modern Diameter networks, comprised of application layer multi-node Modern Diameter networks, composed of application layer multi-node
deployments of Diameter elements, may operate at very large deployments of Diameter elements, may operate at very large
transaction volumes. If a Diameter node becomes overloaded, or even transaction volumes. If a Diameter node becomes overloaded, or even
worse, fails completely, a large number of messages may be lost very worse, fails completely, a large number of messages may be lost very
quickly. Even with redundant servers, many messages can be lost in quickly. Even with redundant servers, many messages can be lost in
the time it takes for failover to complete. While a Diameter client the time it takes for failover to complete. While a Diameter client
or agent should be able to retry such requests, an overloaded peer or agent should be able to retry such requests, an overloaded peer
may cause a sudden large increase in the number of transaction may cause a sudden large increase in the number of transaction
transactions needing to be retried, rapidly filling local queues or transactions needing to be retried, rapidly filling local queues or
otherwise contributing to local overload. Therefore Diameter devices otherwise contributing to local overload. Therefore Diameter devices
need to be able to shed load before critical failures can occur. need to be able to shed load before critical failures can occur.
1.4. Overload vs. Network Congestion 1.4. Overload vs. Network Congestion
This document uses the term "overload" to refer to application-layer This document uses the term "overload" to refer to application-layer
overload at Diameter nodes. This is distinct from "network overload at Diameter nodes. This is distinct from "network
congestion", that is, congestion that occurs at the lower networking congestion", that is, congestion that occurs at the lower networking
layers that may impact the delivery of Diameter messages between layers that may impact the delivery of Diameter messages between
nodes. The authors recognize that element overload and network nodes. This document recognize that element overload and network
congestion are interrelated, and that overload can contribute to congestion are interrelated, and that overload can contribute to
network congestion and vice versa. network congestion and vice versa.
Network congestion issues are better handled by the transport Network congestion issues are better handled by the transport
protocols. Diameter uses TCP and SCTP, both of which include protocols. Diameter uses TCP and SCTP, both of which include
congestion management features. Analysis of whether those features congestion management features. Analysis of whether those features
are sufficient for transport level congestion between Diameter nodes, are sufficient for transport level congestion between Diameter nodes,
and any work to further mitigate network congestion is out of scope and any work to further mitigate network congestion is out of scope
both for this document, and for the work proposed by this document. both for this document, and for the work proposed by this document.
skipping to change at page 6, line 26 skipping to change at page 6, line 23
Most elements using Diameter applications do not use Diameter Most elements using Diameter applications do not use Diameter
exclusively. It is important to realize that overload of an element exclusively. It is important to realize that overload of an element
can be caused by a number of factors that may be unrelated to the can be caused by a number of factors that may be unrelated to the
processing of Diameter or Diameter applications. processing of Diameter or Diameter applications.
An element that doesn't use Diameter exclusively needs to be able to An element that doesn't use Diameter exclusively needs to be able to
signal to Diameter peers that it is experiencing overload regardless signal to Diameter peers that it is experiencing overload regardless
of the cause of the overload, since the overload will affect that of the cause of the overload, since the overload will affect that
element's ability to process Diameter transactions. If the element element's ability to process Diameter transactions. If the element
communicates with other protocols than Diameter, it may also need to communicates with protocols other than Diameter, it may also need to
signal the overload situation on these protocols depending on its signal the overload situation on these protocols depending on its
function and the architecture of the network and application it is function and the architecture of the network and application it is
providing services for. Whether that is necessary can only be providing services for. Whether that is necessary can only be
decided within the context of that architecture and use cases. A decided within the context of that architecture and use cases. A
mechanism for signaling overload with Diameter, which this mechanism for signaling overload with Diameter, which this
specification details the requirements for, provides Diameter nodes specification details the requirements for, provides Diameter nodes
the ability to signal their Diameter peers of overload, mitigating the ability to signal their Diameter peers of overload, mitigating
that part of the issue. Diameter nodes may need to use this, as well that part of the issue. Diameter nodes may need to use this, as well
as other mechanisms, to solve their broader overload issues. as other mechanisms, to solve their broader overload issues.
Indicating overload on protocols other than Diameter is out of scope Indicating overload on protocols other than Diameter is out of scope
for this document, and for the work proposed by this document. for this document, and for the work proposed by this document.
2. Overload Control Scenarios 2. Overload Control Scenarios
Several Diameter deployment scenarios exist that may impact overload Several Diameter deployment scenarios exist that may impact overload
management. The following scenarios help motivate the requirements management. The following scenarios help motivate the requirements
for an overload management mechanism. for an overload management mechanism.
These scenarios are by no means exhaustive, and are in general These scenarios are by no means exhaustive, and are in general
simplified for the sake of clarity. In particular, the authors simplified for the sake of clarity. In particular, this document
assume for the sake of clarity that the client sends Diameter assumes for the sake of clarity that the client sends Diameter
requests to the server, and the server sends responses to client, requests to the server, and the server sends responses to client,
even though Diameter supports bidirectional applications. Each even though Diameter supports bidirectional applications. Each
direction in such an application can be modeled separately. direction in such an application can be modeled separately.
In a large scale deployment, many of the nodes represented in these In a large scale deployment, many of the nodes represented in these
scenarios would be deployed as clusters of servers. The authors scenarios would be deployed as clusters of servers. This document
assume that such a cluster is responsible for managing its own assumes that such a cluster is responsible for managing its own
internal load balancing and overload management so that it appears as internal load balancing and overload management so that it appears as
a single Diameter node. That is, other Diameter nodes can treat it a single Diameter node. That is, other Diameter nodes can treat it
as single, monolithic node for the purposes of overload management. as single, monolithic node for the purposes of overload management.
These scenarios do not illustrate the client application. As These scenarios do not illustrate the client application. As
mentioned in Section 1, Diameter is not typically an end-user mentioned in Section 1, Diameter is not typically an end-user
protocol; rather it is generally used in support of some other client protocol; rather it is generally used in support of some other client
application. These scenarios do not consider the impact of Diameter application. These scenarios do not consider the impact of Diameter
overload on the client application. overload on the client application.
skipping to change at page 9, line 36 skipping to change at page 9, line 36
| | | |
+----------------+ +----------------+
Figure 3: Multiple Application Peer to Peer Scenario Figure 3: Multiple Application Peer to Peer Scenario
2.2. Agent Scenarios 2.2. Agent Scenarios
This section describes scenarios that include a Diameter agent, This section describes scenarios that include a Diameter agent,
either in the form of a Diameter relay or Diameter proxy. These either in the form of a Diameter relay or Diameter proxy. These
scenarios do not consider Diameter redirect agents, since they are scenarios do not consider Diameter redirect agents, since they are
more readily modeled as end-servers. more readily modeled as end-servers. The examples have been kept
simple deliberately, to illustrate basic concepts. Significantly
more complicated topologies are possible with Diameter, including
multiple intermediate agents in a path connected in a variety of
ways.
Figure 4 illustrates a simple Diameter agent scenario with a single Figure 4 illustrates a simple Diameter agent scenario with a single
client, agent, and server. In this case, overload can occur at the client, agent, and server. In this case, overload can occur at the
server, at the agent, or both. But in most cases, client behavior is server, at the agent, or both. But in most cases, client behavior is
the same whether overload occurs at the server or at the agent. From the same whether overload occurs at the server or at the agent. From
the client's perspective, server overload and agent overload is the the client's perspective, server overload and agent overload is the
same thing. same thing.
+------------------+ +------------------+
| | | |
skipping to change at page 14, line 5 skipping to change at page 14, line 5
3. Diameter Overload Case Studies 3. Diameter Overload Case Studies
3.1. Overload in Mobile Data Networks 3.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 mobile networks, enabled smartphone devices continue to expand in mobile 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) [TR23.843]. The root causes of and/or Home Subscriber Servers (HSS) [TR23.843]. The root causes of
the HLR congestion events were manifold but included hardware failure the HLR overload events were manifold but included hardware failure
and procedural errors. The result was high signaling traffic load on and procedural errors. The result was high signaling traffic load on
the HLR and HSS. the HLR and HSS.
The 3GPP architecture [TS23.002] makes extensive use of Diameter. It The 3GPP architecture [TS23.002] makes extensive use of Diameter. It
is used for mobility management [TS29.272] (and others), (IP is used for mobility management [TS29.272] (and others), (IP
Multimedia Subsystem) IMS [TS29.228] (and others), policy and Multimedia Subsystem) IMS [TS29.228] (and others), policy and
charging control [TS29.212] (and others) as well as other functions. charging control [TS29.212] (and others) as well as other functions.
The details of the architecture are out of scope for this document, The details of the architecture are out of scope for this document,
but it is worth noting that there are quite a few Diameter but it is worth noting that there are quite a few Diameter
applications, some with quite large amounts of Diameter signaling in applications, some with quite large amounts of Diameter signaling in
skipping to change at page 16, line 43 skipping to change at page 16, line 43
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.
5. 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 inadequacy may, in turn, contribute to broader overload. This inadequacy may, in turn, contribute to broader
congestion impacts due to unresponsive Diameter nodes causing impacts resulting from overload due to unresponsive Diameter nodes
application or transport layer retransmissions. In particular, they causing application or transport layer retransmissions. In
do not allow a Diameter agent or server to shed load as it approaches particular, they do not allow a Diameter agent or server to shed load
overload. At best, a node can only indicate that it needs to as it approaches overload. At best, a node can only indicate that it
entirely stop receiving requests, i.e. that it has effectively needs to entirely stop receiving requests, i.e. that it has
failed. Even that is problematic due to the inability to indicate effectively failed. Even that is problematic due to the inability to
durational validity on the transient errors available in the base indicate durational validity on the transient errors available in the
Diameter protocol. Diameter offers no mechanism to allow a node to base Diameter protocol. Diameter offers no mechanism to allow a node
indicate different overload states for different categories of to indicate different overload states for different categories of
messages, for example, if it is overloaded for one Diameter messages, for example, if it is overloaded for one Diameter
application but not another. application but not another.
5.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.
skipping to change at page 19, line 8 skipping to change at page 19, line 8
Diameter applications and expect reasonable results. Certain Diameter applications and expect reasonable results. Certain
Diameter applications might, however, benefit from application- Diameter applications might, however, benefit from application-
specific behavior over and above the mechanism's defaults. For specific behavior over and above the mechanism's defaults. For
example, an application specification might specify relative example, an application specification might specify relative
priorities of messages or selection of a specific overload control priorities of messages or selection of a specific overload control
algorithm. algorithm.
7. 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 addressing the issues
described in Section 5 and supporting the scenarios described in described in Section 5 and supporting the scenarios described in
Section 2. These requirements are stated primarily in terms of Section 2. These requirements are stated primarily in terms of
individual node behavior to inform the design of the improved individual node behavior to inform the design of the improved
mechanism; solution designers should keep in mind that the overall mechanism; solution designers should keep in mind that the overall
goal is improved overall system behavior across all the nodes goal is improved overall system behavior across all the nodes
involved, not just improved behavior from specific individual nodes. involved, not just improved behavior from specific individual nodes.
7.1. General 7.1. General
REQ 1: The solution MUST provide a communication method for Diameter REQ 1: The solution MUST provide a communication method for Diameter
skipping to change at page 21, line 13 skipping to change at page 21, line 13
underlying congestion control mechanisms. underlying congestion control mechanisms.
7.3. Heterogeneous Support for Solution 7.3. Heterogeneous Support for Solution
REQ 16: The solution is likely to be deployed incrementally. The REQ 16: The solution is likely to be deployed incrementally. The
solution MUST support a mixed environment where some, but solution MUST support a mixed environment where some, but
not all, nodes implement it. not all, nodes implement it.
REQ 17: In a mixed environment with nodes that support the solution REQ 17: In a mixed environment with nodes that support the solution
and that do not, the solution MUST NOT result in materially and that do not, the solution MUST NOT result in materially
less useful throughput as would have resulted if the less useful throughput during overload as would have
solution were not present. It SHOULD result in less severe resulted if the solution were not present. It SHOULD result
congestion in this environment. in less severe overload in this environment.
REQ 18: In a mixed environment of nodes that support the solution REQ 18: In a mixed environment of nodes that support the solution
and that do not, the solution MUST NOT preclude elements and that do not, the solution MUST NOT preclude elements
that support overload control from treating elements that do that support overload control from treating elements that do
not support overload control in a equitable fashion relative not support overload control in a equitable fashion relative
to those that do. Users and operators of nodes that do not to those that do. Users and operators of nodes that do not
support the solution MUST NOT unfairly benefit from the support the solution MUST NOT unfairly benefit from the
solution. The solution specification SHOULD provide solution. The solution specification SHOULD provide
guidance to implementors for dealing with elements not guidance to implementors for dealing with elements not
supporting overload control. supporting overload control.
skipping to change at page 21, line 37 skipping to change at page 21, line 37
REQ 19: It MUST be possible to use the solution between nodes in REQ 19: It MUST be possible to use the solution between nodes in
different realms and in different administrative domains. different realms and in different administrative domains.
REQ 20: Any explicit overload indication MUST be clearly REQ 20: Any explicit overload indication MUST be clearly
distinguishable from other errors reported via Diameter. distinguishable from other errors reported via Diameter.
REQ 21: In cases where a network node fails, is so overloaded that REQ 21: In cases where a network node fails, is so overloaded that
it cannot process messages, or cannot communicate due to a it cannot process messages, or cannot communicate due to a
network failure, it may not be able to provide explicit network failure, it may not be able to provide explicit
indications of the nature of the failure or its levels of indications of the nature of the failure or its levels of
congestion. The solution MUST result in at least as much overload. The solution MUST result in at least as much
useful throughput as would have resulted if the solution was useful throughput as would have resulted if the solution was
not in place. not in place.
7.4. Granular Control 7.4. Granular Control
REQ 22: The solution MUST provide a way for a node to throttle the REQ 22: The solution MUST provide a way for a node to throttle the
amount of traffic it receives from a peer node. This amount of traffic it receives from a 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.
skipping to change at page 22, line 43 skipping to change at page 22, line 43
retransmission, not throttled, or processed ahead of others. retransmission, not throttled, or processed ahead of others.
7.6. Security 7.6. Security
REQ 27: The solution MUST NOT provide new vulnerabilities to REQ 27: The solution MUST NOT provide new vulnerabilities to
malicious attack, or increase the severity of any existing malicious attack, or increase the severity of any existing
vulnerabilities. This includes vulnerabilities to DoS and vulnerabilities. This includes vulnerabilities to DoS and
DDoS attacks as well as replay and man-in-the middle DDoS attacks as well as replay and man-in-the middle
attacks. Note that the Diameter base specification attacks. Note that the Diameter base specification
[RFC6733] lacks end to end security and this must be [RFC6733] lacks end to end security and this must be
considered. Note that this requirement was expressed at a considered (see the Security Considerations (Section 9)).
high level so as to not preclude any particular solution. Note that this requirement was expressed at a high level so
Is is expected that the solution will address this in more as to not preclude any particular solution. Is is expected
detail. that the solution will address this in more detail.
REQ 28: The solution MUST NOT depend on being deployed in REQ 28: The solution 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 solution to detect, or take responsibility on the solution to detect, or take
countermeasures against, malicious nodes. countermeasures against, malicious nodes.
skipping to change at page 26, line 17 skipping to change at page 26, line 17
REQs 27, 28, and 29 imply a need to prevent man-in-the-middle 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 on the overload control solution. A transport using TLS and/or IPSEC
may be desirable for this purpose. may be desirable for this purpose.
9.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 it 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, REQs 28 and 29 imply a need to 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 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.
10. References 10. References
 End of changes. 20 change blocks. 
46 lines changed or deleted 47 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/