draft-ietf-sip-fork-loop-fix-07.txt   draft-ietf-sip-fork-loop-fix-08.txt 
Network Working Group R. Sparks, Ed. Network Working Group R. Sparks, Ed.
Internet-Draft Tekelec Internet-Draft Tekelec
Updates: 3261 (if approved) S. Lawrence Updates: 3261 (if approved) S. Lawrence
Intended status: Standards Track Bluesocket Inc. Intended status: Standards Track Nortel Networks, Inc.
Expires: January 4, 2009 A. Hawrylyshen Expires: May 1, 2009 A. Hawrylyshen
Ditech Networks Inc. Ditech Networks Inc.
B. Campen B. Campen
Tekelec Tekelec
July 3, 2008 October 28, 2008
Addressing an Amplification Vulnerability in Session Initiation Protocol Addressing an Amplification Vulnerability in Session Initiation Protocol
(SIP) Forking Proxies (SIP) Forking Proxies
draft-ietf-sip-fork-loop-fix-07 draft-ietf-sip-fork-loop-fix-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 4, 2009. This Internet-Draft will expire on May 1, 2009.
Abstract Abstract
This document normatively updates RFC 3261, the Session Initiation This document normatively updates RFC 3261, the Session Initiation
Protocol (SIP), to address a security vulnerability identified in SIP Protocol (SIP), to address a security vulnerability identified in SIP
proxy behavior. This vulnerability enables an attack against SIP proxy behavior. This vulnerability enables an attack against SIP
networks where a small number of legitimate, even authorized, SIP networks where a small number of legitimate, even authorized, SIP
requests can stimulate massive amounts of proxy-to-proxy traffic. requests can stimulate massive amounts of proxy-to-proxy traffic.
This document strengthens loop-detection requirements on SIP proxies This document strengthens loop-detection requirements on SIP proxies
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 5 3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 5
4. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . . . 9 4. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . . . 9
4.1. Strengthening the Requirement to Perform Loop-detection . 9 4.1. Strengthening the Requirement to Perform Loop-detection . 9
4.2. Correcting and Clarifying the RFC 3261 Loop-detection 4.2. Correcting and Clarifying the RFC 3261 Loop-detection
Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 9 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Update to section 16.6 . . . . . . . . . . . . . . . . 9 4.2.1. Update to section 16.6 . . . . . . . . . . . . . . . . 10
4.2.2. Update to Section 16.3 . . . . . . . . . . . . . . . . 10 4.2.2. Update to Section 16.3 . . . . . . . . . . . . . . . . 11
4.2.3. Impact of Loop-detection on Overall Network 4.2.3. Impact of Loop-detection on Overall Network
Performance . . . . . . . . . . . . . . . . . . . . . 11 Performance . . . . . . . . . . . . . . . . . . . . . 11
4.2.4. Note to Implementors . . . . . . . . . . . . . . . . . 11 4.2.4. Note to Implementors . . . . . . . . . . . . . . . . . 11
5. Max-Breadth . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Max-Breadth . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Formal Mechanism . . . . . . . . . . . . . . . . . . . . . 14 5.3. Formal Mechanism . . . . . . . . . . . . . . . . . . . . . 15
5.3.1. "Max-Breadth" Header . . . . . . . . . . . . . . . . . 14 5.3.1. "Max-Breadth" Header . . . . . . . . . . . . . . . . . 15
5.3.2. Terminology . . . . . . . . . . . . . . . . . . . . . 14 5.3.2. Terminology . . . . . . . . . . . . . . . . . . . . . 15
5.3.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 15 5.3.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 15
5.3.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 15 5.3.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 16
5.3.5. UAS behavior . . . . . . . . . . . . . . . . . . . . . 16 5.3.5. UAS behavior . . . . . . . . . . . . . . . . . . . . . 16
5.4. Implementor Notes . . . . . . . . . . . . . . . . . . . . 16 5.4. Implementor Notes . . . . . . . . . . . . . . . . . . . . 17
5.4.1. Treatment of CANCEL . . . . . . . . . . . . . . . . . 16 5.4.1. Treatment of CANCEL . . . . . . . . . . . . . . . . . 17
5.4.2. Reclamation of Max-Breadth on 2xx Responses . . . . . 16 5.4.2. Reclamation of Max-Breadth on 2xx Responses . . . . . 17
5.4.3. Max-Breadth and Automaton UAs . . . . . . . . . . . . 16 5.4.3. Max-Breadth and Automaton UAs . . . . . . . . . . . . 17
5.5. Parallel and Sequential Forking . . . . . . . . . . . . . 16 5.5. Parallel and Sequential Forking . . . . . . . . . . . . . 17
5.6. Max-Breadth Split Weight Selection . . . . . . . . . . . . 17 5.6. Max-Breadth Split Weight Selection . . . . . . . . . . . . 18
5.7. Max-Breadth's Effect on Forking-based Amplification 5.7. Max-Breadth's Effect on Forking-based Amplification
Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 17 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.8. Max-Breadh Header Field ABNF Definition . . . . . . . . . 17 5.8. Max-Breadth Header Field ABNF Definition . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. Max-Forwards Header Field . . . . . . . . . . . . . . . . 17 6.1. Max-Breadth Header Field . . . . . . . . . . . . . . . . . 18
6.2. 440 Max-Breadth Exceeded response . . . . . . . . . . . . 18 6.2. 440 Max-Breadth Exceeded response . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Alternate solutions that were considered and rejected . . 20
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 21
9.3. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 22
9.4. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 20 9.3. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 22
9.5. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 21 9.4. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 22
9.6. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 21 9.5. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.6. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Conventions and Definitions 1. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
2. Introduction 2. Introduction
Interoperability testing uncovered a vulnerability in the behavior of Interoperability testing uncovered a vulnerability in the behavior of
skipping to change at page 5, line 33 skipping to change at page 5, line 33
ensure it is not participating in a request loop. ensure it is not participating in a request loop.
This normative update alone is insufficient to protect against This normative update alone is insufficient to protect against
crafted variations of the attack described here involving multiple crafted variations of the attack described here involving multiple
AORs. To further address the vulnerability, this document defines AORs. To further address the vulnerability, this document defines
the Max-Breadth mechanism to limit the total number of concurrent the Max-Breadth mechanism to limit the total number of concurrent
branches caused by a forked SIP request. The mechanism only limits branches caused by a forked SIP request. The mechanism only limits
concurrency. It does not limit the total number of branches a concurrency. It does not limit the total number of branches a
request can traverse over its lifetime. request can traverse over its lifetime.
The mechanisms in this update will protect against variations of the
attack described here which use a small number of resources,
including most unintentional self-inflicted variations through
accidental misconfiguration. However, an attacker with access to a
sufficient number of distinct resources will still be able to
stimulate a very large number of messages. The number of concurrent
messages will be limited by the Max-Breadth mechanism, so the entire
set willbe spread out over a long period of time, giving operators
better opportunity to detect the attack and take corrective measures
outside the protocol. Future protocol work is needed to prevent this
form of the attack.
3. Vulnerability: Leveraging Forking to Flood a Network 3. Vulnerability: Leveraging Forking to Flood a Network
This section describes setting up an attack with a simplifying This section describes setting up an attack with a simplifying
assumption, that two accounts on each of two different RFC 3261 assumption, that two accounts on each of two different RFC 3261
compliant proxy/registrar servers that do not perform loop-detection compliant proxy/registrar servers that do not perform loop-detection
are available to an attacker. This assumption is not necessary for are available to an attacker. This assumption is not necessary for
the attack, but makes representing the scenario simpler. The same the attack, but makes representing the scenario simpler. The same
attack can be realized with a single account on a single server. attack can be realized with a single account on a single server.
Consider two proxy/registrar services, P1 and P2, and four Addresses Consider two proxy/registrar services, P1 and P2, and four Addresses
skipping to change at page 10, line 14 skipping to change at page 10, line 25
the proxy will compute its own branch parameter, which will be the proxy will compute its own branch parameter, which will be
globally unique for that branch, and will contain the requisite magic globally unique for that branch, and will contain the requisite magic
cookie. Note that following only the guidelines in Section 8.1.1.7 cookie. Note that following only the guidelines in Section 8.1.1.7
will result in a branch parameter that will be different for will result in a branch parameter that will be different for
different instances of a spiraled or looped request through a proxy. different instances of a spiraled or looped request through a proxy.
Proxies required to perform loop-detection by RFC XXXX (RFC-Editor: Proxies required to perform loop-detection by RFC XXXX (RFC-Editor:
replace XXXX with the RFC number of this document) have an additional replace XXXX with the RFC number of this document) have an additional
constraint on the value they place in the Via header field. Such constraint on the value they place in the Via header field. Such
proxies SHOULD create a branch value separable into two parts in any proxies SHOULD create a branch value separable into two parts in any
implementation dependent way. The first part MUST satisfy the implementation dependent way.
constraints of Section 8.1.1.7. The second part is used to perform
loop detection and distinguish loops from spirals. The remainder of this section's description assumes the existance of
these two parts. If a proxy chooses to employ some other mechanism,
it is the implementer's responsibility to verify that the detection
properties defined by the requirements placed on these two parts are
acheived.
The first part of the branch value MUST satisfy the constraints of
Section 8.1.1.7. The second part is used to perform loop detection
and distinguish loops from spirals.
This second part MUST vary with any field used by the location This second part MUST vary with any field used by the location
service logic in determining where to retarget or forward this service logic in determining where to retarget or forward this
request. This is necessary to distinguish looped requests from request. This is necessary to distinguish looped requests from
spirals by allowing the proxy to recognize if none of the values spirals by allowing the proxy to recognize if none of the values
affecting the processing of the request have changed. Hence, The affecting the processing of the request have changed. Hence, The
second part MUST depend at least on the received Request-URI and any second part MUST depend at least on the received Request-URI and any
Route header field values used when processing the received request. Route header field values used when processing the received request.
Implementers need to take care to include all fields used by the Implementers need to take care to include all fields used by the
location service logic in that particular implementation. location service logic in that particular implementation.
skipping to change at page 11, line 47 skipping to change at page 12, line 17
properties. An attacker who can control the inputs in order to properties. An attacker who can control the inputs in order to
produce a hash collision can attack the connection in a variety of produce a hash collision can attack the connection in a variety of
other ways. When forming the second part using a hash, other ways. When forming the second part using a hash,
implementations SHOULD include at least one field in the input to the implementations SHOULD include at least one field in the input to the
hash that varies between different transactions attempting to reach hash that varies between different transactions attempting to reach
the same destination to avoid repeated failure should the hash the same destination to avoid repeated failure should the hash
collide. The Call-ID and CSeq fields would be good inputs for this collide. The Call-ID and CSeq fields would be good inputs for this
purpose. purpose.
A common point of failure to interoperate at SIPit events has been A common point of failure to interoperate at SIPit events has been
due to parsers objecting to the contents of other's Via header field due to parsers objecting to the contents of other elements Via header
values when inspecting the Via stack for loops. Implementers need to field values when inspecting the Via stack for loops. Implementers
take care to avoid making assumptions about the format of another need to take care to avoid making assumptions about the format of
element's Via header field value beyond the basic constraints placed another element's Via header field value beyond the basic constraints
on that format by RFC 3261. In particular, parsing a header field placed on that format by RFC 3261. In particular, parsing a header
value with unknown parameter names, parameters with no values, field value with unknown parameter names, parameters with no values,
parameters values with and without quoted strings must not cause an or parameters values with or without quoted strings must not cause an
implementation to fail. implementation to fail.
Removing, obfuscating, or in any other way modifying the branch Removing, obfuscating, or in any other way modifying the branch
parameter values in Via header fields in a received request before parameter values in Via header fields in a received request before
forwarding it removes the ability for the node that placed that forwarding it removes the ability for the node that placed that
branch parameter into the message to perform loop-detection. If two branch parameter into the message to perform loop-detection. If two
elements in a loop modify branch parameters this way, a loop can elements in a loop modify branch parameters this way, a loop can
never be detected. never be detected.
5. Max-Breadth 5. Max-Breadth
skipping to change at page 15, line 26 skipping to change at page 16, line 19
SIP proxies MUST NOT allow the Outgoing Max-Breadth to exceed the SIP proxies MUST NOT allow the Outgoing Max-Breadth to exceed the
Incoming Max-Breadth in a given response context. Incoming Max-Breadth in a given response context.
If a SIP proxy determines a response context has insufficient If a SIP proxy determines a response context has insufficient
Incoming Max-Breadth to carry out a desired parallel fork, and the Incoming Max-Breadth to carry out a desired parallel fork, and the
proxy is unwilling/unable to compensate by forking serially or proxy is unwilling/unable to compensate by forking serially or
sending a redirect, that proxy MUST return a 440 (Max-Breadth sending a redirect, that proxy MUST return a 440 (Max-Breadth
Exceeded) response. Exceeded) response.
Notice that these requirements means a proxy receiving a request with Notice that these requirements mean a proxy receiving a request with
a Max-Breadth of 1 can only fork serially, but it is not required to a Max-Breadth of 1 can only fork serially, but it is not required to
fork at all - it can return a 440 instead. Thus, this mechanism is fork at all - it can return a 440 instead. Thus, this mechanism is
not a tool a user-agent can use to force all proxies in the path of a not a tool a user-agent can use to force all proxies in the path of a
request to fork serially. request to fork serially.
A SIP proxy MAY distribute Max-Breadth in an arbitrary fashion A SIP proxy MAY distribute Max-Breadth in an arbitrary fashion
between active branches. A proxy SHOULD NOT use a smaller amount of between active branches. A proxy SHOULD NOT use a smaller amount of
Max-Breadth than was present in the original request, unless the Max-Breadth than was present in the original request, unless the
Incoming Max-Breadth exceeded the proxy's maximum acceptable value. Incoming Max-Breadth exceeded the proxy's maximum acceptable value.
A proxy MUST NOT decrement Max-Breadth for each hop or otherwise use A proxy MUST NOT decrement Max-Breadth for each hop or otherwise use
skipping to change at page 17, line 33 skipping to change at page 18, line 28
Max-Breadth limits the total number of active branches spawned by a Max-Breadth limits the total number of active branches spawned by a
given request at any one time, while placing no constraint on the given request at any one time, while placing no constraint on the
distance (measured in hops) that the request can propagate. (ie, distance (measured in hops) that the request can propagate. (ie,
receiving a request with a Max-Breadth of 1 means that any forking receiving a request with a Max-Breadth of 1 means that any forking
must be sequential, not that forking is forbidden) must be sequential, not that forking is forbidden)
This limits the effectiveness of any amplification attack that This limits the effectiveness of any amplification attack that
leverages forking, because the amount of state/bandwidth needed to leverages forking, because the amount of state/bandwidth needed to
process the traffic at any given point in time is capped. process the traffic at any given point in time is capped.
5.8. Max-Breadh Header Field ABNF Definition 5.8. Max-Breadth Header Field ABNF Definition
This specification extends the grammar for the Session Initation This specification extends the grammar for the Session Initiation
Protocol by adding the following extension-header: Protocol by adding the following extension-header:
Max-Breadth = "Max-Breadth" HCOLON 1*DIGIT Max-Breadth = "Max-Breadth" HCOLON 1*DIGIT
6. IANA Considerations 6. IANA Considerations
This specification registers a new SIP header field and a new SIP This specification registers a new SIP header field and a new SIP
response according to the processes defined in [RFC3261]. response according to the processes defined in [RFC3261].
6.1. Max-Forwards Header Field 6.1. Max-Breadth Header Field
This information should appear in the header sub-registry under This information should appear in the header sub-registry under
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
RFC XXXX (this specification) RFC XXXX (this specification)
Header Field Name: Max-Breadth Header Field Name: Max-Breadth
Compact Form: none Compact Form: none
6.2. 440 Max-Breadth Exceeded response 6.2. 440 Max-Breadth Exceeded response
This information should appear in the response-code sub-registry This information should appear in the response-code sub-registry
under http://www.iana.org/assignments/sip-parameters. under http://www.iana.org/assignments/sip-parameters.
Response code: 440 Response code: 440
skipping to change at page 18, line 23 skipping to change at page 19, line 20
Response code: 440 Response code: 440
Default Reason Phrase: Max-Breadth Exceeded Default Reason Phrase: Max-Breadth Exceeded
7. Security Considerations 7. Security Considerations
This document is entirely about documenting and addressing a This document is entirely about documenting and addressing a
vulnerability in SIP proxies as defined by RFC 3261 that can lead to vulnerability in SIP proxies as defined by RFC 3261 that can lead to
an exponentially growing message exchange attack. an exponentially growing message exchange attack.
The Max-Breadth mechanism defined here does not decrease the
aggregate traffic caused by the forking-loop attack. It only serves
to spread the traffic caused by the attack over a longer period, by
limiting the number of concurrent branches that are being processed
at the same time. An attacker could pump multiple requests into a
network that uses the Max-Breadth mechanism and gradually build
traffic to unreasonable levels. Deployments should monitor carefully
and react to gradual increases in the number of concurrent
outstanding transactions related to a given resource to protect
against this possibility. Operators should anticipate being able to
temporarily disable any resources identified as being used in such an
attack. A rapid increase in outstanding concurrent transactions
system-wide may be an indication of the presence of this kind of
attack across many resources. Deployments in which it is feasible
for an attacker to obtain a very large number of resources are
particularly at risk. If detecting and intervening in each instance
of the attack is insufficient to reduce the load, overload may occur.
Implementers and operators are encouraged to follow the
recommendations being developed for handling overload conditions (see
[I-D.ietf-sipping-overload-reqs] and
[I-D.ietf-sipping-overload-design]).
Designers of protocol gateways should consider the implications of
this kind of attack carefully. As an example, if a message transits
from a SIP network into the PSTN and subsequently back into a SIP
network, and information about the history of the request on either
side of the protocol translation is lost, it becomes possible to
construct loops that neither Max-Forwards nor loop-detection can
protect against. This combined with forking amplification on the SIP
side of the loop will result in an attack as described in this
document that the mechanisms here will not abate, not even to the
point of limiting the number of concurrent messages in the attack.
These considerations are particularly important for designers of
gateways from SIP to SIP (as found in B2BUAs for example). Many
existing B2BUA implementations are under some pressure to hide as
much information about the two sides communicating with them as
possible. Implementers of such implementations may be tempted to
remove the data that might be used by the loop-detection, Max-
Forwards, or Max-Breadth mechanisms at other points in the network,
taking the responsibility for detecting loops (or forms of this
attack) on themselves. However, if two such implementations are
involved in the attack, neither will be able to detect it.
7.1. Alternate solutions that were considered and rejected
Alternative solutions that were discussed included Alternative solutions that were discussed included
Doing nothing - rely on suing the offender: While systems that have Doing nothing - rely on suing the offender: While systems that have
accounts have logs that can be mined to locate abusers, it isn't accounts have logs that can be mined to locate abusers, it isn't
clear that this provides a credible deterrent or defense against clear that this provides a credible deterrent or defense against
the attack described in this document. Systems that don't the attack described in this document. Systems that don't
recognize the situation and take corrective/preventative action recognize the situation and take corrective/preventative action
are likely to experience failure of a magnitude that precludes are likely to experience failure of a magnitude that precludes
retrieval of the records documenting the setup of the attack. (In retrieval of the records documenting the setup of the attack. (In
one scenario, the registrations can occur in a radically different one scenario, the registrations can occur in a radically different
skipping to change at page 19, line 23 skipping to change at page 21, line 13
defined in [I-D.ietf-sip-outbound]. Mechanisms like this may be defined in [I-D.ietf-sip-outbound]. Mechanisms like this may be
considered again in the future, but are currently insufficiently considered again in the future, but are currently insufficiently
developed to address the present threat. developed to address the present threat.
Deprecate forking: This attack does not exist in a system that Deprecate forking: This attack does not exist in a system that
relies entirely on redirection and initiation of new requests by relies entirely on redirection and initiation of new requests by
the original endpoint. Removing such a large architectural the original endpoint. Removing such a large architectural
component from the system at this time was deemed a too extreme component from the system at this time was deemed a too extreme
solution. solution.
The Max-Breadth mechanism defined here does not decrease the Don't reclaim breadth An alternative design of the Max-Breadth
aggregate traffic caused by the forking-loop attack. It only serves
to spread the traffic caused by the attack over a longer period, by
limiting the number of concurrent branches that are being processed
at the same time. An attacker could pump multple requests into a
network that uses the Max-Breadth mechanism and gradually build
traffic to unreasonable levels. Deployments should monitor carefully
and react to gradual increases in the number of concurrent
outstanding transactions related to a given resource to protect
against this possibility. An alternative design of the Max-Breadth
mechanism that was considered and rejected was to not allow the mechanism that was considered and rejected was to not allow the
breadth from completed branches to be reused Section 5.3.3.1. Under breadth from completed branches to be reused Section 5.3.3.1.
this alternative, an introduced request would cause at most the Under this alternative, an introduced request would cause at most
initial value of Max-Breadth transactions to be generated in the the initial value of Max-Breadth transactions to be generated in
network. While that approach limits any variant of the amplification the network. While that approach limits any variant of the
vulnerability described here to a constant multipler, it would amplification vulnerability described here to a constant
dramatically change the potential reach of requests and there is multiplier, it would dramatically change the potential reach of
beleif that it would break existing deployments. requests and there is belief that it would break existing
deployments.
8. Acknowledgments 8. Acknowledgments
Thanks go to the implementors that subjected their code to this Thanks go to the implementors that subjected their code to this
scenario and helped analyze the results at SIPit 17. Eric Rescorla scenario and helped analyze the results at SIPit 17. Eric Rescorla
provided guidance and text for the hash recommendation note. provided guidance and text for the hash recommendation note.
9. Change Log 9. Change Log
RFC Editor - Remove this section before publication RFC Editor - Remove this section before publication
skipping to change at page 22, line 17 skipping to change at page 23, line 51
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
10.2. Informative References 10.2. Informative References
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-15 (work in progress), June 2008. draft-ietf-sip-outbound-15 (work in progress), June 2008.
[I-D.ietf-sipping-overload-design]
Hilt, V., "Design Considerations for Session Initiation
Protocol (SIP) Overload Control",
draft-ietf-sipping-overload-design-00 (work in progress),
October 2008.
[I-D.ietf-sipping-overload-reqs]
Rosenberg, J., "Requirements for Management of Overload in
the Session Initiation Protocol",
draft-ietf-sipping-overload-reqs-05 (work in progress),
July 2008.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
Authors' Addresses Authors' Addresses
Robert Sparks (editor) Robert Sparks (editor)
Tekelec Tekelec
17210 Campbell Road 17210 Campbell Road
Suite 250 Suite 250
Dallas, Texas 75254-4203 Dallas, Texas 75254-4203
USA USA
Email: RjS@nostrum.com Email: RjS@nostrum.com
Scott Lawrence Scott Lawrence
Bluesocket Inc. Nortel Networks, Inc.
10 North Ave. 600 Technology Park
Burlington, MA 01803 Billerica, MA 01821
USA USA
Phone: +1 781 229 0533 Phone: +1 978 248 5508
Email: slawrence@bluesocket.com Email: scott.lawrence@nortel.com
Alan Hawrylyshen Alan Hawrylyshen
Ditech Networks Inc. Ditech Networks Inc.
823 E. Middlefield Rd 823 E. Middlefield Rd
Mountain View, CA 94043 Mountain View, CA 94043
Canada Canada
Phone: +1 650 623 1300 Phone: +1 650 623 1300
Email: alan.ietf@polyphase.ca Email: alan.ietf@polyphase.ca
Byron Campen Byron Campen
 End of changes. 23 change blocks. 
72 lines changed or deleted 144 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/