SIPPING Working Group V. Hilt
Internet-Draft I. Widjaja
Intended status: Standards Track Bell Labs/Alcatel-Lucent
Expires: January 14, 2009 H. Schulzrinne
Columbia University
July 13, 2008
Session Initiation Protocol (SIP) Overload Control
draft-hilt-sipping-overload-05
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 January 14, 2009.
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.
Hilt, et al. Expires January 14, 2009 [Page 1]
Internet-Draft Overload Control July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design Considerations . . . . . . . . . . . . . . . . . . . . 4
3.1. SIP Mechanism . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. SIP Response Header Field . . . . . . . . . . . . . . 4
3.1.2. SIP Event Package . . . . . . . . . . . . . . . . . . 5
3.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 6
3.3. Load Status . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Responding to an Overload Indication . . . . . . . . . . . 7
3.5. Message Prioritization . . . . . . . . . . . . . . . . . . 7
4. Via Header Parameters for Overload Control . . . . . . . . . . 7
4.1. The 'oc_accept' Parameter . . . . . . . . . . . . . . . . 7
4.2. Creating the 'oc' Parameter . . . . . . . . . . . . . . . 8
4.3. Determining the 'oc' Parameter Value . . . . . . . . . . . 9
4.4. Processing the 'oc' Parameter . . . . . . . . . . . . . . 10
4.5. Using the 'oc' Parameter Value . . . . . . . . . . . . . . 10
4.6. Rejecting Requests . . . . . . . . . . . . . . . . . . . . 11
4.7. Self-Limiting . . . . . . . . . . . . . . . . . . . . . . 11
4.8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Appendix B. 'Overload-Control' Event Package . . . . . . . . . . 14
B.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 14
B.2. Event Package Parameters . . . . . . . . . . . . . . . . . 14
B.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 14
B.4. Subscription Duration . . . . . . . . . . . . . . . . . . 15
B.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 15
B.6. Subscriber generation of SUBSCRIBE requests . . . . . . . 16
B.7. Notifier processing of SUBSCRIBE requests . . . . . . . . 16
B.8. Notifier generation of NOTIFY requests . . . . . . . . . . 16
B.9. Subscriber processing of NOTIFY requests . . . . . . . . . 17
B.10. Handling of forked requests . . . . . . . . . . . . . . . 17
B.11. Rate of notifications . . . . . . . . . . . . . . . . . . 17
B.12. State Agents . . . . . . . . . . . . . . . . . . . . . . . 18
B.13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Hilt, et al. Expires January 14, 2009 [Page 2]
Internet-Draft Overload Control July 2008
1. Introduction
As with any network element, a Session Initiation Protocol (SIP)
[RFC3261] 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
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 [RFC4412]. 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 [RFC3261]. 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
[I-D.rosenberg-sipping-overload-reqs].
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 [RFC2119].
Hilt, et al. Expires January 14, 2009 [Page 3]
Internet-Draft Overload Control July 2008
3. Design Considerations
General design considerations for SIP overload control are discussed
in [I-D.hilt-sipping-overload-design]. The following section
discusses additional design considerations for a SIP extension for
overload control.
3.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.
3.1.1. SIP Response Header Field
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
inform its upstream neighbors about the current overload status. A
detailed description of this header is provided in Section 4.
This approach has the following characteristics:
o 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.
o 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.
o 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 the set of current upstream or downstream
neighbors with which it should exchange overload feedback.
o 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.
o 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.
Hilt, et al. Expires January 14, 2009 [Page 4]
Internet-Draft Overload Control July 2008
3.1.2. SIP Event Package
Overload control information can also be conveyed from a receiver to
a sender using a new event package. This 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. A description of such an event package
is provided in Appendix B.
This approach has the following characteristics:
o Overload control information is conveyed outside of the SIP
signaling flow and can be decoupled from SIP signaling. For
example, a separate overload control manager can be responsible
for monitoring the load on all servers in a server farm and
provide overload control feedback to all SIP servers that have set
up subscriptions to this controller.
o 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.
o 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.
o 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.
o A SIP server can limit the set of senders that can receive
overload control information by authenticating subscriptions to
this event package.
o This approach requires each proxy to implement a UAS/UAC to manage
the subscriptions.
Hilt, et al. Expires January 14, 2009 [Page 5]
Internet-Draft Overload Control July 2008
OPEN ISSUE: We need to decide about one SIP mechanism for
conveying overload control information. Section 4 and Appendix B
provide details for the header and the event package alternative.
3.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 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.
3.3. Load Status
It may be useful for a SIP server to frequently report its current
load status to upstream neighbors. The load status indicates to
which degree the resources needed by a SIP server to process SIP
messages are utilized. An upstream neighbor can use load status to
balance load between alternative SIP servers and to find under-
utilized servers. Reporting load is not intended to replace
specialized load balancing mechanisms.
OPEN ISSUE: reporting load status seems useful but somewhat
orthogonal to overload control. Should this be a separate
mechanism?
Hilt, et al. Expires January 14, 2009 [Page 6]
Internet-Draft Overload Control July 2008
3.4. Responding to an Overload Indication
An element may receive overload control feedback indicating that it
needs to reduce the traffic it sends to its downstream neighbor. An
element 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 element can also buffer
requests in the hope that the overload condition will resolve quickly
and the requests still can be forwarded in time. Finally, it can
reject these requests.
3.5. Message Prioritization
Overload control can require a SIP server to prioritize messages and
select messages that need to be rejected or redirected. The
selection is largely a matter of local policy.
A SIP server SHOULD honor the Resource-Priority header field as
defined in RFC4412 [RFC4412] if it is present in a SIP request. The
Resource-Priority header field enables a proxy to identify high-
priority requests, such as emergency service requests, and preserve
them as much as possible during times of overload.
4. Via Header Parameters for Overload Control
This section defines new parameters for the SIP Via header for
overload control. These parameter provide a SIP mechanism for
conveying overload control information between SIP entities.
4.1. The 'oc_accept' Parameter
A SIP server that supports this specification MUST add an "oc_accept"
parameter to the Via headers it inserts into SIP requests. This
provides an indication to downstream neighbors that this server
supports overload control.
OPEN ISSUE: To throttle upstream neighbors in a fair way, it is
important that a SIP server can estimate the load each upstream
neighbor receives for this server before it is throttled. This
enables the server to throttle each upstream neighbor in the same
way and thus provides each request the same chance of succeeding.
In rate- and window-based overload control systems, a SIP server
does not know how many messages each upstream neighbor had
received for the server before throttling took place. A solution
to this problem is to allow servers to report the load received
for a downstream neighbor in the 'oc_accept' parameter.
Hilt, et al. Expires January 14, 2009 [Page 7]
Internet-Draft Overload Control July 2008
4.2. Creating the 'oc' Parameter
A SIP server can provide overload control feedback to its upstream
neighbors by adding the 'oc' parameter to the topmost Via header
field of a SIP response. The 'oc' parameter is a new Via header
parameter defined in this specification. When an 'oc' parameter is
added to a response, it MUST be inserted into the topmost Via header.
It MUST NOT be added to any other Via header in the response. The
topmost Via header is determined after the SIP server has removed its
own Via header. It is the Via header that was generated by the next
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 next SIP
server. A Via header parameter therefore provides hop-by-hop
semantics for overload control feedback even if the next hop neighbor
does not support this specification.
A SIP server SHOULD add an 'oc' parameter to those responses, that
contain an 'oc_accept' parameter in the topmost Via header. In this
case, the SIP server MUST remove the 'oc_accept' parameter from the
Via header and replace it with an 'oc' parameter.
The 'oc' parameter can be used in all response types, including
provisional, success and failure responses. A SIP server MAY
generally add the 'oc' parameter to all responses it is sending. A
SIP server MUST add an '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 insert the 'oc' parameter when the overload control
algorithm sets the 'oc' parameter to a value different from the
default value.
A SIP server that has added an '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. 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 without an 'oc' parameter
and MUST be ignored if it appears in a Via header without 'oc'
parameter.
A SIP server MAY forward the content of an 'oc' parameter it has
Hilt, et al. Expires January 14, 2009 [Page 8]
Internet-Draft Overload Control July 2008
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 could 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.
The 'oc' and 'oc_validity' 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 two SIP servers can exchange overload information. While adding
'oc' and 'oc_validity' parameters to requests may increase the
frequency with which overload information is exchanged in these
scenarios, this increase will rarely provide benefits and does not
justify the added overhead and complexity needed.
A SIP server MAY decide to add 'oc' and 'oc_validity' parameters only
to responses that are sent via a secured transport channel such as
TLS. The SIP server can use transport level authentication to
identify the SIP servers, to which responses with these parameters
are sent. This enables a SIP server to protect overload control
information and ensure that it is only visible to trusted parties.
Since overload control protects a SIP server from overload, it is
RECOMMENDED that a SIP server generally inserts 'oc' and
'oc_validity' parameters into responses to all SIP servers.
4.3. Determining the 'oc' Parameter Value
The value of the 'oc' parameter is determined by an overload control
algorithm (see [I-D.hilt-sipping-overload-design]). 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.
OPEN ISSUE: the semantics of the 'oc' parameter depends on the
overload control method used. It may contain a loss rate for
loss-based overload control, a target rate for rate-based overload
control or message confirmations and window-size for window-based
overload control. It might be possible to allow multiple
Hilt, et al. Expires January 14, 2009 [Page 9]
Internet-Draft Overload Control July 2008
mechanisms to co-exist (e.g., by defining different parameters for
the different feedback types). However, for interoperability
purposes it seems preferable to agree on one mechanism. Further
studies are needed to evaluate the different methods.
4.4. Processing the 'oc' Parameter
A SIP entity compliant to this specification SHOULD remove 'oc' and
'oc_validity' parameters in all Via headers of a response received,
except for the topmost Via header. This prevents 'oc'/'oc_validity'
parameters that were accidentally or maliciously inserted into Via
headers by a downstream SIP server from traveling upstream.
A SIP server maintains the 'oc' parameter values received along with
the address 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 server receives a response with an 'oc'
parameter from a SIP server, it overwrites the 'oc' value it has
currently stored for this server with the new value received. The
SIP server 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 'oc' Parameter Value
A SIP server compliant to this specification MUST honor 'oc'
parameter values it receives from downstream neighbors. The SIP
server MUST NOT forward more messages to a SIP server than allowed by
the current 'oc' parameter value from this server.
When forwarding a SIP request, a SIP entity uses the SIP procedures
to determine the next hop SIP server as, e.g., described in [RFC3261]
and [RFC3263]. After selecting the next hop server, the SIP server
MUST determine if it has an 'oc' parameter value for this server. If
it has a non-expired 'oc' parameter value, the SIP server MUST
determine if it can or cannot forward the current request within the
current conditions.
OPEN ISSUE: the specific mechanisms to throttle traffic depend on
the type of feedback conveyed in the 'oc' parameter value. It
needs to be defined depending on whether a loss-based, rate-based
or window-based feedback is used.
The treatment of SIP requests that cannot be forwarded to the
selected SIP Server is a matter of local policy. A SIP entity MAY
try to find an alternative target or it MAY reject the request (see
Section 4.6).
Hilt, et al. Expires January 14, 2009 [Page 10]
Internet-Draft Overload Control July 2008
4.6. Rejecting Requests
A SIP server that rejects a request because of overload MUST reject
this request with the 5xx response code defined for overload control
(e.g., 503 (Service Unavailable) or 507 (Server Overload)
[I-D.hilt-sip-correction-503]). This response code indicates that
the request did not succeed because the SIP servers processing the
request are under overload.
A SIP server that is under overload and has started to throttle
incoming traffic SHOULD use 5xx response to reject a fraction of
requests from upstream neighbors that do not include the 'oc_accept'
parameter in their Via headers. These neighbors do not support this
specification and will not respond to overload control feedback in
the 'oc' parameter. The fraction of requests rejected SHOULD be
equivalent to the fraction of requests the upstream server would
reject/redirect if it did support this specification. This is to
ensure that SIP servers, which do not support this specification,
don't receive an unfair advantage over those that do.
A SIP server that has reached overload (i.e., a load close to 100)
SHOULD start using 5xx responses in addition to using the 'oc'
parameter for all upstream neighbors. If the proxy has reached a
load close to 100, it needs to protect itself against overload.
Also, it is likely that upstream proxies have ignored overload
feedback and do not support this specification.
4.7. Self-Limiting
In some cases, a SIP server may not receive a response from a
downstream neighbor when sending a request. RFC3261 [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 these cases, a SIP server SHOULD stop sending requests to this
server. The SIP server SHOULD occasionally forward a single request
to probe if the downstream neighbor is alive. Once a SIP server has
successfully transmitted a request to the downstream neighbor, it can
resume normal transmission of requests. It should, of course, honor
an 'oc' parameters it may receive. This avoids that a SIP server,
which is unable to respond to incoming requests, is overloaded with
additional requests.
Hilt, et al. Expires January 14, 2009 [Page 11]
Internet-Draft Overload Control July 2008
OPEN ISSUE: waiting for a timeout to occur seems a long time
before starting to throttle back. It could make sense to throttle
back earlier if no response is received for requests transmitted.
4.8. Syntax
This section defines the syntax of three new Via header parameters:
'oc', 'oc_validity' and 'oc_accept'. These Via header parameters are
used to implement an overload control feedback loop between
neighboring SIP servers.
The 'oc' and 'oc_validity' parameters are only defined in the topmost
Via header of a response. They MUST NOT be used in the Via headers
of requests and MUST NOT be used in other Via headers of a response.
The 'oc' and 'oc_validity' parameters MUST be ignored if received
outside of the topmost Via header of a response. The 'oc_accept'
parameter MAY appear in all Via headers.
OPEN ISSUE: the syntax of the 'oc' Via header parameter depends on
the overload control method (i.e., loss-based, rate-based or
window-based) in use. The following syntax definition defines a
rate-based 'oc' header. This syntax needs to be adjusted if rate-
based or window-based overload control is used.
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_accept' Via header parameter indicates that the SIP server,
which has created this Via header, supports overload control.
oc-throttle = "oc" [EQUAL 0-100]
oc-validity = "oc_validity" [EQUAL delta-ms]
oc-accept = "oc_accept"
This extends the existing definition of the Via header field
parameters, so that its BNF now looks like:
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ oc-throttle / oc-validity
/ oc-accept / via-extension
Example:
Hilt, et al. Expires January 14, 2009 [Page 12]
Internet-Draft Overload Control July 2008
Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
;oc=20;oc_validity=500
5. 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.
OPEN ISSUE: 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.
Hilt, et al. Expires January 14, 2009 [Page 13]
Internet-Draft Overload Control July 2008
6. IANA Considerations
[TBD.]
Appendix A. Acknowledgements
Many thanks to Rich Terpstra, Daryl Malas, Jonathan Rosenberg and
Charles Shen for their contributions to this specification.
Appendix B. 'Overload-Control' Event Package
This section defines a new SIP event package for overload control.
This event package provides a SIP mechanism for conveying overload
control information between SIP entities.
The following sections provide the details for defining a SIP event
package as required by RFC 3265 [RFC3265].
B.1. Event Package Name
The name of this event package is "overload-control". This package
name is carried in the Event and Allow-Events header fields, as
defined in RFC 3265 [RFC3265].
B.2. Event Package Parameters
No package specific Event header field parameters are defined for
this event package.
B.3. SUBSCRIBE Bodies
A SUBSCRIBE request for overload control information MAY contain a
body. This body would serve the purpose of filtering the overload
control subscription. The definition of such a body is outside the
scope of this specification. For example, the body might provide a
threshold for reporting overload control information or it might
indicate that overload control information should be reported as a
loss-percentage or a request rate.
A SUBSCRIBE request for the overload control package MAY be sent
without a body. This implies that the default subscription filtering
policy as described in Appendix B.8 has been requested.
Hilt, et al. Expires January 14, 2009 [Page 14]
Internet-Draft Overload Control July 2008
B.4. Subscription Duration
A subscription to the overload control event package is usually
established when a SIP server first sends a request to another SIP
server and terminated when this server stops sending requests and
overload control is not needed any more.
The duration of a subscription is related to the time a signaling
relationship exists between two servers. In a static SIP server
configuration (e.g., two SIP servers are configured to exchange
messages in a service provider's network) this relationship can last
for days or weeks as long as both servers are running. In this
scenario, the subscription duration is largely irrelevant.
In a dynamic configuration (e.g., two SIP servers in different
domains) the duration of the signaling relationship can be in the
range of minutes or hours and might only last for the duration of a
single session. Since it is unknown a priori when the next SIP
request will be transmitted from the subscriber to the notifier,
subscriber and notifier MAY terminate a subscription to overload
control after a period of inactivity.
The duration of a subscription to the overload control event package
SHOULD be longer than the duration of a typical session. The default
subscription duration for this event package is set to two hours.
B.5. NOTIFY Bodies
In this event package, the body of a notification contains the
current overload status of the notifier.
All subscribers and notifiers MUST support the format application/
overload-info+xml. The SUBSCRIBE request MAY contain an Accept
header field. If no such header field is present, it has a default
value of application/overload-info+xml. If the header field is
present, it MUST include application/overload-info+xml, and MAY
include any other MIME type capable of representing overload status
information. As defined in RFC 3265 [RFC3265], the body of
notifications MUST be in one of the formats defined in the Accept
header of the SUBSCRIBE request or in the default format.
TBD: An document format for the above placeholder application/
overload-info+xml needs to be defined. The following document
snippet is an example for such a format:
<overload-control>
<rate-limit>200</rate-limit>
</overload-control>
Hilt, et al. Expires January 14, 2009 [Page 15]
Internet-Draft Overload Control July 2008
B.6. Subscriber generation of SUBSCRIBE requests
The subscriber follows the general rules for generating SUBSCRIBE
requests defined in RFC 3265 [RFC3265].
B.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.
B.8. Notifier generation of NOTIFY requests
A notifier sends a notification in response to SUBSCRIBE requests as
defined in RFC 3265 [RFC3265]. 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 January 14, 2009 [Page 16]
Internet-Draft Overload Control July 2008
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.
B.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.
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.
B.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 [RFC3265].
B.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
in the control value. The notifier SHOULD NOT generate a NOTIFY
Hilt, et al. Expires January 14, 2009 [Page 17]
Internet-Draft Overload Control July 2008
message at a rate faster than once every 5 seconds for all other
notifications (i.e., for any additional information included in the
subscription).
B.12. State Agents
State agents play no role in this package.
B.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. References
7.1. Normative References
[I-D.hilt-sip-correction-503]
Hilt, V. and I. Widjaja, "Essential Correction to the
Session Initiation Protocol (SIP) 503 (Service
Hilt, et al. Expires January 14, 2009 [Page 18]
Internet-Draft Overload Control July 2008
Unavailable) Response", draft-hilt-sip-correction-503-01
(work in progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] 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.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
7.2. Informative References
[I-D.hilt-sipping-overload-design]
Hilt (Ed.), V., "Design Considerations for Session
Initiation Protocol (SIP) Overload Control",
draft-hilt-sipping-overload-design-00 (work in progress).
[I-D.rosenberg-sipping-overload-reqs]
Rosenberg, J., "Requirements for Management of Overload in
the Session Initiation Protocol",
draft-rosenberg-sipping-overload-reqs-02 (work in
progress), October 2006.
Authors' Addresses
Volker Hilt
Bell Labs/Alcatel-Lucent
791 Holmdel-Keyport Rd
Holmdel, NJ 07733
USA
Email: volkerh@bell-labs.com
Hilt, et al. Expires January 14, 2009 [Page 19]
Internet-Draft Overload Control July 2008
Indra Widjaja
Bell Labs/Alcatel-Lucent
600-700 Mountain Avenue
Murray Hill, NJ 07974
USA
Email: iwidjaja@alcatel-lucent.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 January 14, 2009 [Page 20]
Internet-Draft Overload Control July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Hilt, et al. Expires January 14, 2009 [Page 21]