Session Initiation Protocol (SIP) Overload Control
DOCNAME

Abstract

Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines an overload control mechanism for SIP.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on May 23, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Terminology
3.  Overview of operations
4.  Via Header Parameters for Overload Control
    4.1.  The 'oc' Parameter
    4.2.  Creating the Overload Control Parameters
    4.3.  Determining the 'oc' Parameter Value
    4.4.  Processing the Overload Control Parameters
    4.5.  Using the Overload Control Parameter Values
    4.6.  Forwarding the overload control parameters
    4.7.  Self-Limiting
5.  Responding to an Overload Indication
    5.1.  Message prioritization at the hop before the overloaded server
    5.2.  Rejecting requests at an overloaded server
6.  Syntax
7.  Design Considerations
    7.1.  SIP Mechanism
        7.1.1.  SIP Response Header
        7.1.2.  SIP Event Package
    7.2.  Backwards Compatibility
8.  Security Considerations
9.  IANA Considerations
10.  References
    10.1.  Normative References
    10.2.  Informative References
Appendix A.  Acknowledgements
§  Authors' Addresses

1.  Introduction

As with any network element, a Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) server can suffer from overload when the number of SIP messages it receives exceeds the number of messages it can process. Overload can pose a serious problem for a network of SIP servers. During periods of overload, the throughput of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the throughput drops down to a small fraction of the original processing capacity. This is often called congestion collapse.

Overload is said to occur if a SIP server does not have sufficient resources to process all incoming SIP messages. These resources may include CPU processing capacity, memory, network bandwidth, input/output, or disk resources.

For overload control, we only consider failure cases where SIP servers are unable to process all SIP requests due to resource constraints. There are other cases where a SIP server can successfully process incoming requests but has to reject them due to failure conditions unrelated to the SIP server being overloaded. For example, a PSTN gateway that runs out of trunk lines but still has plenty of capacity to process SIP messages should reject incoming INVITEs using a 488 (Not Acceptable Here) response [RFC4412] (Schulzrinne, H. and J. Polk, “Communications Resource Priority for the Session Initiation Protocol (SIP),” February 2006.). Similarly, a SIP registrar that has lost connectivity to its registration database but is still capable of processing SIP requests should reject REGISTER requests with a 500 (Server Error) response [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). Overload control does not apply to these cases and SIP provides appropriate response codes for them.

The SIP protocol provides a limited mechanism for overload control through its 503 (Service Unavailable) response code. However, this mechanism cannot prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, the use of the 503 (Service Unavailable) response code may cause traffic to oscillate and to shift between SIP servers and thereby worsen an overload condition. A detailed discussion of the SIP overload problem, the problems with the 503 (Service Unavailable) response code and the requirements for a SIP overload control mechanism can be found in [RFC5390] (Rosenberg, J., “Requirements for Management of Overload in the Session Initiation Protocol,” December 2008.).

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

3.  Overview of operations

We now explain the overview of how the overload control mechanism operates by introducing the overload control parameters. Section 4 (Via Header Parameters for Overload Control) provides more details and normative behavior on the parameters listed below.

Because overload control is best performed hop-by-hop, the Via parameter is attractive since it allows two adjacent SIP entities to indicate support for, and exchange information associated with overload control. Additional advantages of this choice are discussed in Section 7.1.1 (SIP Response Header). An alternative mechanism using SIP event packages was also considered, and the characteristics of that choice are further outlined in Section 7.1.2 (SIP Event Package).

This document defines three new parameters for the SIP Via header for overload control. These parameters provide a SIP mechanism for conveying overload control information between adjacent SIP entities.) These parameters are:

1. oc: This parameter serves a dual purpose; when inserted by a SIP entity in a request going downstream, the parameter indicates that the SIP entity supports overload control. When the downstream SIP server sends a response, the downstream SIP server will add a value to the parameter that indicates a loss rate (in percentage) by which the requests arriving at the downstream SIP server should be reduced. (c.f. Section 4.2 (Creating the Overload Control Parameters), Section 4.3 (Determining the 'oc' Parameter Value), Section 4.4 (Processing the Overload Control Parameters) and Section 4.5 (Using the Overload Control Parameter Values).)
2. oc-validity: Inserted by the SIP entity sending a response upstream. This parameter contains a value that indicates the time (in ms) that the load reduction specified by the "oc" parameter should be in effect (c.f. Section 4.2 (Creating the Overload Control Parameters).)
3. oc-seq: Inserted by the SIP entity sending a response upstream. This parameter contains a value that indicates the sequence number associated with the "oc" parameter defined above (c.f. Section Section 4.2 (Creating the Overload Control Parameters)).

Consider a SIP entity, P1, which is sending requests to another downstream SIP server, P2. The following snippets of SIP messages demonstrate how the overload control parameters work.

       INVITE sips:user@example.com SIP/2.0
       Via: SIP/2.0/TLS p1.example.net;
         branch=z9hG4bK2d4790.1;received=192.0.2.111;oc
       ...

       SIP/2.0 100 Trying
       Via: SIP/2.0/TLS p1.example.net;
         branch=z9hG4bK2d4790.1;received=192.0.2.111;
         oc=20;oc-validity=500;oc-seq=1282321615.781
       ...

In the messages above, the first line is sent by P1 to P2. This line is a SIP request; because P1 supports overload control, it inserts the "oc" parameter in the topmost Via header that it created.

The second line --- a SIP response --- shows the topmost Via header amended by P2 according to this specification and sent to P1. Because P2 also supports overload control, it sends back further overload control parameters towards P1 requesting that P1 reduce the incoming traffic by 20% for 500ms. P2 updates the "oc" parameter to add a value and inserts the remaining two parameters, "oc-validity" and "oc-seq".

4.  Via Header Parameters for Overload Control

4.1.  The 'oc' Parameter

A SIP entity that supports this specification MUST add an "oc" parameter to the Via headers it inserts into SIP requests. This provides an indication to downstream neighbors that this server supports overload control. When inserted into a request by a SIP entity to indicate support for overload control, there MUST NOT be a value associated with the parameter.

4.2.  Creating the Overload Control Parameters

A SIP server can provide overload control feedback to its upstream neighbors by providing a value for the "oc" parameter to the topmost Via header field of a SIP response. The topmost Via header is determined after the SIP server has removed its own Via header; i.e., it is the Via header that was generated by the upstream neighbor.

Since the topmost Via header of a response will be removed by an upstream neighbor after processing it, overload control feedback contained in the "oc" parameter will not travel beyond the upstream SIP entity. A Via header parameter therefore provides hop-by-hop semantics for overload control feedback (see [I‑D.ietf‑soc‑overload‑design] (Hilt, V., Noel, E., Shen, C., and A. Abdelal, “Design Considerations for Session Initiation Protocol (SIP) Overload Control,” August 2010.)) even if the next hop neighbor does not support this specification.

The "oc: parameter can be used in all response types, including provisional, success and failure responses. A SIP server MAY update the "oc" parameter to all responses it is sending. A SIP server MUST update the "oc" parameter to responses when the transmission of overload control feedback is required by the overload control algorithm to limit the traffic received by the server. I.e., a SIP server MUST update the "oc" parameter when the overload control algorithm sets the value of an "oc" parameter to a value different than the default value.

A SIP server that has updated the "oc" parameter to Via header SHOULD also add a "oc_validity" parameter to the same Via header. The "oc_validity" parameter defines the time in milliseconds during which the content (i.e., the overload control feedback) of the "oc" parameter is valid. The default value of the "oc_validity" parameter is 500 (millisecond). A SIP server SHOULD use a shorter "oc_validity" time if its overload status varies quickly and MAY use a longer "oc_validity" time if this status is more stable. If the "oc_validity" parameter is not present, its default value is used. The "oc_validity" parameter MUST NOT be used in a Via header that did not originally contain an "oc" parameter when received. Furthermore, when a SIP server receives a request with the topmost Via header containing only an "oc-validity" parameter without the accompanying "oc" parameter. it MUST ignore the "oc-validity" parameter.

When a SIP server retransmits a response, it SHOULD use the "oc" parameter value and "oc-validity" parameter value consistent with the overload state at the time the retransmitted response is sent. This implies that the values in the "oc" and "oc-validity" parameters may be different then the ones used in previous retransmissions of the response. Due to the fact that responses sent over UDP may be subject to delays in the network and arrive out of order, the "oc-seq" parameter aids in detecting a stale "oc" parameter value.

Implementations that are capable of updating the "oc" and "oc-validity" parameter values for retransmissions MUST insert the "oc-seq" parameter. The value of this parameter MUST be a set of numbers drawn from an increasing sequence.

Implementations that are not capable of updating the "oc" and "oc-validity" parameter values for retransmissions --- or implementations that do not want to do so because they will have to regenerate the message to be retransmitted --- MUST still insert a "oc-seq" parameter in the first response associated with a transaction; however, they do not have to update the value in subsequent retransmissions.

The "oc_validity" and "oc-seq" Via header parameters are only defined in SIP responses and MUST NOT be used in SIP requests. These parameters are only useful to the upstream neighbor of a SIP server (i.e., the entity that is sending requests to the SIP server) since this is the entity that can offload traffic by redirecting/rejecting new requests. If requests are forwarded in both directions between two SIP servers (i.e., the roles of upstream/downstream neighbors change), there are also responses flowing in both directions. Thus, both SIP servers can exchange overload information.

Since overload control protects a SIP server from overload, it is RECOMMENDED that a SIP server use the mechanisms described in this specification. However, if a SIP server wanted to limit its overload control capability for privacy reasons, it MAY decide to perform overload control only for requests that are received on a secure transport channel, such as TLS. This enables a SIP server to protect overload control information and ensure that it is only visible to trusted parties.

4.3.  Determining the 'oc' Parameter Value

The value of the "oc" parameter is determined by an overload control algorithm (see [I‑D.ietf‑soc‑overload‑design] (Hilt, V., Noel, E., Shen, C., and A. Abdelal, “Design Considerations for Session Initiation Protocol (SIP) Overload Control,” August 2010.)). This specification does not mandate the use of a specific overload control algorithm. However, the output of an overload control algorithm MUST be compliant to the semantics of this Via header parameter.

The "oc" parameter value specifies the percentage by which the load forwarded to this SIP server should be reduced. Possible values range from 0 (the traffic forwarded is reduced by 0%, i.e., all traffic is forwarded) to 100 (the traffic forwarded is reduced by 100%, i.e., no traffic forwarded). The default value of this parameter is 0.

OPEN ISSUE 1: The "oc" parameter value specified in this document is defined to contain a loss rate. However, other types of overload control feedback exist, for example, a target rate for rate-based overload control or message confirmations and window-size for window-based overload control.

While it would in theory be possible to allow multiple types of overload control feedback to co-exist (e.g., by using different parameters for the different feedback types) it is very problematic for interoperability purposes and would require SIP servers to implement multiple overload control mechanisms.

4.4.  Processing the Overload Control Parameters

A SIP entity compliant to this specification SHOULD remove "oc", "oc_validity" and "oc-seq" parameters from all Via headers of a response received, except for the topmost Via header. This prevents overload control parameters that were accidentally or maliciously inserted into Via headers by a downstream SIP server from traveling upstream.

A SIP entity maintains the "oc" parameter values received along with the address and port number of the SIP servers from which they were received for the duration specified in the "oc_validity" parameter or the default duration. Each time a SIP entity receives a response with an "oc" parameter from a downstream SIP server, it overwrites the "oc" value it has currently stored for this server with the new value received. The SIP entity restarts the validity period of an "oc" parameter each time a response with an "oc" parameter is received from this server. A stored "oc" parameter value MUST be discarded once it has reached the end of its validity.

4.5.  Using the Overload Control Parameter Values

A SIP entity compliant to this specification MUST honor overload control values it receives from downstream neighbors. The SIP entity MUST NOT forward more requests to a SIP server than allowed by the current "oc" parameter value from a particular downstream server.

When forwarding a SIP request, a SIP entity uses the SIP procedures of [RFC3263] (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.) to determine the next hop SIP server. The procedures of [RFC3263] (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.) take as input a SIP URI, extract the domain portion of that URI for use as a lookup key, and query the Domain Name Service (DNS) to obtain an ordered set of one or more IP addresses with a port number and transport corresponding to each IP address in this set (the "Expected Output").

After selecting a specific SIP server from the Expected Output, the SIP entity MUST determine if it already has overload control parameter values for the server chosen from the Expected Output. If the SIP entity has a non-expired "oc" parameter value for the server chosen from the Expected Output, and this chosen server is operating in overload control mode. Thus, the SIP entity MUST determine if it can or cannot forward the current request to the SIP server depending on the nature of the request and the prevailing overload conditions.

The particular algorithm used to determine whether or not to forward a particular SIP request is a matter of local policy, and may take into account a variety of prioritization factors. However, this local policy SHOULD generate the same number and rate of SIP requests as the default algorithm (to be determined), which treats all requests as equal.

In the absence of a different local policy, the SIP entity SHOULD use the following default algorithm to determine if it can forward the request downstream (TODO: Need to devise an algorithm. The original simple algorithm based on random number generation does not suffice for all cases.)

4.6.  Forwarding the overload control parameters

A SIP entity MAY forward the content of an "oc" parameter it has received from a downstream neighbor on to its upstream neighbor. However, forwarding the content of the "oc" parameter is generally NOT RECOMMENDED and should only be performed if permitted by the configuration of SIP servers. For example, a SIP server that only relays messages between exactly two SIP servers may forward an "oc" parameter. The "oc" parameter is forwarded by copying it from the Via in which it was received into the next Via header (i.e., the Via header that will be on top after processing the response). If an "oc_validity" parameter is present, MUST be copied along with the "oc" parameter.

4.7.  Self-Limiting

In some cases, a SIP entity may not receive a response from a downstream server after sending a request. RFC3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] defines that when a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer, it MUST be treated as a 503 (Service Unavailable) status code.

In the event of repeated timeouts or fatal transport errors, the SIP entity MUST stop sending requests to this server. The SIP entity SHOULD occasionally forward a single request to probe if the downstream server is alive. Once a SIP entity has successfully transmitted a request to the downstream server, the SIP entity can resume normal traffic rates. It should, of course, honor any "oc" parameters it may receive subsequent to resuming normal traffic rates.

OPEN ISSUE 2: If a downstream neighbor does not respond to a request at all, the upstream SIP entity will stop sending requests to the downstream neighbor. The upstream SIP entity will periodically forward a single request to probe the health of its downstream neighbor. It has been suggested --- see http://www.ietf.org/mail-archive/web/sip-overload/current/msg00229.html --- that we have a notification mechanism in place for the downstream neighbor to signal to the upstream SIP entity that it is ready to receive requests. This notification scheme has advantages, but comes with obvious disadvantages as well. Need some more discussion around this.

5.  Responding to an Overload Indication

A SIP entity can receive overload control feedback indicating that it needs to reduce the traffic it sends to its downstream server. The entity can accomplish this task by sending some of the requests that would have gone to the overloaded element to a different destination. It needs to ensure, however, that this destination is not in overload and capable of processing the extra load. An entity can also buffer requests in the hope that the overload condition will resolve quickly and the requests still can be forwarded in time. In many cases, however, it will need to reject these requests.

5.1.  Message prioritization at the hop before the overloaded server

During an overload condition, a SIP entity needs to prioritize requests and select those requests that need to be rejected or redirected. While this selection is largely a matter of local policy, certain heuristics can be suggested. One, during overload control, the SIP entity should preserve existing dialogs as much as possible. This suggests that mid-dialog requests MAY be given preferential treatment. Similarly, requests that result in releasing resources (such as a BYE) MAY also be given preferential treatment.

A SIP entity SHOULD honor the local policy for prioritizing SIP requests such as policies based on the content of the Resource-Priority header (RPH, RFC4412 (Schulzrinne, H. and J. Polk, “Communications Resource Priority for the Session Initiation Protocol (SIP),” February 2006.) [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. Other indicators, such as the SOS URN [RFC5031] (Schulzrinne, H., “A Uniform Resource Name (URN) for Emergency and Other Well-Known Services,” January 2008.) indicating an emergency request, may also be used for prioritization.

Local policy could also include giving precedence to mid- dialog SIP requests (re-INVITEs, UPDATEs, BYEs etc.) in times of overload. A local policy can be expected to combine both the SIP request type and the prioritization markings, and SHOULD be honored when overload conditions prevail.

5.2.  Rejecting requests at an overloaded server

If the upstream SIP entity to the overloaded server does not support overload control, it will continue to direct requests to the overloaded server. Thus, the overloaded server must bear the cost of rejecting some session requests as well as the cost of processing other requests to completion. It would be fair to devote the same amount of processing at the overloaded server to the combination of rejection and processing as the overloaded server would devote to processing requests from an upstream SIP entity that supported overload control. This is to ensure that SIP servers that do not support this specification don't receive an unfair advantage over those that do.

A SIP server that is under overload and has started to throttle incoming traffic MUST reject this request with a "503 (Service Unavailable)" response without Retry-After header to reject a fraction of requests from upstream neighbors that do not support overload control.

6.  Syntax

This section defines the syntax of new Via header parameters: "oc", "oc_validity", and "oc-seq".

The "oc" Via header parameter, when it has a value, MUST restrain that value to a number between 0 and 100. This value describes the percentage by which the traffic (SIP requests) to the SIP server from which the response has been received should be reduced. The default value for this parameter is 0.

The "oc_validity" Via header parameter contains the time during which the corresponding "oc" Via header parameter is valid. The "oc_validity" parameter can only be present in a Via header in conjunction with an "oc" parameter.

The "oc-seq" Via header parameter contains a sequence number. Those implementations that are capable of providing finer-grained overload control information may do so, however, each response that contains the updated overload control information MUST have an increasing value in this parameter. This is to allow the upstream server to properly order out-of-order responses that contain overload control information.

This specification extends the existing definition of the Via header field parameters of [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) as follows:

    via-params        =  via-ttl / via-maddr
                      / via-received / via-branch
                      / oc / oc-validity
                      / oc-seq / via-extension

oc = "oc" [EQUAL 0-100]

oc-validity = "oc_validity" [EQUAL delta-ms]

oc-seq = (1*12DIGIT "." 1*5DIGIT)

Example:

  Via: SIP/2.0/TCP ss1.atlanta.example.com:5060
    ;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
    ;oc=20;oc_validity=500;oc-seq=1282321615.641

7.  Design Considerations

This section discusses specific design considerations for the mechanism described in this document. General design considerations for SIP overload control can be found in [I‑D.ietf‑soc‑overload‑design] (Hilt, V., Noel, E., Shen, C., and A. Abdelal, “Design Considerations for Session Initiation Protocol (SIP) Overload Control,” August 2010.).

7.1.  SIP Mechanism

A SIP mechanism is needed to convey overload feedback from the receiving to the sending SIP entity. A number of different alternatives exist to implement such a mechanism.

7.1.1.  SIP Response Header

Overload control information can be transmitted using a new Via header field parameter for overload control. A SIP server can add this header parameter to the responses it is sending upstream to provide overload control feedback to its upstream neighbors. This approach has the following characteristics:

• A Via header parameter is light-weight and creates very little overhead. It does not require the transmission of additional messages for overload control and does not increase traffic or processing burdens in an overload situation.
• Overload control status can frequently be reported to upstream neighbors since it is a part of a SIP response. This enables the use of this mechanism in scenarios where the overload status needs to be adjusted frequently. It also enables the use of overload control mechanisms that use regular feedback such as window-based overload control.
• With a Via header parameter, overload control status is inherent in SIP signaling and is automatically conveyed to all relevant upstream neighbors, i.e., neighbors that are currently contributing traffic. There is no need for a SIP server to specifically track and manage the set of current upstream or downstream neighbors with which it should exchange overload feedback.
• Overload status is not conveyed to inactive senders. This avoids the transmission of overload feedback to inactive senders, which do not contribute traffic. If an inactive sender starts to transmit while the receiver is in overload it will receive overload feedback in the first response and can adjust the amount of traffic forwarded accordingly.
• A SIP server can limit the distribution of overload control information by only inserting it into responses to known upstream neighbors. A SIP server can use transport level authentication (e.g., via TLS) with its upstream neighbors.

7.1.2.  SIP Event Package

Overload control information can also be conveyed from a receiver to a sender using a new event package. Such an event package enables a sending entity to subscribe to the overload status of its downstream neighbors and receive notifications of overload control status changes in NOTIFY requests. This approach has the following characteristics:

• Overload control information is conveyed decoupled from SIP signaling. It enables an overload control manager, which is a separate entity, to monitor the load on other servers and provide overload control feedback to all SIP servers that have set up subscriptions with the controller.
• With an event package, a receiver can send updates to senders that are currently inactive. Inactive senders will receive a notification about the overload and can refrain from sending traffic to this neighbor until the overload condition is resolved. The receiver can also notify all potential senders once they are permitted to send traffic again. However, these notifications do generate additional traffic, which adds to the overall load.
• A SIP entity needs to set up and maintain overload control subscriptions with all upstream and downstream neighbors. A new subscription needs to be set up before/while a request is transmitted to a new downstream neighbor. Servers can be configured to subscribe at boot time. However, this would require additional protection to avoid the avalanche restart problem for overload control. Subscriptions need to be terminated when they are not needed any more, which can be done, for example, using a timeout mechanism.
• A receiver needs to send NOTIFY messages to all subscribed upstream neighbors in a timely manner when the control algorithm requires a change in the control variable (e.g., when a SIP server is in an overload condition). This includes active as well as inactive neighbors. These NOTIFYs add to the amount of traffic that needs to be processed. To ensure that these requests will not be dropped due to overload, a priority mechanism needs to be implemented in all servers these request will pass through.
• As overload feedback is sent to all senders in separate messages, this mechanism is not suitable when frequent overload control feedback is needed.
• A SIP server can limit the set of senders that can receive overload control information by authenticating subscriptions to this event package.
• This approach requires each proxy to implement user agent functionality (UAS and UAC) to manage the subscriptions.

7.2.  Backwards Compatibility

An new overload control mechanism needs to be backwards compatible so that it can be gradually introduced into a network and functions properly if only a fraction of the servers support it.

Hop-by-hop overload control (see [I‑D.ietf‑soc‑overload‑design] (Hilt, V., Noel, E., Shen, C., and A. Abdelal, “Design Considerations for Session Initiation Protocol (SIP) Overload Control,” August 2010.)) has the advantage that it does not require that all SIP entities in a network support it. It can be used effectively between two adjacent SIP servers if both servers support overload control and does not depend on the support from any other server or user agent. The more SIP servers in a network support hop-by-hop overload control, the better protected the network is against occurrences of overload.

A SIP server may have multiple upstream neighbors from which only some may support overload control. If a server would simply use this overload control mechanism, only those that support it would reduce traffic. Others would keep sending at the full rate and benefit from the throttling by the servers that support overload control. In other words, upstream neighbors that do not support overload control would be better off than those that do.

A SIP server should therefore use 5xx responses towards upstream neighbors that do not support overload control. The server should reject the same amount of requests with 5xx responses that would be otherwise be rejected/redirected by the upstream neighbor if it would support overload control. If the load condition on the server does not permit the creation of 5xx responses, the server should drop all requests from servers that do not support overload control.

8.  Security Considerations

Overload control mechanisms can be used by an attacker to conduct a denial-of-service attack on a SIP entity if the attacker can pretend that the SIP entity is overloaded. When such a forged overload indication is received by an upstream SIP entity, it will stop sending traffic to the victim. Thus, the victim is subject to a denial-of-service attack.

An attacker can create forged overload feedback by inserting itself into the communication between the victim and its upstream neighbors. The attacker would need to add overload feedback indicating a high load to the responses passed from the victim to its upstream neighbor. Proxies can prevent this attack by communicating via TLS. Since overload feedback has no meaning beyond the next hop, there is no need to secure the communication over multiple hops.

Another way to conduct an attack is to send a message containing a high overload feedback value through a proxy that does not support this extension. If this feedback is added to the second Via headers (or all Via headers), it will reach the next upstream proxy. If the attacker can make the recipient believe that the overload status was created by its direct downstream neighbor (and not by the attacker further downstream) the recipient stops sending traffic to the victim. A precondition for this attack is that the victim proxy does not support this extension since it would not pass through overload control feedback otherwise.

A malicious SIP entity could gain an advantage by pretending to support this specification but never reducing the amount of traffic it forwards to the downstream neighbor. If its downstream neighbor receives traffic from multiple sources which correctly implement overload control, the malicious SIP entity would benefit since all other sources to its downstream neighbor would reduce load.

The solution to this problem depends on the overload control method. For rate-based and window-based overload control, it is very easy for a downstream entity to monitor if the upstream neighbor throttles traffic forwarded as directed. For percentage throttling this is not always obvious since the load forwarded depends on the load received by the upstream neighbor.

9.  IANA Considerations

[TBD.]

10.  References

10.1. Normative References

10.2. Informative References

Appendix A.  Acknowledgements

Many thanks to Rich Terpstra, Daryl Malas, Jonathan Rosenberg, Charles Shen, Padma Valluri, Janet Gunn, Shaun Bharrat, and Paul Kyzivat for their contributions to this specification.

Authors' Addresses