Section 5.1. The loss algorithm described in this section is the default algorithm that must be supported by all Diameter nodes that support DOIC. The loss algorithm is designed to be a straightforward and stateless overload abatement algorithm. It is used by reporting nodes to request a percentage reduction in the amount of traffic sent. The traffic impacted by the requested reduction depends on the type of overload report. Reporting nodes request the stateless reduction of the number of requests by an indicated percentage. This percentage reduction is in comparison to the number of messages the node otherwise would send, regardless of how many requests the node might have sent in the past. From a conceptual level, the logic at the reacting node could be outlined as follows. 1. An overload report is received, and the associated OCS is either saved or updated (if required) by the reacting node. 2. A new Diameter request is generated by the application running on the reacting node. 3. The reacting node determines that an active overload report applies to the request, as indicated by the corresponding OCS entry. 4. The reacting node determines if overload abatement treatment should be applied to the request. One approach that could be taken for each request is to select a uniformly selected random number between 1 and 100. If the random number is less than or
equal to the indicated reduction percentage, then the request is given abatement treatment; otherwise, the request is given normal routing treatment. Section 5.2.3. When sending the OC-OLR AVP, the reporting node MUST indicate a percentage reduction in the OC-Reduction-Percentage AVP. The reporting node MAY change the reduction percentage in subsequent overload reports. When doing so, the reporting node must conform to overload report handling specified in Section 5.2.3.
Note: The goal of this behavior is to reduce the probability of overload condition thrashing where an immediate transition from 100% reduction to 0% reduction results in the reporting node moving quickly back into an overload condition. Section 4 of [RFC6733] for more information on AVPs and AVP data types.
The following capability is defined in this document: OLR_DEFAULT_ALGO (0x0000000000000001) When this flag is set by the a DOIC reacting node, it means that the default traffic abatement (loss) algorithm is supported. When this flag is set by a DOIC reporting node, it means that the loss algorithm will be used for requested overload abatement. Section 5.2. From the functionality point of view, the OC-Sequence-Number AVP is used as a nonvolatile increasing counter for a sequence of overload reports between two DOIC nodes for the same overload occurrence. Sequence numbers are treated in a unidirectional manner, i.e., two sequence numbers in each direction between two DOIC nodes are not related or correlated.
86,400 seconds (24 hours). If the value received in the OC-Validity- Duration is greater than the maximum value, then the default value applies.
7.1 Grouped | | V | +--------------------------------------------------+----+----+ |OC-Feature-Vector 622 7.2 Unsigned64 | | V | +--------------------------------------------------+----+----+ |OC-OLR 623 7.3 Grouped | | V | +--------------------------------------------------+----+----+ |OC-Sequence-Number 624 7.4 Unsigned64 | | V | +--------------------------------------------------+----+----+ |OC-Validity-Duration 625 7.5 Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Report-Type 626 7.6 Enumerated | | V | +--------------------------------------------------+----+----+ |OC-Reduction | | | | -Percentage 627 7.7 Unsigned32 | | V | +--------------------------------------------------+----+----+ As described in the Diameter base protocol [RFC6733], the M-bit usage for a given AVP in a given command may be defined by the application.
For instance, if the request arrived at the reporting node without a Destination-Host AVP, then the reporting node might determine that there is an alternative Diameter node that could successfully process the request and that retrying the transaction would not negatively impact the reporting node. DIAMETER_TOO_BUSY would be sent in this case. If the request arrived at the reporting node with a Destination- Host AVP populated with its own Diameter identity, then the reporting node can assume that retrying the request would result in it coming to the same reporting node. DIAMETER_UNABLE_TO_COMPLY would be sent in this case. A second example is when an agent that supports the DOIC solution is performing the role of a reacting node for a non-supporting client. Requests that are rejected as a result of DOIC throttling by the agent in this scenario would generally be rejected with a DIAMETER_UNABLE_TO_COMPLY response code. Section 7. All AVP codes are allocated from the "AVP Codes" sub-registry under the "Authentication, Authorization, and Accounting (AAA) Parameters" registry. Section 7.2 for the initial Feature Vector Value in the registry. This specification defines the value. New values can be added to the registry using the Specification Required policy [RFC5226].
A new "OC-Report-Type AVP Values (code 626)" registry has been created. This registry contains the following: Report Type Value Name Report Type Value Specification defining the new value See Section 7.6 for the initial assignment in the registry. New types can be added using the Specification Required policy [RFC5226].
When agents are involved, this presents an effectively transitive trust model. That is, a Diameter client or server can authorize an agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on. Since confidentiality and integrity protection occur at the transport layer, agents can read, and perhaps modify, any part of a Diameter message, including an overload report. There are several ways an attacker might attempt to exploit the overload control mechanism. An unauthorized third party might inject an overload report into the network. If this third party is upstream of an agent, and that agent fails to apply proper authorization policies, downstream nodes may mistakenly trust the report. This attack is at least partially mitigated by the assumption that nodes include overload reports in Diameter answers but not in requests. This requires an attacker to have knowledge of the original request in order to construct an answer. Such an answer would also need to arrive at a Diameter node via a protected transport connection. Therefore, implementations MUST validate that an answer containing an overload report is a properly constructed response to a pending request prior to acting on the overload report, and that the answer was received via an appropriate transport connection. A similar attack involves a compromised but otherwise authorized node that sends an inappropriate overload report. For example, a server for the realm "example.com" might send an overload report indicating that a competitor's realm "example.net" is overloaded. If other nodes act on the report, they may falsely believe that "example.net" is overloaded, effectively reducing that realm's capacity. Therefore, it's critical that nodes validate that an overload report received from a peer actually falls within that peer's responsibility before acting on the report or forwarding the report to other peers. For example, an overload report from a peer that applies to a realm not handled by that peer is suspect. This may require out-of-band, non-Diameter agreements and/or mechanisms. This attack is partially mitigated by the fact that the application, as well as host and realm, for a given OLR is determined implicitly by respective AVPs in the enclosing answer. If a reporting node modifies any of those AVPs, the enclosing transaction will also be affected.
protocols, a DoS attack on Diameter is likely to impact those protocols as well. In the worst case, where the Diameter application is being used for access control into an IP network, a coordinated DoS attack could result in the blockage of all traffic into that network. Therefore, Diameter nodes MUST NOT honor or forward OLRs received from peers that are not trusted to send them. An attacker might use the information in an OLR to assist in DoS attacks. For example, an attacker could use information about current overload conditions to time an attack for maximum effect, or use subsequent overload reports as a feedback mechanism to learn the results of a previous or ongoing attack. Operators need the ability to ensure that OLRs are not leaked to untrusted parties. RFC7068] indicates that the overload control solution cannot assume that all Diameter nodes in a network are trusted. It also requires that malicious nodes not be allowed to take advantage of the overload control mechanism to get more than their fair share of service.
overload control MUST give operators the ability to select which peers are trusted to deliver overload reports and whether they are trusted to forward overload reports from non-adjacent nodes. DOIC nodes MUST strip DOIC AVPs from messages received from peers that are not trusted for DOIC purposes. The lack of end-to-end confidentiality protection means that any Diameter Agent in the path of an overload report can view the contents of that report. In addition to the requirement to select which peers are trusted to send overload reports, operators MUST be able to select which peers are authorized to receive reports. A node MUST NOT send an overload report to a peer not authorized to receive it. Furthermore, an agent MUST remove any overload reports that might have been inserted by other nodes before forwarding a Diameter message to a peer that is not authorized to receive overload reports. A DOIC node cannot always automatically detect that a peer also supports DOIC. For example, a node might have a peer that is a non-supporting agent. If nodes on the other side of that agent send OC-Supported-Features AVPs, the agent is likely to forward them as unknown AVPs. Messages received across the non-supporting agent may be indistinguishable from messages received across a DOIC supporting agent, giving the false impression that the non- supporting agent actually supports DOIC. This complicates the transitive-trust nature of DOIC. Operators need to be careful to avoid situations where a non-supporting agent is mistakenly trusted to enforce DOIC-related authorization policies. It is expected that work on end-to-end Diameter security might make it easier to establish trust in non-adjacent nodes for overload control purposes. Readers should be reminded, however, that the overload control mechanism allows Diameter Agents to modify AVPs in, or insert additional AVPs into, existing messages that are originated by other nodes. If end-to-end security is enabled, there is a risk that such modification could violate integrity protection. The details of using any future Diameter end-to-end security mechanism with overload control will require careful consideration, and are beyond the scope of this document.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>. [Cx] 3GPP, "Cx and Dx interfaces based on the Diameter protocol; Protocol details", 3GPP TS 29.229 12.7.0, September 2015. [PCC] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 12.10.0, September 2015. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, DOI 10.17487/RFC4006, August 2005, <http://www.rfc-editor.org/info/rfc4006>. [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control Requirements", RFC 7068, DOI 10.17487/RFC7068, November 2013, <http://www.rfc-editor.org/info/rfc7068>. [S13] 3GPP, "Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol", 3GPP TS 29.272 12.8.0, September 2015.
Sections 7.2 and 9 for the required IANA steps.
Inter-Realm/Administrative Domain Considerations There are likely to be special considerations for handling DOIC signaling across administrative boundaries. This includes considerations for whether or not information included in the DOIC signaling should be sent across those boundaries. In addition, consideration should be taken as to whether or not a reacting node in one realm can be trusted to implement the requested overload abatement handling for overload reports received from a separately administered realm. Section 8.1 of [RFC6733] defines two state machines that imply two types of applications, session-less and session-based applications. The primary difference between these types of applications is the lifetime of Session-Ids. For session-based applications, the Session-Id is used to tie multiple requests into a single session. The Credit-Control application defined in [RFC4006] is an example of a Diameter session-based application. In session-less applications, the lifetime of the Session-Id is a single Diameter transaction, i.e., the session is implicitly terminated after a single Diameter transaction and a new Session-Id is generated for each Diameter request.
For the purposes of this discussion, session-less applications are further divided into two types of applications: Stateless Applications: Requests within a stateless application have no relationship to each other. The 3GPP-defined S13 application is an example of a stateless application [S13], where only a Diameter command is defined between a client and a server and no state is maintained between two consecutive transactions. Pseudo-Session Applications: Applications that do not rely on the Session-Id AVP for correlation of application messages related to the same session but use other session-related information in the Diameter requests for this purpose. The 3GPP-defined Cx application [Cx] is an example of a pseudo-session application. The handling of overload reports must take the type of application into consideration, as discussed in Appendix C.2. Appendix C.3 discusses considerations for handling various request types when the target server is known to be in an overloaded state. These discussions assume that the strategy for mitigating the reported overload is to reduce the overall workload sent to the overloaded entity. The concept of applying overload treatment to requests targeted for an overloaded Diameter entity is inherent to this discussion. The method used to reduce offered load is not specified here, but it could include routing requests to another Diameter entity known to be able to handle them, or it could mean rejecting certain requests. For a Diameter Agent, rejecting requests will usually mean generating appropriate Diameter error responses. For a Diameter client, rejecting requests will depend upon the application. For example, it could mean giving an indication to the entity requesting the Diameter service that the network is busy and to try again later.
Stateless Applications: By definition, there is no relationship between individual requests in a stateless application. As a result, when a request is sent or relayed to an overloaded Diameter entity -- either a Diameter Server or a Diameter Agent -- the sending or relaying entity can choose to apply the overload treatment to any request targeted for the overloaded entity. Pseudo-session Applications: For pseudo-session applications, there is an implied ordering of requests. As a result, decisions about which requests towards an overloaded entity to reject could take the command code of the request into consideration. This generally means that transactions later in the sequence of transactions should be given more favorable treatment than messages earlier in the sequence. This is because more work has already been done by the Diameter network for those transactions that occur later in the sequence. Rejecting them could result in increasing the load on the network as the transactions earlier in the sequence might also need to be repeated. Session-Based Applications: Overload handling for session-based applications must take into consideration the work load associated with setting up and maintaining a session. As such, the entity sending requests towards an overloaded Diameter entity for a session-based application might tend to reject new session requests prior to rejecting intra-session requests. In addition, session-ending requests might be given a lower probability of being rejected, as rejecting session-ending requests could result in session status being out of sync between the Diameter clients and servers. Application designers that would decide to reject mid-session requests will need to consider whether the rejection invalidates the session and any resulting session cleanup procedures.
Session-Initiating Request: A session-initiating request is the initial message that establishes a Diameter session. The ACR message defined in [RFC6733] is an example of a session-initiating request. Correlated Session-Initiating Request: There are cases when multiple session-initiated requests must be correlated and managed by the same Diameter server. It is notably the case in the 3GPP Policy and Charging Control (PCC) architecture [PCC], where multiple apparently independent Diameter application sessions are actually correlated and must be handled by the same Diameter server. Intra-session Request: An intra-session request is a request that uses the same Session- Id as the one used in a previous request. An intra-session request generally needs to be delivered to the server that handled the session-creating request for the session. The STR message defined in [RFC6733] is an example of an intra-session request. Pseudo-session Requests: Pseudo-session requests are independent requests and do not use the same Session-Id but are correlated by other session-related information contained in the request. There exist Diameter applications that define an expected ordering of transactions. This sequencing of independent transactions results in a pseudo- session. The AIR, MAR, and SAR requests in the 3GPP-defined Cx [Cx] application are examples of pseudo-session requests. Appendix C.3 have implications on decisions about which requests should be throttled first. The following list of request treatments regarding throttling is provided as guidelines for application designers when implementing the Diameter overload control mechanism described in this document. The exact behavior regarding throttling is a matter of local policy, unless specifically defined for the application. Independent Requests: Independent requests can generally be given equal treatment when making throttling decisions, unless otherwise indicated by application requirements or local policy.
Session-Initiating Requests: Session-initiating requests often represent more work than independent or intra-session requests. Moreover, session- initiating requests are typically followed by other session- related requests. Since the main objective of overload control is to reduce the total number of requests sent to the overloaded entity, throttling decisions might favor allowing intra-session requests over session-initiating requests. In the absence of local policies or application-specific requirements to the contrary, individual session-initiating requests can be given equal treatment when making throttling decisions. Correlated Session-Initiating Requests: A request that results in a new binding; where the binding is used for routing of subsequent session-initiating requests to the same server, it represents more work load than other requests. As such, these requests might be throttled more frequently than other request types. Pseudo-session Requests: Throttling decisions for pseudo-session requests can take into consideration where individual requests fit into the overall sequence of requests within the pseudo-session. Requests that are earlier in the sequence might be throttled more aggressively than requests that occur later in the sequence. Intra-session Requests: There are two types of intra-sessions requests, requests that terminate a session and the remainder of intra-session requests. Implementers and operators may choose to throttle session- terminating requests less aggressively in order to gracefully terminate sessions, allow cleanup of the related resources (e.g., session state), and avoid the need for additional intra-session requests. Favoring session termination requests may reduce the session management impact on the overloaded entity. The default handling of other intra-session requests might be to treat them equally when making throttling decisions. There might also be application-level considerations whether some request types are favored over others.