SIPPING Working Group V. Hilt Internet-Draft I. Widjaja Expires: April 28, 2008 Bell Labs/Alcatel-Lucent D. Malas Level 3 Communications H. Schulzrinne Columbia University October 26, 2007 Session Initiation Protocol (SIP) Overload Control draft-hilt-sipping-overload-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). 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) Hilt, et al. Expires April 28, 2008 [Page 1] Internet-Draft Overload Control October 2007 response code, SIP servers are still vulnerable to overload. This document proposes new overload control mechanisms for SIP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 3.1. System Model . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Degree of Cooperation . . . . . . . . . . . . . . . . . . 6 3.2.1. Local Overload Control . . . . . . . . . . . . . . . . 7 3.2.2. Hop-by-Hop . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. End-to-End . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Topologies . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Overload Control Method . . . . . . . . . . . . . . . . . 11 3.4.1. Rate-based Overload Control . . . . . . . . . . . . . 11 3.4.2. Loss-based Overload Control . . . . . . . . . . . . . 12 3.4.3. Window-based Overload Control . . . . . . . . . . . . 13 3.5. Overload Control Algorithms . . . . . . . . . . . . . . . 14 3.6. Load Status . . . . . . . . . . . . . . . . . . . . . . . 15 3.7. SIP Mechanism . . . . . . . . . . . . . . . . . . . . . . 15 3.7.1. SIP Response Header . . . . . . . . . . . . . . . . . 15 3.7.2. SIP Event Package . . . . . . . . . . . . . . . . . . 16 3.8. Backwards Compatibility . . . . . . . . . . . . . . . . . 17 3.9. Interaction with Local Overload Control . . . . . . . . . 18 4. SIP Application Considerations . . . . . . . . . . . . . . . . 18 4.1. Responding to an Overload Indication . . . . . . . . . . . 18 4.2. Message Prioritization . . . . . . . . . . . . . . . . . . 18 4.3. Privacy Considerations . . . . . . . . . . . . . . . . . . 19 5. In-Band: 'Overload-Control' Header Field . . . . . . . . . . . 19 5.1. Generating the 'Overload-Control' Header . . . . . . . . . 19 5.2. Determining the 'Overload-Control' Header Value . . . . . 21 5.3. Processing the 'Overload-Control' Header . . . . . . . . . 21 5.4. Using the 'Overload-Control' Header Value . . . . . . . . 23 5.5. Rejecting Requests . . . . . . . . . . . . . . . . . . . . 23 5.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Out-Of-Band: 'Overload-Control' Event Package . . . . . . . . 25 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 25 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 25 6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 25 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 26 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 26 6.6. Subscriber generation of SUBSCRIBE requests . . . . . . . 27 6.7. Notifier processing of SUBSCRIBE requests . . . . . . . . 27 6.8. Notifier generation of NOTIFY requests . . . . . . . . . . 27 6.9. Subscriber processing of NOTIFY requests . . . . . . . . . 28 6.10. Handling of forked requests . . . . . . . . . . . . . . . 28 Hilt, et al. Expires April 28, 2008 [Page 2] Internet-Draft Overload Control October 2007 6.11. Rate of notifications . . . . . . . . . . . . . . . . . . 28 6.12. State Agents . . . . . . . . . . . . . . . . . . . . . . . 29 6.13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Hilt, et al. Expires April 28, 2008 [Page 3] Internet-Draft Overload Control October 2007 1. Introduction As with any network element, a Session Initiation Protocol (SIP) [2] 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. There are other cases where a SIP server can successfully process incoming requests but has to reject them due to other failure conditions. 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 [5]. Similarly, a SIP registrar that has lost connectivity to its registration database but is still capable of processing SIP messages should reject REGISTER requests with a 500 (Server Error) response [2]. Overload control does not apply to these cases and SIP provides 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 [7]. 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 [1]. Hilt, et al. Expires April 28, 2008 [Page 4] Internet-Draft Overload Control October 2007 3. Design Considerations This section discusses key design considerations for a SIP overload control mechanism. The design goal for this mechanism is to enable a SIP server to control the amount of traffic it receives from its upstream neighbors. 3.1. System Model The model shown in Figure 1 identifies fundamental components of an SIP overload control system: SIP Processor: The SIP Processor processes SIP messages and is the component that is protected by overload control. Monitor: The Monitor measures the current load of the SIP processor on the receiving entity. It implements the mechanisms needed to determine the current usage of resources relevant for the SIP processor and reports load samples (S) to the Control Function. Control Function: The Control Function implements the overload control mechanism on the receiving and sending entity. The control function uses the load samples (S). It determines if overload has occurred and a throttle (T) needs to be set to adjust the load sent to the SIP processor on the receiving entity. The control function on the receiving entity sends load feedback (F) to the control function sending entity. Actuator: The Actuator implements the algorithms needed to act on the throttles (T) and to adjust the amount of traffic forwarded to the receiving entity. For example, a throttle may instruct the Actuator to reduce the traffic destined to the receiving entity by 10%. The algorithms in the Actuator then determine how the traffic reduction is achieved, e.g., by selecting the messages that will be affected and determining whether they are rejected or redirected. The type of feedback (F) conveyed from the receiving to the sending entity depends on the overload control method used (i.e., loss-based, rate-based or window-based overload control; see Section 3.4), the overload control algorithm Section 3.5 as well as other design parameters. In any case, the feedback (F) enables the sending entity to adjust the amount of traffic forwarded to the receiving entity to a level that is acceptable to the receiving entity without causing overload. Hilt, et al. Expires April 28, 2008 [Page 5] Internet-Draft Overload Control October 2007 Sending Receiving Entity Entity +----------------+ +----------------+ | Server A | | Server B | | +----------+ | | +----------+ | -+ | | Control | | F | | Control | | | | | Function |<-+------+--| Function | | | | +----------+ | | +----------+ | | | T | | | ^ | | Overload | v | | | S | | Control | +----------+ | | +----------+ | | | | Actuator | | | | Monitor | | | | +----------+ | | +----------+ | | | | | | ^ | -+ | v | | | | -+ | +----------+ | | +----------+ | | <-+--| SIP | | | | SIP | | | SIP --+->|Processor |--+------+->|Processor |--+-> | System | +----------+ | | +----------+ | | +----------------+ +----------------+ -+ Figure 1: System Model for Overload Control 3.2. Degree of Cooperation A SIP request is often processed by more than one SIP server on its path to the destination. Thus, a design choice for overload control involves the placement of overload control components (in particular the Monitor and Actuator) on the SIP servers on the path of a request and, consequently, the degree of cooperation between these SIP servers. Overload control can be implemented locally (i.e., Monitor and Actuator on the same server), hop-by-hop (i.e., Monitor on a server and Actuator on its direct upstream neighbor), or end-to-end (i.e., Monitors on all SIP servers along the path of a request and one Actuator on the sender). These configurations are show in Figure 2. Hilt, et al. Expires April 28, 2008 [Page 6] Internet-Draft Overload Control October 2007 +-+ +---------+ v | +------+ | | +-+ +-+ +---+ | | | +---+ v | v | //=>| C | v | v //=>| C | +---+ +---+ // +---+ +---+ +---+ // +---+ | A |===>| B | | A |===>| B | +---+ +---+ \\ +---+ +---+ +---+ \\ +---+ \\=>| D | ^ \\=>| D | +---+ | +---+ ^ | | | +-+ +---------+ (a) local (b) hop-by-hop +-------+----------+ | ^ | | | +---+ v | //=>| C | +---+ +---+ // +---+ | A |===>| B | +---+ +---+ \\ +---+ ^ | \\=>| D | | | +---+ | v | +-------+----------+ (c) end-to-end ==> SIP request flow <-- Overload feedback loop Figure 2: Degree of Cooperation between Servers 3.2.1. Local Overload Control Servers can locally implement overload control mechanisms that do not require any cooperation with neighbor. All overload control components (Monitor, Control Function, Actuator) reside on the same SIP element. The goal of local overload control is to reject requests when overload occurs with minimal effort, i.e., before they are fully processed. Since rejecting these messages requires less processing capacity than processing them, a server is able to gracefully reject excess messages instead of simply dropping them. However, once the number of incoming requests exceeds the server's capacity to reject them, the server will become overloaded. Local overload control does not require protocol support and is out Hilt, et al. Expires April 28, 2008 [Page 7] Internet-Draft Overload Control October 2007 of scope for this document. 3.2.2. Hop-by-Hop In the hop-by-hop model, a separate control loop is instantiated between all neighboring SIP servers that directly exchange traffic. I.e., the Actuator is located on the SIP server that is the direct upstream neighbor of the SIP server that has the corresponding Montitor. This control loop is completely independent of the control loops between servers further up- or downstream. In the example in Figure 2(b), three independent overload control loops are instantiated: A - B, B - C and B - D. Each loop only covers a single hop. Overload feedback received from a downstream neighbor is therefore not forwarded further upstream. Instead, a SIP server acts on this feedback, for example, by re-routing or rejecting traffic if needed. The upstream neighbor of a server instantiates a separate overload control loop with its upstream neighbors. If the neighbor becomes overloaded, it will report this problem to its upstream neighbors, which again take action based on the reported feedback. Thus, in hop-by-hop overload control, overload is always resolved by the direct upstream neighbors of the overloaded server without the need to involve entities that are located multiple SIP hops away. Hop-by-hop overload control reduces the impact of overload on a SIP network and, in particular, can avoid congestion collapse. In addition, hop-by-hop overload control is simple and scales well to networks with many SIP entities. It does not require a SIP entity to aggregate a large number of overload status values or keep track of the overload status of SIP servers it is not communicating with. 3.2.3. End-to-End End-to-end overload control implements an overload control loop along the entire path of a SIP request, from UAC to UAS. An end-to-end overload control mechanism needs to consider overload information from all SIP servers on the way, including all proxies and the UAS. It has to be able to frequently collect the overload status of all servers on the potential path(s) to a destination and combine this data into meaningful overload feedback. A UA or SIP server only needs to throttle requests if it knows that these requests will eventually be forwarded to an overloaded server. For example, if D is overloaded in Figure 2(c), A should only throttle requests it forwards to B when it knows that they will be forwarded to D. It should not throttle requests that will eventually be forwarded to C, since server C is not overloaded. In many cases, Hilt, et al. Expires April 28, 2008 [Page 8] Internet-Draft Overload Control October 2007 it is difficult for A to determine which requests will be routed to C and D since this depends on the local routing decision made by B. The main problem of end-to-end path overload control is its inherent complexity since a UAC or SIP server needs to monitor all potential paths to a destination in order to determine which requests should be throttled and which requests may be sent. In addition, the routing decisions of a SIP server depend on local policy, which can be difficult to infer for an upstream neighbor. Therefore, end-to-end overload control is likely to only work well in simple, well-known topologies (e.g., a server is known to only have one downstream neighbor) or if a UA/server sends many requests to the exact same destination. 3.3. Topologies The following topologies describe four generic SIP server configurations, which each poses specific challenges for an overload control mechanism. In the "load balancer" configuration shown in Figure 3(a) a set of SIP servers (D, E and F) receives traffic from a single source A. A load balancer is a typical example for such a configuration. In this configuration, overload control needs to prevent server A (i.e., the load balancer) from sending too much traffic to any of its downstream neighbors D, E and F. If one of the downstream neighbors becomes overloaded, A can direct traffic to the servers that still have capacity. If one of the servers serves as a backup, it can be activated once one of the primary servers reaches overload. If A can reliably determine that D, E and F are its only downstream neighbors and all of them are in overload, it may choose to report overload to its upstream neighbor. However, if the set of downstream neighbors is not fixed or only some of them are in overload then A cannot use overload control. The reason is that A can still forward all requests destined to non-overloaded downstream neighbors. These requests would be throttled as well if A would use overload control towards its upstream neighbors. A should therefore reject the messages that are destined to its overloaded neighbors and would exceed their capacity as long as A is not overloaded itself. In the "multiple sources" configuration shown in Figure 3(b), a SIP server D receives traffic from multiple upstream sources A, B and C. Each of these sources can contribute a different amount of traffic, which can vary over time. Sources may become inactive and previously inactive servers may start contributing traffic to D. If D becomes overloaded, it needs to generate feedback to reduce the Hilt, et al. Expires April 28, 2008 [Page 9] Internet-Draft Overload Control October 2007 amount of traffic it receives from its upstream neighbors. D needs to decide by how much each upstream neighbor should reduce traffic. This decision can require the consideration of the amount of traffic sent by each upstream neighbor and it may need to be re-adjusted as the traffic contributed by each upstream neighbor varies over time. An important goal for generating overload control feedback is to achieve fairness among requests sent from upstream neighbors. Fairness can be defined as each request that is routed to D having an equal chance of being processed. However, a SIP server may also have a local policy that prefers some sources over others. For example, it can throttle a less preferred upstream neighbor more or earlier than a preferred neighbor. In many configurations, SIP servers form a "mesh" as shown in Figure 3(c). Here, multiple upstream servers A, B and C forward traffic to multiple alternative servers D and E. This configuration is a combination of the "load balancer" and "multiple sources" scenario. +---+ +---+ /->| D | | A |-\ / +---+ +---+ \ / \ +---+ +---+-/ +---+ +---+ \->| | | A |------>| E | | B |------>| D | +---+-\ +---+ +---+ /->| | \ / +---+ \ +---+ +---+ / \->| F | | C |-/ +---+ +---+ (a) load balancer (b) multiple sources +---+ | A |---\ a--\ +---+=\ \---->+---+ \ \/----->| D | b--\ \--->+---+ +---+--/\ /-->+---+ \---->| | | B | \/ c-------->| D | +---+===\/\===>+---+ | | /\====>| E | ... /--->+---+ +---+--/ /==>+---+ / | C |=====/ z--/ +---+ (c) mesh (d) edge proxy Hilt, et al. Expires April 28, 2008 [Page 10] Internet-Draft Overload Control October 2007 Figure 3: Topologies Overload control that is based on lowering the number of messages contributed by a sender is not suited for servers that receive requests from a very large population of senders, each of which only infrequently sends a request. This scenario is shown in Figure 3(d). An edge proxy that is connected to many UAs is a typical example for such a configuration. Since each UA typically only contributes a few requests, which are often related to the same call, it can't decrease its message rate to resolve the overload. In such a configuration, a SIP server can resort to local overload control by rejecting a percentage of the requests it receives with 503 (Service Unavailable) responses. Since there are many upstream neighbors that contribute to the overall load, sending 503 (Service Unavailable) to a fraction of them can gradually reduce load without entirely stopping all incoming traffic. Using 503 (Service Unavailable) towards individual sources can, however, not prevent overload if a large number of users places calls at the same time. OPEN ISSUE: The requirements of the "edge proxy" topology are different than the ones of the other topologies, which may require a different method for overload control. 3.4. Overload Control Method The method used by an overload control mechanism to limit the amount of traffic forwarded to an element is an important aspect of the design. We discuss the following three different types of overload control methods: rate-based, loss-based and window-based overload control. 3.4.1. Rate-based Overload Control The key idea of rate-based overload control is to limit the request rate at which an upstream element is allowed to forward to the downstream neighbor. If overload occurs, a SIP server instructs each upstream neighbor to send at most X requests per second. Each upstream neighbor can be assigned a different rate cap. The rate cap ensures that the number of requests received by a SIP server never increases beyond the sum of all rate caps granted to upstream neighbors. It can protect a SIP server against overload even during load spikes if no new upstream neighbors start sending traffic. New upstream neighbors need to be factored into the rate caps assigned as soon as they appear. The current overall rate cap used by a SIP server is determined by an overload control algorithm, e.g., based on system load. Hilt, et al. Expires April 28, 2008 [Page 11] Internet-Draft Overload Control October 2007 An algorithm for the sending entity to implement a rate cap of a given number of requests per second X is request gapping. After transmitting a request to a downstream neighbor, a server waits for 1/X seconds before it transmits the next request to the same neighbor. Requests that arrive during the waiting period are not forwarded and are either redirected, rejected or buffered. The main drawback of this mechanism is that it requires a SIP server to assign a certain rate cap to each of its upstream neighbors based on its overall capacity. Effectively, a server assigns a share of its capacity to each upstream neighbor. The server needs to ensure that the sum of all rate caps assigned to upstream neighbors is not (significantly) higher than its actual processing capacity. This requires a SIP server to continuously evaluate the amount of load it receives from each upstream neighbor and assign a rate cap that is suitable for this neighbor without limiting it too much. For example, in a non-overloaded situation, it could assign a rate cap that is 10% higher than the current number of requests received from this neighbor. This rate cap needs to be adjusted if the number of requests generated by the upstream neighbor changes (e.g., the server wants to contribute a higher amount of traffic). The cap also needs to be adjusted if a new upstream neighbors appears or an existing neighbor stops transmitting. If the cap assigned to an upstream neighbor is too high, the server may still experience overload. However, if the cap is too low, the upstream neighbors will reject requests even though they could be processed by the server. Thus, rate-based overload control is likely to work well only if the number of upstream servers is small and constant. 3.4.2. Loss-based Overload Control A loss percentage enables a SIP server to ask an upstream neighbor to reduce the number of requests it would normally forward to this server by a percentage X. For example, a SIP server can ask an upstream neighbor to reduce the number of requests this neighbor would normally send by 10%. The upstream neighbor then redirects or rejects X percent of the traffic that is destined for this server. The loss percentage is determined by an overload control algorithm, e.g., based on current system load. An algorithm for the sending entity to implement a loss percentage is to draw a random number between 1 and 100 for each request to be forwarded. The request is not forwarded to the server if the random number is less than or equal to X. An advantage of loss-based overload control is that, the receiving entity does not need to track the request rate it receives from each upstream neighbor. It is sufficient to monitor the overall system Hilt, et al. Expires April 28, 2008 [Page 12] Internet-Draft Overload Control October 2007 utilization. To reduce load, a server can ask its upstream neighbors to lower the traffic forwarded by a certain percentage. The server calculates this percentage by combining the loss percentage that is currently in use (i.e., the loss percentage the upstream neighbors are currently using when forwarding traffic), the current system utilization and the desired system utilization. For example, if the server load approaches 90% and the current loss percentage is set to a 50% traffic reduction, then the server can decide to increase the loss percentage to 55% in order to get to a system utilization of 80%. Similarly, the server can lower the loss percentage if permitted by the system utilization. This requires that system utilization can be accurately measured and that these measurements are reasonably stable. Loss-based overload control achieves fairness among incoming requests if all upstream neighbors are throttled by the same percentage. In this case, each request destined for an overloaded server has the same chance of being rejected by overload control. The main drawback of percentage throttling is that the throttle percentage needs to be adjusted to the current number of requests received by the server. This is in particular important if the number of requests received fluctuates quickly. For example, if a SIP server sets a throttle value of 10% at time t1 and the number of requests increases by 20% between time t1 and t2 (t1 200 Hilt, et al. Expires April 28, 2008 [Page 26] Internet-Draft Overload Control October 2007 6.6. Subscriber generation of SUBSCRIBE requests The subscriber follows the general rules for generating SUBSCRIBE requests defined in RFC 3265 [4]. 6.7. Notifier processing of SUBSCRIBE requests It is RECOMMENDED that a notifier provides overload control status information to all subscribers and that the notifier accepts all subscriptions to this event package. By denying a subscription to overload control, a notifier would disable overload control to this subscriber. Since this subscriber would not know the current overload status of the notifier, it would not reduce the traffic forwarded when the notifier enters an overload condition. Thus, denying a subscription to this event package can leave the notifier vulnerable to SIP overload. A notifier MAY authenticate and authorize subscriptions to this event package. This is useful if the notifier wants to provide extended overload status information to certain subscribers. For example, a notifier can provide detailed resource usage information to authenticated subscribers and only provide the current throttle status to all other subscribers. The details of the authorization policy are at the discretion of the administrator. 6.8. Notifier generation of NOTIFY requests A notifier sends a notification in response to SUBSCRIBE requests as defined in RFC 3265 [4]. In addition, a notifier MAY send a notification at any time during the subscription. Typically, the notifier will send a notification every time the overload control status has changed. For example, the notifier can create a notify every time the overload control value (e.g., the rate limit) changes. Overload status information is expressed in the format negotiated for the NOTIFY body (e.g., "application/overload-info+xml"). The overload status in a NOTIFY body MUST be complete. Notifications that contain the deltas to previous overload status or a partial overload status are not supported in this event package. It is RECOMMENDED that the notifier returns an initial NOTIFY that contains at least the current overload control value immediately after receiving a SUBSCRIBE request. It is RECOMMENDED that the notifier returns such an initial NOTIFY even if the notifier is still waiting for an authorization decision. Once the subscription is authorized, the notifier MAY send another notification that then contains all information the subscriber is authorized to receive. It is RECOMMENDED that the notifier accepts a subscription and creates a Hilt, et al. Expires April 28, 2008 [Page 27] Internet-Draft Overload Control October 2007 NOTIFY with at least the current overload control value even if the subscriber is not authorized to receive more information. The timely delivery of overload control notifications is important for overload control. It is therefore RECOMMENDED that NOTIFY messages for this event package are sent with highest priority. I.e., the transmission of NOTIFY messages for this event package ought not to be delayed by other tasks. 6.9. Subscriber processing of NOTIFY requests A subscriber MUST use the overload control state contained in a NOTIFY body and apply this state to all subsequent SIP messages it is intending to send to the respective SIP server. The subscriber MUST NOT forward a higher number of SIP messages to the server than allowed by the current overload control state. Details of how to apply overload control are discussed in Section 3.4 A subscriber MUST use the overload state it has received for a SIP server until the subscriber receives another NOTIFY with an updated state or until the subscription is terminated. The subscriber SHOULD stop using the reported overload state once the subscription is terminated. It is RECOMMENDED that the subscriber processes incoming NOTIFY messages for this event package with highest priority. I.e., NOTIFY messages for this event package ought to be processed before other messages are processed. This is to ensure that a subscriber can react quickly to changes in the overload control status even if the subscriber is currently receiving a high volume of messages. 6.10. Handling of forked requests This event package allows the creation of only one dialog as a result of an initial SUBSCRIBE request. The techniques to achieve this behavior are described in [4]. 6.11. Rate of notifications Keeping the rate of notifications low is important for an overload control mechanism to avoid creating additional traffic in an overload condition. However, it is also important that an overload control algorithm can quickly adjust the overload control value as needed. Ideally, the overload control algorithm would generate a stable control value that rarely needs to be adjusted. The notifier SHOULD NOT generate NOTIFY messages at a rate faster once every 1 second for notifications that are triggered by a change Hilt, et al. Expires April 28, 2008 [Page 28] Internet-Draft Overload Control October 2007 in the control value. The notifier SHOULD NOT generate a NOTIFY message at a rate faster than once every 5 seconds for all other notifications (i.e., for any additional information included in the subscription). 6.12. State Agents State agents play no role in this package. 6.13. Examples The following message flow illustrates how proxy A can subscribe to overload control status of proxy B. The flow assumes that proxy A does not have an active subscription to the overload control status of proxy B and has received an INVITE request it needs to forward to B. Proxy A Proxy B | | |(1) SUBSCRIBE | |------------------>| |(2) 200 OK | |<------------------| |(3) NOTIFY | |<------------------| |(4) 200 OK | |------------------>| |(5) INVITE | |------------------>| |(6) 200 OK | |<------------------| |(7) ACK | |------------------>| | | Message Details TBD. 7. 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 Hilt, et al. Expires April 28, 2008 [Page 29] Internet-Draft Overload Control October 2007 sending traffic to the victim. Thus, the victim is subject to a denial-of-service attack. An attacker can create forged overload status reports by inserting itself into the communication between the victim and its upstream neighbors. The attacker would need to add status reports 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 status reports have 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 status value through a proxy that does not support this extension. Since this proxy does not remove the overload status information, 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 status information otherwise. The attack also does not work if there is a stateful proxy between the attacker and the victim and only 100 (Trying) responses are used to convey the 'Overload-Control' header. 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. OPEN ISSUE: the solution to this problem depends on the overload control algorithm. For a fixed message rate 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. 8. IANA Considerations [TBD.] Appendix A. Acknowledgements Many thanks to Rich Terpstra and Jonathan Rosenberg for their Hilt, et al. Expires April 28, 2008 [Page 30] Internet-Draft Overload Control October 2007 contributions to this specification. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [5] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006. [6] Hilt, V. and I. Widjaja, "Essential Correction to the Session Initiation Protocol (SIP) 503 (Service Unavailable) Response", draft-hilt-sip-correction-503-01 (work in progress). 9.2. Informative References [7] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", draft-rosenberg-sipping-overload-reqs-02 (work in progress), October 2006. [8] Bormann, C., Liu, Z., Price, R., and G. Camarillo, "Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)", draft-ietf-rohc-sigcomp-sip-08 (work in progress), September 2007. [9] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling using Internet Multimedia", draft-ietf-ecrit-framework-03 (work in progress), September 2007. Hilt, et al. Expires April 28, 2008 [Page 31] Internet-Draft Overload Control October 2007 Authors' Addresses Volker Hilt Bell Labs/Alcatel-Lucent 791 Holmdel-Keyport Rd Holmdel, NJ 07733 USA Email: volkerh@bell-labs.com Indra Widjaja Bell Labs/Alcatel-Lucent 600-700 Mountain Avenue Murray Hill, NJ 07974 USA Email: iwidjaja@alcatel-lucent.com Daryl Malas Level 3 Communications 1025 Eldorado Blvd. Broomfield, CO USA Email: daryl.malas@level3.com Henning Schulzrinne Columbia University/Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Phone: +1 212 939 7004 Email: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu Hilt, et al. Expires April 28, 2008 [Page 32] Internet-Draft Overload Control October 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hilt, et al. Expires April 28, 2008 [Page 33]