draft-ietf-sip-fork-loop-fix-08.txt   rfc5393.txt 
Network Working Group R. Sparks, Ed. Network Working Group R. Sparks, Ed.
Internet-Draft Tekelec Request for Comments: 5393 Tekelec
Updates: 3261 (if approved) S. Lawrence Updates: 3261 S. Lawrence
Intended status: Standards Track Nortel Networks, Inc. Category: Standards Track Nortel Networks, Inc.
Expires: May 1, 2009 A. Hawrylyshen A. Hawrylyshen
Ditech Networks Inc. Ditech Networks Inc.
B. Campen B. Campen
Tekelec Tekelec
October 28, 2008 December 2008
Addressing an Amplification Vulnerability in Session Initiation Protocol
(SIP) Forking Proxies
draft-ietf-sip-fork-loop-fix-08
Status of this Memo
By submitting this Internet-Draft, each author represents that any Addressing an Amplification Vulnerability
applicable patent or other IPR claims of which he or she is aware in Session Initiation Protocol (SIP) Forking Proxies
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 Status of This Memo
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 This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (c) 2008 IETF Trust and the persons identified as the
http://www.ietf.org/shadow.html. document authors. All rights reserved.
This Internet-Draft will expire on May 1, 2009. This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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
when they fork requests (that is, forward a request to more than one when they fork requests (that is, forward a request to more than one
destination). It also corrects and clarifies the description of the destination). It also corrects and clarifies the description of the
loop-detection algorithm such proxies are required to implement. loop-detection algorithm such proxies are required to implement.
Additionally, this document defines a Max-Breadth mechanism for Additionally, this document defines a Max-Breadth mechanism for
limiting the number of concurrent branches pursued for any given limiting the number of concurrent branches pursued for any given
request. request.
Table of Contents Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Definitions .....................................3
3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 5 3. Vulnerability: Leveraging Forking to Flood a Network ............3
4. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . . . 9 4. Updates to RFC 3261 .............................................7
4.1. Strengthening the Requirement to Perform Loop-detection . 9 4.1. Strengthening the Requirement to Perform Loop Detection ....7
4.2. Correcting and Clarifying the RFC 3261 Loop-detection 4.2. Correcting and Clarifying the RFC 3261
Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 9 Loop-Detection Algorithm ...................................7
4.2.1. Update to section 16.6 . . . . . . . . . . . . . . . . 10 4.2.1. Update to Section 16.6 ..............................7
4.2.2. Update to Section 16.3 . . . . . . . . . . . . . . . . 11 4.2.2. Update to Section 16.3 ..............................8
4.2.3. Impact of Loop-detection on Overall Network 4.2.3. Impact of Loop Detection on Overall Network
Performance . . . . . . . . . . . . . . . . . . . . . 11 Performance .........................................9
4.2.4. Note to Implementors . . . . . . . . . . . . . . . . . 11 4.2.4. Note to Implementers ................................9
5. Max-Breadth . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Max-Breadth ....................................................10
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Overview ..................................................10
5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Examples ..................................................11
5.3. Formal Mechanism . . . . . . . . . . . . . . . . . . . . . 15 5.3. Formal Mechanism ..........................................12
5.3.1. "Max-Breadth" Header . . . . . . . . . . . . . . . . . 15 5.3.1. Max-Breadth Header Field ...........................12
5.3.2. Terminology . . . . . . . . . . . . . . . . . . . . . 15 5.3.2. Terminology ........................................13
5.3.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 15 5.3.3. Proxy Behavior .....................................13
5.3.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 16 5.3.3.1. Reusing Max-Breadth .......................14
5.3.5. UAS behavior . . . . . . . . . . . . . . . . . . . . . 16 5.3.4. UAC Behavior .......................................14
5.4. Implementor Notes . . . . . . . . . . . . . . . . . . . . 17 5.3.5. UAS Behavior .......................................14
5.4.1. Treatment of CANCEL . . . . . . . . . . . . . . . . . 17 5.4. Implementer Notes .........................................14
5.4.2. Reclamation of Max-Breadth on 2xx Responses . . . . . 17 5.4.1. Treatment of CANCEL ................................14
5.4.3. Max-Breadth and Automaton UAs . . . . . . . . . . . . 17 5.4.2. Reclamation of Max-Breadth on 2xx Responses ........14
5.5. Parallel and Sequential Forking . . . . . . . . . . . . . 17 5.4.3. Max-Breadth and Automaton UAs ......................14
5.6. Max-Breadth Split Weight Selection . . . . . . . . . . . . 18 5.5. Parallel and Sequential Forking ...........................15
5.7. Max-Breadth's Effect on Forking-based Amplification 5.6. Max-Breadth Split Weight Selection ........................15
Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.7. Max-Breadth's Effect on Forking-Based
5.8. Max-Breadth Header Field ABNF Definition . . . . . . . . . 18 Amplification Attacks .....................................15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5.8. Max-Breadth Header Field ABNF Definition ..................16
6.1. Max-Breadth Header Field . . . . . . . . . . . . . . . . . 18 6. IANA Considerations ............................................16
6.2. 440 Max-Breadth Exceeded response . . . . . . . . . . . . 19 6.1. Max-Breadth Header Field ..................................16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6.2. 440 Max-Breadth Exceeded Response .........................16
7.1. Alternate solutions that were considered and rejected . . 20 7. Security Considerations ........................................16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Alternate Solutions That Were Considered and Rejected .....17
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgments ................................................19
9.1. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References .....................................................19
9.2. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References ......................................19
9.3. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References ....................................19
9.4. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 22
9.5. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 22
9.6. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Conventions and Definitions
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].
2. Introduction 1. Introduction
Interoperability testing uncovered a vulnerability in the behavior of Interoperability testing uncovered a vulnerability in the behavior of
forking SIP proxies as defined in [RFC3261]. This vulnerability can forking SIP proxies as defined in [RFC3261]. This vulnerability can
be leveraged to cause a small number of valid SIP requests to be leveraged to cause a small number of valid SIP requests to
generate an extremely large number of proxy-to-proxy messages. A generate an extremely large number of proxy-to-proxy messages. A
version of this attack demonstrates fewer than ten messages version of this attack demonstrates fewer than ten messages
stimulating potentially 2^71 messages. stimulating potentially 2^71 messages.
This document specifies normative changes to the SIP protocol to This document specifies normative changes to the SIP protocol to
address this vulnerability. According to this update, when a SIP address this vulnerability. According to this update, when a SIP
proxy forks a request to more than one destination, it is required to proxy forks a request to more than one destination, it is required to
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 Addresses of Record (AORs). To further address the vulnerability,
the Max-Breadth mechanism to limit the total number of concurrent this document defines the Max-Breadth mechanism to limit the total
branches caused by a forked SIP request. The mechanism only limits number of concurrent branches caused by a forked SIP request. The
concurrency. It does not limit the total number of branches a mechanism only limits concurrency. It does not limit the total
request can traverse over its lifetime. number of branches a request can traverse over its lifetime.
The mechanisms in this update will protect against variations of the The mechanisms in this update will protect against variations of the
attack described here which use a small number of resources, attack described here that use a small number of resources, including
including most unintentional self-inflicted variations through most unintentional self-inflicted variations that occur through
accidental misconfiguration. However, an attacker with access to a accidental misconfiguration. However, an attacker with access to a
sufficient number of distinct resources will still be able to sufficient number of distinct resources will still be able to
stimulate a very large number of messages. The number of concurrent stimulate a very large number of messages. The number of concurrent
messages will be limited by the Max-Breadth mechanism, so the entire messages will be limited by the Max-Breadth mechanism, so the entire
set willbe spread out over a long period of time, giving operators set willbe spread out over a long period of time, giving operators
better opportunity to detect the attack and take corrective measures better opportunity to detect the attack and take corrective measures
outside the protocol. Future protocol work is needed to prevent this outside the protocol. Future protocol work is needed to prevent this
form of the attack. form of the attack.
2. Conventions and Definitions
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].
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
of Record, a@P1, b@P1, a@P2, and b@P2. Using normal REGISTER of Record, a@P1, b@P1, a@P2, and b@P2. Using normal REGISTER
requests, establish bindings to these AoRs as follows (non-essential requests, establish bindings to these AORs as follows (non-essential
details elided): details elided):
REGISTER sip:P1 SIP/2.0 REGISTER sip:P1 SIP/2.0
To: <sip:a@P1> To: <sip:a@P1>
Contact: <sip:a@P2>, <sip:b@P2> Contact: <sip:a@P2>, <sip:b@P2>
REGISTER sip:P1 SIP/2.0 REGISTER sip:P1 SIP/2.0
To: <sip:b@P1> To: <sip:b@P1>
Contact: <sip:a@P2>, <sip:b@P2> Contact: <sip:a@P2>, <sip:b@P2>
REGISTER sip:P2 SIP/2.0 REGISTER sip:P2 SIP/2.0
To: <sip:a@P2> To: <sip:a@P2>
Contact: <sip:a@P1>, <sip:b@P1> Contact: <sip:a@P1>, <sip:b@P1>
REGISTER sip:P2 SIP/2.0 REGISTER sip:P2 SIP/2.0
To: <sip:b@P2> To: <sip:b@P2>
Contact: <sip:a@P1>, <sip:b@P1> Contact: <sip:a@P1>, <sip:b@P1>
With these bindings in place, introduce an INVITE to any of the four With these bindings in place, introduce an INVITE request to any of
AoRs, say a@P1. This request will fork to two requests handled by the four AORs, say a@P1. This request will fork to two requests
P2, which will fork to four requests handled by P1, which will fork handled by P2, which will fork to four requests handled by P1, which
to eight messages handled by P2, and so on. This message flow is will fork to eight messages handled by P2, and so on. This message
represented in Figure 1. flow is represented in Figure 1.
| |
a@P1 a@P1
/ \ / \
/ \ / \
/ \ / \
/ \ / \
a@P2 b@P2 a@P2 b@P2
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
a@P1 b@P1 a@P1 b@P1 a@P1 b@P1 a@P1 b@P1
/ \ / \ / \ / \ / \ / \ / \ / \
a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2
/\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\
. .
. .
. .
Figure 1: Attack request propagation Figure 1: Attack Request Propagation
Requests will continue to propagate down this tree until Max-Forwards Requests will continue to propagate down this tree until Max-Forwards
reaches zero. If the endpoint and two proxies involved follow RFC reaches zero. If the endpoint and two proxies involved follow RFC
3261 recommendations, the tree will be 70 rows deep, representing 3261 recommendations, the tree will be 70 rows deep, representing
2^71-1 requests. The actual number of messages may be much larger if 2^71-1 requests. The actual number of messages may be much larger if
the time to process the entire tree worth of requests is longer than the time to process the entire tree's worth of requests is longer
Timer C at either proxy. In this case, a storm of 408s, and/or a than Timer C at either proxy. In this case, a storm of 408 responses
storm of CANCELs will also be propagating through the tree along with and/or a storm of CANCEL requests will also be propagating through
the INVITEs. Remember that there are only two proxies involved in the tree along with the INVITE requests. Remember that there are
this scenario - each having to hold the state for all the only two proxies involved in this scenario - each having to hold the
transactions it sees (at least 2^70 simultaneously active state for all the transactions it sees (at least 2^70 simultaneously
transactions near the end of the scenario). active transactions near the end of the scenario).
The attack can be simplified to one account at one server if the The attack can be simplified to one account at one server if the
service can be convinced that contacts with varying attributes service can be convinced that contacts with varying attributes
(parameters, schemes, embedded headers) are sufficiently distinct, (parameters, schemes, embedded headers) are sufficiently distinct,
and these parameters are not used as part of AOR comparisons when and these parameters are not used as part of AOR comparisons when
forwarding a new request. Since RFC 3261 mandates that all URI forwarding a new request. Since RFC 3261 mandates that all URI
parameters must be removed from a URI before looking it up in a parameters must be removed from a URI before looking it up in a
location service and that the URIs from the Contact header are location service and that the URIs from the Contact header field are
compared using URI equality, the following registration should be compared using URI equality, the following registration should be
sufficient to set this attack up using a single REGISTER request to a sufficient to set up this attack using a single REGISTER request to a
single account: single account:
REGISTER sip:P1 SIP/2.0 REGISTER sip:P1 SIP/2.0
To: <sip:a@P1> To: <sip:a@P1>
Contact: <sip:a@P1;unknown-param=whack>,<sip:a@P1;unknown-param=thud> Contact: <sip:a@P1;unknown-param=whack>,<sip:a@P1;unknown-param=thud>
This attack was realized in practice during one of the SIP This attack was realized in practice during one of the SIP
Interoperability Test (SIPit) sessions. The scenario was extended to Interoperability Test (SIPit) sessions. The scenario was extended to
include more than two proxies, and the participating proxies all include more than two proxies, and the participating proxies all
limited Max-Forwards to be no larger than 20. After a handful of limited Max-Forwards to be no larger than 20. After a handful of
messages to construct the attack, the participating proxies began messages to construct the attack, the participating proxies began
bombarding each other. Extrapolating from the several hours the bombarding each other. Extrapolating from the several hours the
experiment was allowed to run, the scenario would have completed in experiment was allowed to run, the scenario would have completed in
just under 10 days. Had the proxies used the RFC 3261 recommended just under 10 days. Had the proxies used the RFC 3261 recommended
Max-Forwards value of 70, and assuming they performed linearly as the Max-Forwards value of 70, and assuming they performed linearly as the
state they held increases, it would have taken 3 trillion years to state they held increased, it would have taken 3 trillion years to
complete the processing of the single INVITE that initiated the complete the processing of the single INVITE request that initiated
attack. It is interesting to note that a few proxies rebooted during the attack. It is interesting to note that a few proxies rebooted
the scenario, and rejoined in the attack when they restarted (as long during the scenario and rejoined in the attack when they restarted
as they maintained registration state across reboots). This points (as long as they maintained registration state across reboots). This
out that if this attack were launched on the Internet at large, it points out that if this attack were launched on the Internet at
might require coordination among all the affected elements to stop large, it might require coordination among all the affected elements
it. to stop it.
Loop-detection, as specified in this document, at any of the proxies Loop detection, as specified in this document, at any of the proxies
in the scenarios described so far would have stopped the attack in the scenarios described so far would have stopped the attack
immediately. (If all the proxies involved implemented this loop- immediately. (If all the proxies involved implemented this loop
detection, the total number of stimulated messages in the first detection, the total number of stimulated messages in the first
scenario described is reduced to 14, and in the variation involving scenario described would be reduced to 14; in the variation involving
one server, the number of stimulated messages is reduced to 10.) one server, the number of stimulated messages would be reduced to
However, there is a variant of the attack that uses multiple AORs 10.) However, there is a variant of the attack that uses multiple
where loop-detection alone is insufficient protection. In this AORs where loop detection alone is insufficient protection. In this
variation, each participating AOR forks to all the other variation, each participating AOR forks to all the other
participating AORs. For small numbers of participating AORs (10 participating AORs. For small numbers of participating AORs (10, for
example), paths through the resulting tree will not loop until very example), paths through the resulting tree will not loop until very
large numbers of messages have been generated. Acquiring a large numbers of messages have been generated. Acquiring a
sufficient number of AORs to launch such an attack on networks sufficient number of AORs to launch such an attack on networks
currently available is quite feasible. currently available is quite feasible.
In this scenario, requests will often take many hops to complete a In this scenario, requests will often take many hops to complete a
loop, and there are a very large number of different loops that will loop, and there are a very large number of different loops that will
occur during the attack. In fact, if N is the number of occur during the attack. In fact, if N is the number of
participating AORs, and provided N is less than or equal to Max- participating AORs, and provided N is less than or equal to Max-
Forwards, the amount of traffic generated by the attack is greater Forwards, the amount of traffic generated by the attack is greater
than N!, even if all proxies involved are performing loop-detection. than N!, even if all proxies involved are performing loop detection.
Suppose we have a set of N AORs, all of which are set up to fork
to the entire set. For clarity, assume AOR 1 is where the attack
begins. Every permutation of the remaining N-1 AORs will play
out, defining (N-1)! distinct paths, without repeating any AOR.
Then, each of these paths will fork N ways one last time, and a
loop will be detected on each of these branches. These final
branches alone total N! requests ((N-1)! paths, with N forks at
the end of each path).
Forwarded Requests vs. Number of Participating AORs Suppose we have a set of N AORs, all of which are set up to fork to
the entire set. For clarity, assume AOR 1 is where the attack
begins. Every permutation of the remaining N-1 AORs will play out,
defining (N-1)! distinct paths, without repeating any AOR. Then,
each of these paths will fork N ways one last time, and a loop will
be detected on each of these branches. These final branches alone
total N! requests ((N-1)! paths, with N forks at the end of each
path).
___N____Requests_ ___N____Requests_
| 1 | 1 | | 1 | 1 |
| 2 | 4 | | 2 | 4 |
| 3 | 15 | | 3 | 15 |
| 4 | 64 | | 4 | 64 |
| 5 | 325 | | 5 | 325 |
| 6 | 1956 | | 6 | 1956 |
| 7 | 13699 | | 7 | 13699 |
| 8 | 109600 | | 8 | 109600 |
| 9 | 986409 | | 9 | 986409 |
| 10 | 9864100 | | 10 | 9864100 |
Forwarded Requests vs. Number of Participating AORs Forwarded Requests vs. Number of Participating AORs
In a network where all proxies are performing loop-detection, an
In a network where all proxies are performing loop detection, an
attacker is still afforded rapidly increasing returns on the number attacker is still afforded rapidly increasing returns on the number
of AORs they are able to leverage. The Max-Breadth mechanism defined of AORs they are able to leverage. The Max-Breadth mechanism defined
in this document is designed to limit the effectiveness of this in this document is designed to limit the effectiveness of this
variation of the attack. variation of the attack.
In all of the scenarios, it is important to notice that at each In all of the scenarios, it is important to notice that at each
forking proxy, an additional branch could be added pointing to a forking proxy, an additional branch could be added pointing to a
single victim (that might not even be a SIP-aware element), resulting single victim (that might not even be a SIP-aware element), resulting
in a massive amount of traffic being directed towards the victim from in a massive amount of traffic being directed towards the victim from
potentially as many sources as there are AORs participating in the potentially as many sources as there are AORs participating in the
attack. attack.
4. Updates to RFC 3261 4. Updates to RFC 3261
4.1. Strengthening the Requirement to Perform Loop-detection 4.1. Strengthening the Requirement to Perform Loop Detection
The following requirements mitigate the risk of a proxy falling The following requirements mitigate the risk of a proxy falling
victim to the attack described in this document. victim to the attack described in this document.
When a SIP proxy forks a particular request to more than one When a SIP proxy forks a particular request to more than one
location, it MUST ensure that request is not looping through this location, it MUST ensure that request is not looping through this
proxy. It is RECOMMENDED that proxies meet this requirement by proxy. It is RECOMMENDED that proxies meet this requirement by
performing the Loop-Detection steps defined in this document. performing the loop-detection steps defined in this document.
The requirement to use this document's refinement of the loop- The requirement to use this document's refinement of the loop-
detection algorithm in RFC 3261 is set at should-strength to allow detection algorithm from RFC 3261 is set at should-strength to allow
for future standards track mechanisms that will allow a proxy to for future Standards-Track mechanisms that will allow a proxy to
determine it is not looping. For example, a proxy forking to determine it is not looping. For example, a proxy forking to
destinations established using the sip-outbound mechanism destinations established using the sip-outbound mechanism [OUTBOUND]
[I-D.ietf-sip-outbound] would know those branches will not loop. would know those branches will not loop.
A SIP proxy forwarding a request to only one location MAY perform A SIP proxy forwarding a request to only one location MAY perform
loop detection but is not required to. When forwarding to only one loop detection but is not required to. When forwarding to only one
location, the amplification risk being exploited is not present, and location, the amplification risk being exploited is not present, and
the Max-Forwards mechanism will protect the network to the extent it the Max-Forwards mechanism will protect the network to the extent it
was designed to do (always keep the constant multiplier due to was designed (always keep in mind the constant multiplier due to
exhausting Max-Forwards while not forking in mind.) A proxy is not exhausting Max-Forwards while not forking). A proxy is not required
required to perform loop detection when forwarding a request to a to perform loop detection when forwarding a request to a single
single location even if it happened to have previously forked that location even if it happened to have previously forked that request
request (and performed loop detection) in its progression through the (and performed loop detection) in its progression through the
network. network.
4.2. Correcting and Clarifying the RFC 3261 Loop-detection Algorithm 4.2. Correcting and Clarifying the RFC 3261 Loop-Detection Algorithm
4.2.1. Update to section 16.6 4.2.1. Update to Section 16.6
This section replaces all of item 8 in section 16.6 of RFC 3261 (item This section replaces all of item 8 in Section 16.6 of RFC 3261 (item
8 begins on page 105 and ends on page 106 of RFC 3261). 8 begins on page 105 and ends on page 106 of RFC 3261).
8. Add a Via header field value 8. Add a Via Header Field Value
The proxy MUST insert a Via header field value into the copy before The proxy MUST insert a Via header field value into the copy before
the existing Via header field values. The construction of this value the existing Via header field values. The construction of this value
follows the same guidelines of Section 8.1.1.7. This implies that follows the same guidelines of Section 8.1.1.7. This implies that
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 5393 have an
replace XXXX with the RFC number of this document) have an additional additional constraint on the value they place in the Via header
constraint on the value they place in the Via header field. Such field. Such proxies SHOULD create a branch value separable into two
proxies SHOULD create a branch value separable into two parts in any parts in any implementation-dependent way.
implementation dependent way.
The remainder of this section's description assumes the existance of The remainder of this section's description assumes the existence of
these two parts. If a proxy chooses to employ some other mechanism, these two parts. If a proxy chooses to employ some other mechanism,
it is the implementer's responsibility to verify that the detection it is the implementer's responsibility to verify that the detection
properties defined by the requirements placed on these two parts are properties defined by the requirements placed on these two parts are
acheived. achieved.
The first part of the branch value MUST satisfy the constraints of 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 Section 8.1.1.7. The second part is used to perform loop detection
and distinguish loops from spirals. 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.
This second part MUST NOT vary with the request method. CANCEL and This second part MUST NOT vary with the request method. CANCEL and
non-200 ACK requests MUST have the same branch parameter value as the non-200 ACK requests MUST have the same branch parameter value as the
corresponding request they cancel or acknowledge. This branch corresponding request they cancel or acknowledge. This branch
parameter value is used in correlating those requests at the server parameter value is used in correlating those requests at the server
handling them (see Sections 17.2.3 and 9.2). handling them (see Sections 17.2.3 and 9.2).
4.2.2. Update to Section 16.3 4.2.2. Update to Section 16.3
This section replaces all of item 4 in section 16.3 of RFC 3261 (item This section replaces all of item 4 in Section 16.3 of RFC 3261 (item
4 appears on page 95 RFC 3261). 4 appears on page 95 of RFC 3261).
4. Loop Detection Check 4. Loop-Detection Check
Proxies required to perform loop-detection by RFC-XXXX (RFC-Editor: Proxies required to perform loop detection by RFC 5393 MUST perform
replace XXXX with the RFC number of this document) MUST perform the the following loop-detection test before forwarding a request. Each
following loop-detection test before forwarding a request. Each Via Via header field value in the request whose sent-by value matches a
header field value in the request whose sent-by value matches a value value placed into previous requests by this proxy MUST be inspected
placed into previous requests by this proxy MUST be inspected for the for the "second part" defined in Section 4.2.1 of RFC 5393. This
"second part" defined in Section 4.2.1 of RFC-XXXX. This second part second part will not be present if the message was not forked when
will not be present if the message was not forked when that Via that Via header field value was added. If the second field is
header field value was added. If the second field is present, the present, the proxy MUST perform the second-part calculation described
proxy MUST perform the second part calculation described in in Section 4.2.1 of RFC 5393 on this request and compare the result
Section 4.2.1 of RFC-XXXX on this request and compare the result to to the value from the Via header field. If these values are equal,
the value from the Via header field. If these values are equal, the the request has looped and the proxy MUST reject the request with a
request has looped and the proxy MUST reject the request with a 482 482 (Loop Detected) response. If the values differ, the request is
(Loop Detected) response. If the values differ, the request is
spiraling and processing continues to the next step. spiraling and processing continues to the next step.
4.2.3. Impact of Loop-detection on Overall Network Performance 4.2.3. Impact of Loop Detection on Overall Network Performance
These requirements and the recommendation to use the loop-detection These requirements and the recommendation to use the loop-detection
mechanisms in this document make the favorable trade of exponential mechanisms in this document make the favorable trade of exponential
message growth for work that is at worst case order n^2 as a message message growth for work that is, at worst, order n^2 as a message
crosses n proxies. Specifically, this work is order m*n where m is crosses n proxies. Specifically, this work is order m*n where m is
the number of proxies in the path that fork the request to more than the number of proxies in the path that fork the request to more than
one location. In practice, m is expected to be small. one location. In practice, m is expected to be small.
The loop detection algorithm expressed in this document requires a The loop-detection algorithm expressed in this document requires a
proxy to inspect each Via element in a received request. In the proxy to inspect each Via element in a received request. In the
worst case where a message crosses N proxies, each of which loop worst case, where a message crosses N proxies, each of which loop
detect, proxy k does k inspections, and the overall number of detect, proxy k does k inspections, and the overall number of
inspections spread across the proxies handling this request is the inspections spread across the proxies handling this request is the
sum of k from k=1 to k=N which is N(N+1)/2. sum of k from k=1 to k=N which is N(N+1)/2.
4.2.4. Note to Implementors 4.2.4. Note to Implementers
A common way to create the second part of the branch parameter value A common way to create the second part of the branch parameter value
when forking a request is to compute a hash over the concatenation of when forking a request is to compute a hash over the concatenation of
the Request-URI, any Route header field values used during processing the Request-URI, any Route header field values used during processing
the request and any other values used by the location service logic the request, and any other values used by the location service logic
while processing this request. The hash should be chosen so that while processing this request. The hash should be chosen so that
there is a low probability that two distinct sets of these parameters there is a low probability that two distinct sets of these parameters
will collide. Because the maximum number of inputs which need to be will collide. Because the maximum number of inputs that need to be
compared is 70 the chance of a collision is low even with a compared is 70, the chance of a collision is low even with a
relatively small hash value, such as 32 bits. CRC-32c as specified relatively small hash value, such as 32 bits. CRC-32c as specified
in [RFC4960] is a specific acceptable function, as is MD5 [RFC1321]. in [RFC4960] is a specific acceptable function, as is MD5 [RFC1321].
Note that MD5 is being chosen purely for non-cryptographic Note that MD5 is being chosen purely for non-cryptographic
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 elements Via header due to parsers objecting to the contents of another element's Via
field values when inspecting the Via stack for loops. Implementers header field values when inspecting the Via stack for loops.
need to take care to avoid making assumptions about the format of Implementers need to take care to avoid making assumptions about the
another element's Via header field value beyond the basic constraints format of another element's Via header field value beyond the basic
placed on that format by RFC 3261. In particular, parsing a header constraints placed on that format by RFC 3261. In particular,
field value with unknown parameter names, parameters with no values, parsing a header field value with unknown parameter names, parameters
or parameters values with or without quoted strings must not cause an with no values, or parameter values with or without quoted strings
implementation to fail. must not cause an 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
5.1. Overview 5.1. Overview
The Max-Breadth mechanism defined here limits the total number of The Max-Breadth mechanism defined here limits the total number of
concurrent branches caused by a forked SIP request. With this concurrent branches caused by a forked SIP request. With this
mechanism, all proxyable requests are assigned a positive integral mechanism, all proxyable requests are assigned a positive integral
Max-Breadth value, which denotes the maximum number of concurrent Max-Breadth value, which denotes the maximum number of concurrent
branches this request may spawn through parallel forking as it is branches this request may spawn through parallel forking as it is
forwarded from its current point. When a proxy forwards a request, forwarded from its current point. When a proxy forwards a request,
its Max-Breadth value is divided among the outgoing requests. In its Max-Breadth value is divided among the outgoing requests. In
turn, each of the forwarded requests has a limit on how many turn, each of the forwarded requests has a limit on how many
concurrent branches they may spawn. As branches complete, their concurrent branches it may spawn. As branches complete, their
portion of the Max-Breadth value becomes available for subsequent portion of the Max-Breadth value becomes available for subsequent
branches, if needed. If there is insufficient Max-Breadth to carry branches, if needed. If there is insufficient Max-Breadth to carry
out a desired parallel fork, a proxy can return the 440 (Max-Breadth out a desired parallel fork, a proxy can return the 440 (Max-Breadth
Exceeded) response defined in this document. Exceeded) response defined in this document.
This mechanism operates independently from Max-Forwards. Max- This mechanism operates independently from Max-Forwards. Max-
Forwards limits the depth of the tree a request may traverse as it is Forwards limits the depth of the tree a request may traverse as it is
forwarded from its origination point to each destination it may be forwarded from its origination point to each destination it is forked
forked to. As Section 3 shows, the number of branches in a tree of to. As Section 3 shows, the number of branches in a tree of even
even limited depth can be made large (exponential with depth) by limited depth can be made large (exponential with depth) by
leveraging forking. Each such branch has a pair of SIP transaction leveraging forking. Each such branch has a pair of SIP transaction
state machines associated with it. The Max-Breadth mechanism limits state machines associated with it. The Max-Breadth mechanism limits
the number of branches that are active (those that have running the number of branches that are active (those that have running
transaction state machines) at any given point in time. transaction state machines) at any given point in time.
Max-Breadth does not prevent forking. It only limits the number of Max-Breadth does not prevent forking. It only limits the number of
concurrent parallel forked branches. In particular, a Max-Breadth of concurrent parallel forked branches. In particular, a Max-Breadth of
1 restricts a request to pure serial forking rather than restricting 1 restricts a request to pure serial forking rather than restricting
it from being forked at all. it from being forked at all.
A client receiving a 440 (Max-Breadth Exceeded) response can infer A client receiving a 440 (Max-Breadth Exceeded) response can infer
that it its request did not reach all possible destinations. that its request did not reach all possible destinations. Recovery
Recovery options are similar to those when receiving a 483 (Too Many options are similar to those when receiving a 483 (Too Many Hops)
Hops) response, and include affecting the routing decisions through response, and include affecting the routing decisions through
whatever mechanisms are appropriate to result in a less broad search, whatever mechanisms are appropriate to result in a less broad search,
or refining the request itself before submission to make the search or refining the request itself before submission to make the search
space smaller. space smaller.
5.2. Examples 5.2. Examples
UAC Proxy A Proxy B Proxy C UAC Proxy A Proxy B Proxy C
| INVITE | | | | INVITE | | |
| Max-Breadth: 60 | INVITE | | | Max-Breadth: 60 | INVITE | |
| Max-Forwards: 70 | Max-Breadth: 30 | | | Max-Forwards: 70 | Max-Breadth: 30 | |
|-------------------->| Max-Forwards: 69 | | |-------------------->| Max-Forwards: 69 | |
| |------------------->| | | |------------------->| |
| | INVITE | | | | INVITE | |
| | Max-Breadth: 30 | | | | Max-Breadth: 30 | |
| | Max-Forwards: 69 | | | | Max-Forwards: 69 | |
| |--------------------------------------->| | |--------------------------------------->|
| | | | | | | |
Parallel forking Parallel Forking
UAC Proxy A Proxy B Proxy C UAC Proxy A Proxy B Proxy C
| INVITE | | | | INVITE | | |
| Max-Breadth: 60 | INVITE | | | Max-Breadth: 60 | INVITE | |
| Max-Forwards: 70 | Max-Breadth: 60 | | | Max-Forwards: 70 | Max-Breadth: 60 | |
|-------------------->| Max-Forwards: 69 | | |-------------------->| Max-Forwards: 69 | |
| |------------------->| | | |------------------->| |
| | some error response| | | | some error response| |
| |<-------------------| | | |<-------------------| |
| | INVITE | | | | INVITE | |
| | Max-Breadth: 60 | | | | Max-Breadth: 60 | |
| | Max-Forwards: 69 | | | | Max-Forwards: 69 | |
| |--------------------------------------->| | |--------------------------------------->|
| | | | | | | |
Sequential forking Sequential Forking
UAC Proxy A Proxy B Proxy C UAC Proxy A Proxy B Proxy C
| INVITE | | | | INVITE | | |
| Max-Breadth: 60 | INVITE | | | Max-Breadth: 60 | INVITE | |
| Max-Forwards: 70 | Max-Breadth: 60 | INVITE | | Max-Forwards: 70 | Max-Breadth: 60 | INVITE |
|-------------------->| Max-Forwards: 69 | Max-Breadth: 60 | |-------------------->| Max-Forwards: 69 | Max-Breadth: 60 |
| |------------------->| Max-Forwards: 68 | | |------------------->| Max-Forwards: 68 |
| | |------------------>| | | |------------------>|
| | | | | | | |
| | | | | | | |
| | | | | | | |
No forking No Forking
MB == Max-Breadth MF == Max-Forwards MB == Max-Breadth MF == Max-Forwards
| MB: 4 | MB: 4
| MF: 5 | MF: 5
MB: 2 P MB: 2 MB: 2 P MB: 2
MF: 4 / \ MF: 4 MF: 4 / \ MF: 4
+---------------+ +------------------+ +---------------+ +------------------+
MB: 1 P MB: 1 MB: 1 P MB: 1 MB: 1 P MB: 1 MB: 1 P MB: 1
MF: 3 / \ MF: 3 MF: 3 / \ MF: 3 MF: 3 / \ MF: 3 MF: 3 / \ MF: 3
+---+ +-------+ +----+ +-------+ +---+ +-------+ +----+ +-------+
skipping to change at page 15, line 25 skipping to change at page 12, line 38
MB: 1 | MB: 1 | MB: 1 | MB: 1 | MB: 1 | MB: 1 | MB: 1 | MB: 1 |
MF: 2 | MF: 2 | MF: 2 | MF: 2 | MF: 2 | MF: 2 | MF: 2 | MF: 2 |
P P P P P P P P
MB: 1 | MB: 1 | MB: 1 | MB: 1 | MB: 1 | MB: 1 | MB: 1 | MB: 1 |
MF: 1 | MF: 1 | MF: 1 | MF: 1 | MF: 1 | MF: 1 | MF: 1 | MF: 1 |
P P P P P P P P
. .
. .
. .
Max-Breadth and Max-Forwards working together Max-Breadth and Max-Forwards Working Together
5.3. Formal Mechanism 5.3. Formal Mechanism
5.3.1. "Max-Breadth" Header 5.3.1. Max-Breadth Header Field
The Max-Breadth header takes a single positive integer as its value. The Max-Breadth header field takes a single positive integer as its
The Max-Breadth header takes no parameters. value. The Max-Breadth header field value takes no parameters.
5.3.2. Terminology 5.3.2. Terminology
For each "response context" (see [RFC3261] Sec 16) in a proxy, this For each "response context" (see Section 16 of [RFC3261]) in a proxy,
mechanism defines two positive integral values; Incoming Max-Breadth this mechanism defines two positive integral values: Incoming Max-
and Outgoing Max-Breadth. Incoming Max-Breadth is the value of the Breadth and Outgoing Max-Breadth. Incoming Max-Breadth is the value
Max-Breadth header field value in the request that formed the in the Max-Breadth header field in the request that formed the
response context. Outgoing Max-Breadth is the sum of the Max-Breadth response context. Outgoing Max-Breadth is the sum of the Max-Breadth
of all forwarded requests in the response context, that have not header field values in all forwarded requests in the response context
received a final response. that have not received a final response.
5.3.3. Proxy Behavior 5.3.3. Proxy Behavior
If a SIP proxy receives a request with no Max-Breadth header field If a SIP proxy receives a request with no Max-Breadth header field
value, it MUST add one, with a value that is RECOMMENDED to be 60. value, it MUST add one, with a value that is RECOMMENDED to be 60.
Proxies MUST have a maximum allowable Incoming Max-Breadth value, Proxies MUST have a maximum allowable Incoming Max-Breadth value,
which is RECOMMENDED to be 60. If this maximum is exceeded in a which is RECOMMENDED to be 60. If this maximum is exceeded in a
received request, the proxy MUST overwrite it with a value that received request, the proxy MUST overwrite it with a value that
SHOULD be no greater than its allowable maximum. SHOULD be no greater than its allowable maximum.
skipping to change at page 16, line 21 skipping to change at page 13, line 38
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 mean 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
it to restrict the "depth" of a request's propagation. it to restrict the "depth" of a request's propagation.
5.3.3.1. Reusing Max-Breadth 5.3.3.1. Reusing Max-Breadth
Because forwarded requests that have received a final response do not Because forwarded requests that have received a final response do not
count towards the Outgoing Max-Breadth, whenever a final response count towards the Outgoing Max-Breadth, whenever a final response
arrives, the Max-Breadth that was used on that branch becomes arrives, the Max-Breadth that was used on that branch becomes
available for reuse. Proxies SHOULD be prepared to reuse this Max- available for reuse. Proxies SHOULD be prepared to reuse this Max-
Breadth in cases where there may be elements left in the target-set. Breadth in cases where there may be elements left in the target-set.
5.3.4. UAC Behavior 5.3.4. UAC Behavior
A UAC MAY place a Max-Breadth header field value in outgoing A User Agent Client (UAC) MAY place a Max-Breadth header field value
requests. If so, this value is RECOMMENDED to be 60. in outgoing requests. If so, this value is RECOMMENDED to be 60.
5.3.5. UAS behavior 5.3.5. UAS Behavior
This mechanism does not affect UAS behavior. A UAS receiving a This mechanism does not affect User Agent Server (UAS) behavior. A
request with a Max-Breadth header field will ignore that field while UAS receiving a request with a Max-Breadth header field will ignore
processing the request. that field while processing the request.
5.4. Implementor Notes 5.4. Implementer Notes
5.4.1. Treatment of CANCEL 5.4.1. Treatment of CANCEL
Since CANCEL requests are never proxied, a Max-Breadth header-field- Since CANCEL requests are never proxied, a Max-Breadth header field
value is meaningless in a CANCEL request. Sending a CANCEL in no way value is meaningless in a CANCEL request. Sending a CANCEL in no way
effects the Outgoing Max-Breadth in the associated INVITE response affects the Outgoing Max-Breadth in the associated INVITE response
context. Receiving a CANCEL in no way effects the Incoming Max- context. Receiving a CANCEL in no way affects the Incoming Max-
Breadth of the associated INVITE response context. Breadth of the associated INVITE response context.
5.4.2. Reclamation of Max-Breadth on 2xx Responses 5.4.2. Reclamation of Max-Breadth on 2xx Responses
Whether 2xx responses free up Max-Breadth is mostly a moot issue, Whether 2xx responses free up Max-Breadth is mostly a moot issue,
since proxies are forbidden to start new branches in this case. But, since proxies are forbidden to start new branches in this case. But,
there is one caveat. For INVITE, we may receive multiple 2xx for a there is one caveat. A proxy may receive multiple 2xx responses for
single branch. Also, 2543 implementations may send back a 6xx a single forwarded INVITE request. Also, [RFC2543] implementations
followed by a 2xx on the same branch. Implementations that subtract may send back a 6xx followed by a 2xx on the same branch.
from the Outgoing Max-Breadth when they receive an INVITE/2xx must be Implementations that subtract from the Outgoing Max-Breadth when they
careful to avoid bugs caused by subtracting multiple times for a receive a 2xx response to an INVITE request must be careful to avoid
single branch. bugs caused by subtracting multiple times for a single branch.
5.4.3. Max-Breadth and Automaton UAs 5.4.3. Max-Breadth and Automaton UAs
Designers of automaton UAs (including B2BUAs, gateways, exploders, Designers of automaton user agents (UAs) (including B2BUAs, gateways,
and any other element that programmatically sends requests as a exploders, and any other element that programmatically sends requests
result of incoming SIP traffic) should consider whether Max-Breadth as a result of incoming SIP traffic) should consider whether Max-
limitations should be placed on outgoing requests. For example, it Breadth limitations should be placed on outgoing requests. For
is reasonable to design B2BUAs to carry the Max-Breadth value from example, it is reasonable to design B2BUAs to carry the Max-Breadth
incoming requests over into requests that are sent as a result. value from incoming requests into requests that are sent as a result.
Also, it is reasonable to place Max-Breadth constraints on sets of Also, it is reasonable to place Max-Breadth constraints on sets of
requests sent by exploders, when they may be leveraged in an requests sent by exploders when they may be leveraged in an
amplification attack. amplification attack.
5.5. Parallel and Sequential Forking 5.5. Parallel and Sequential Forking
Inherent in the definition of this mechanism is the ability of a Inherent in the definition of this mechanism is the ability of a
proxy to reclaim apportioned Max-Breadth while forking sequentially. proxy to reclaim apportioned Max-Breadth while forking sequentially.
The limitation on outgoing Max-Breadth is applied to concurrent The limitation on outgoing Max-Breadth is applied to concurrent
branches only. branches only.
For example, if a proxy receives a request with a Max-Breadth of 4, For example, if a proxy receives a request with a Max-Breadth of 4
and has 8 targets to forward it to, that proxy may parallel fork to 4 and has 8 targets to forward it to, that proxy may parallel fork to 4
of these targets initially (each with a Max-Breadth of 1, totaling an of these targets initially (each with a Max-Breadth of 1, totaling an
Outgoing Max-Breadth of 4). If one of these transactions completes Outgoing Max-Breadth of 4). If one of these transactions completes
with a failure response, the outgoing Max-Breadth drops to 3, with a failure response, the outgoing Max-Breadth drops to 3,
allowing the proxy to forward to one of the 4 remaining targets allowing the proxy to forward to one of the 4 remaining targets
(again, with a Max-Breadth of 1). (again, with a Max-Breadth of 1).
5.6. Max-Breadth Split Weight Selection 5.6. Max-Breadth Split Weight Selection
There are a variety of mechanisms for controlling the weight of each There are a variety of mechanisms for controlling the weight of each
fork branch. Fork branches that are given more Max-Breadth are more fork branch. Fork branches that are given more Max-Breadth are more
likely to complete quickly (because it is less likely that a proxy likely to complete quickly (because it is less likely that a proxy
down the line will be forced to fork sequentially). By the same down the line will be forced to fork sequentially). By the same
token, if it is known that a given branch will not fork later on, a token, if it is known that a given branch will not fork later on, a
Max-Breadth of 1 may be assigned with no ill effect. This would be Max-Breadth of 1 may be assigned with no ill effect. This would be
appropriate, for example, if a proxy knows the branch is using the appropriate, for example, if a proxy knows the branch is using the
SIP outbound extension [I-D.ietf-sip-outbound]. SIP outbound extension [OUTBOUND].
5.7. Max-Breadth's Effect on Forking-based Amplification Attacks 5.7. Max-Breadth's Effect on Forking-Based Amplification Attacks
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. (i.e.,
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-Breadth Header Field ABNF Definition 5.8. Max-Breadth Header Field ABNF Definition
This specification extends the grammar for the Session Initiation This specification extends the grammar for the Session Initiation
Protocol by adding the following extension-header: Protocol by adding an extension-header. The ABNF [RFC5234]
definition is as follows.
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-Breadth Header Field 6.1. Max-Breadth Header Field
This information should appear in the header sub-registry under This information appears in the Header Fields sub-registry of the SIP
http://www.iana.org/assignments/sip-parameters. Parameters registry.
RFC XXXX (this specification) RFC 5393 (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 appears in the Response Codes sub-registry of the
under http://www.iana.org/assignments/sip-parameters. SIP Parameters registry.
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 The Max-Breadth mechanism defined here does not decrease the
aggregate traffic caused by the forking-loop attack. It only serves aggregate traffic caused by the forking-loop attack. It only serves
to spread the traffic caused by the attack over a longer period, by to spread the traffic caused by the attack over a longer period by
limiting the number of concurrent branches that are being processed limiting the number of concurrent branches that are being processed
at the same time. An attacker could pump multiple requests into a at the same time. An attacker could pump multiple requests into a
network that uses the Max-Breadth mechanism and gradually build network that uses the Max-Breadth mechanism and gradually build
traffic to unreasonable levels. Deployments should monitor carefully traffic to unreasonable levels. Deployments should monitor carefully
and react to gradual increases in the number of concurrent and react to gradual increases in the number of concurrent
outstanding transactions related to a given resource to protect outstanding transactions related to a given resource to protect
against this possibility. Operators should anticipate being able to against this possibility. Operators should anticipate being able to
temporarily disable any resources identified as being used in such an temporarily disable any resources identified as being used in such an
attack. A rapid increase in outstanding concurrent transactions attack. A rapid increase in outstanding concurrent transactions
system-wide may be an indication of the presence of this kind of system-wide may be an indication of the presence of this kind of
skipping to change at page 19, line 37 skipping to change at page 17, line 12
and react to gradual increases in the number of concurrent and react to gradual increases in the number of concurrent
outstanding transactions related to a given resource to protect outstanding transactions related to a given resource to protect
against this possibility. Operators should anticipate being able to against this possibility. Operators should anticipate being able to
temporarily disable any resources identified as being used in such an temporarily disable any resources identified as being used in such an
attack. A rapid increase in outstanding concurrent transactions attack. A rapid increase in outstanding concurrent transactions
system-wide may be an indication of the presence of this kind of system-wide may be an indication of the presence of this kind of
attack across many resources. Deployments in which it is feasible attack across many resources. Deployments in which it is feasible
for an attacker to obtain a very large number of resources are for an attacker to obtain a very large number of resources are
particularly at risk. If detecting and intervening in each instance particularly at risk. If detecting and intervening in each instance
of the attack is insufficient to reduce the load, overload may occur. of the attack is insufficient to reduce the load, overload may occur.
Implementers and operators are encouraged to follow the Implementers and operators are encouraged to follow the
recommendations being developed for handling overload conditions (see recommendations being developed for handling overload conditions (see
[I-D.ietf-sipping-overload-reqs] and [REQS] and [DESIGN]).
[I-D.ietf-sipping-overload-design]).
Designers of protocol gateways should consider the implications of Designers of protocol gateways should consider the implications of
this kind of attack carefully. As an example, if a message transits 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 from a SIP network into the Public Switched Telephone Network (PSTN)
network, and information about the history of the request on either and subsequently back into a SIP network, and information about the
side of the protocol translation is lost, it becomes possible to history of the request on either side of the protocol translation is
construct loops that neither Max-Forwards nor loop-detection can lost, it becomes possible to construct loops that neither Max-
protect against. This combined with forking amplification on the SIP Forwards nor loop detection can protect against. This, combined with
side of the loop will result in an attack as described in this forking amplification on the SIP side of the loop, will result in an
document that the mechanisms here will not abate, not even to the attack as described in this document that the mechanisms here will
point of limiting the number of concurrent messages in the attack. not abate, not even to the point of limiting the number of concurrent
messages in the attack. These considerations are particularly
These considerations are particularly important for designers of important for designers of gateways from SIP to SIP (as found in
gateways from SIP to SIP (as found in B2BUAs for example). Many B2BUAs, for example). Many existing B2BUA implementations are under
existing B2BUA implementations are under some pressure to hide as some pressure to hide as much information about the two sides
much information about the two sides communicating with them as communicating with them as possible. Implementers of such
possible. Implementers of such implementations may be tempted to implementations may be tempted to remove the data that might be used
remove the data that might be used by the loop-detection, Max- by the loop-detection, Max-Forwards, or Max-Breadth mechanisms at
Forwards, or Max-Breadth mechanisms at other points in the network, other points in the network, taking on the responsibility for
taking the responsibility for detecting loops (or forms of this detecting loops (or forms of this attack). However, if two such
attack) on themselves. However, if two such implementations are implementations are involved in the attack, neither will be able to
involved in the attack, neither will be able to detect it. detect it.
7.1. Alternate solutions that were considered and rejected 7.1. Alternate Solutions That Were Considered and Rejected
Alternative solutions that were discussed included Alternative solutions that were discussed include:
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
time period than the invite. The invite itself may have come from time period than the INVITE transaction. The INVITE request
an innocent). It's even possible that the scenario may be set up itself may have come from an innocent). It's even possible that
unintentionally. Furthermore, for some existing deployments, the the scenario may be set up unintentionally. Furthermore, for some
cost and audit ability of an account is simply an email address. existing deployments, the cost and audit ability of an account is
Finding someone to punish may be impossible. Finally, there are simply an email address. Finding someone to punish may be
individuals who will not respond to any threat of legal action, impossible. Finally, there are individuals who will not respond
and the effect of even a single successful instance of this kind to any threat of legal action, and the effect of even a single
of attack would be devastating to a service-provider. successful instance of this kind of attack would be devastating to
a service provider.
Putting a smaller cap on Max-Forwards: The effect of the attack is Putting a smaller cap on Max-Forwards: The effect of the attack is
exponential with respect to the initial Max-Forwards value. exponential with respect to the initial Max-Forwards value.
Turning this value down limits the effect of the attack. This Turning this value down limits the effect of the attack. This
comes at the expense of severely limiting the reach of requests in comes at the expense of severely limiting the reach of requests in
the network, possibly to the point that existing architectures the network, possibly to the point that existing architectures
will begin to fail. will begin to fail.
Disallowing registration bindings to arbitrary contacts: The way Disallowing registration bindings to arbitrary contacts: The way
registration binding is currently defined is a key part of the registration binding is currently defined is a key part of the
success of the kind of attack documented here. The alternative of success of the kind of attack documented here. The alternative of
limiting registration bindings to allow only binding to the limiting registration bindings to allow only binding to the
network element performing the registration, perhaps to the network element performing the registration, perhaps to the
extreme of ignoring bits provided in the Contact in favor of extreme of ignoring bits provided in the Contact in favor of
transport artifacts observed in the registration request has been transport artifacts observed in the registration request, has been
discussed (particularly in the context of the mechanisms being discussed (particularly in the context of the mechanisms being
defined in [I-D.ietf-sip-outbound]. Mechanisms like this may be defined in [OUTBOUND]). Mechanisms like this may be considered
considered again in the future, but are currently insufficiently again in the future, but are currently insufficiently developed to
developed to address the present threat. 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 too extreme a
solution. solution.
Don't reclaim breadth An alternative design of the Max-Breadth Don't reclaim breadth: 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. breadth from completed branches to be reused (see
Under this alternative, an introduced request would cause at most Section 5.3.3.1). Under this alternative, an introduced request
the initial value of Max-Breadth transactions to be generated in would cause, at most, the initial value of Max-Breadth
the network. While that approach limits any variant of the transactions to be generated in the network. While that approach
amplification vulnerability described here to a constant limits any variant of the amplification vulnerability described
multiplier, it would dramatically change the potential reach of here to a constant multiplier, it would dramatically change the
requests and there is belief that it would break existing potential reach of requests, and there is belief that it would
deployments. break existing deployments.
8. Acknowledgments 8. Acknowledgments
Thanks go to the implementors that subjected their code to this Thanks go to the implementers 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. References
RFC Editor - Remove this section before publication
9.1. -06 to -07
Cleaning up some things based on WGLC and review for publication
request (like refreshing references)
Added a sentence to the overview discussing what a client might do
if it got a 440
Reinforced that a UAC will ignore a Max-Breadth header
Updated the reference to CRC32C - from 3309 to 4960
Integrated fixes from Jan Kolomaznik's review
9.2. -05 to -06
Integrated Max-Breadth based on working group discussion of the
secdir review
Added a paragraph pointing out that removing or modifying other
node's branch parameters defeats their ability to loop detect
Moved the total number of messages from O(2^70) to O(2^71) based
on an observation by Jan Kolomaznik. To see this, note that the
total number of requests is the sum from i=0 to Max-Forwards of
2^i which is 2^(Max-Forwards+1) - 1. The point of the text
doesn't change - (the point being that the number is _big_).
Made the new 4xx concrete (choosing 440)
Added a sentence reinforcing that if you forward to only one
branch, you still potentially have a constant multiplier of
messages in the network as Max-Forwards runs out (based on
feedback from Thomas Cross.)
9.3. -04 to -05
Boilerplate update, editorial nits fixed
9.4. -03 to -04
Addressed WGLC comments
Changed the hash recommendation per list consensus
Reintroduced Call-ID and CSeq (list discussion rediscovered one
use for them in avoiding repeated hash collisions)
9.5. -02 to -03
Closed Open Issue 1 "Why are we including all of the Route headers
values?". The text has been modified to include only those values
used in processing the request.
Closed Open Issues 2 and 3 "Why did 3261 include Call-ID To-tag,
and From-tag and CSeq?" and "Why did 3261 include Proxy-Require
and Proxy-Authorization?". The group has not been able to
identify why these fields would be included in the hash generally,
and successful interoperability tests have not included them.
Since they were not included in the text for -02, the text for
this version was not affected.
Removed the word "cryptographic" from the hash description in the
non-normative note to implementers (per list discussion) and added
characterization of the properties the hash chosen should have.
9.6. -01 to -02
Integrated several editorial fixes suggested by Jonathan Rosenberg
Noted that the reduction of the attack to a single registration
against a single URI as documented in previous versions, is, in
fact, going to be effective against implementations conforming to
the standards before this repair.
Re-incorporated motivation from the original maxforwards-problem
draft into the security considerations section based on feedback
from Cullen Jennings
Introduced replacement text for the loop detection algorithm
description in RFC 3261, fixing the bug 648 (the topmost Via value
must not be included in the second part) and clarifying the
algorithm. Removed several other fields suggested by 3261 and
placed open issues around their presence.
Added a Notes to Implementors section capturing the "common way"
text and pointing to the interoperability issues that have been
observed with loop detection at previous SIPits
10. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
10.2. Informative References [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[I-D.ietf-sip-outbound] 9.2. Informative References
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-15 (work in progress), June 2008.
[I-D.ietf-sipping-overload-design] [DESIGN] Hilt, V., "Design Considerations for Session Initiation
Hilt, V., "Design Considerations for Session Initiation Protocol (SIP) Overload Control", Work in Progress,
Protocol (SIP) Overload Control", July 2008.
draft-ietf-sipping-overload-design-00 (work in progress),
October 2008.
[I-D.ietf-sipping-overload-reqs] [OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated
Rosenberg, J., "Requirements for Management of Overload in Connections in the Session Initiation Protocol (SIP)",
the Session Initiation Protocol", Work in Progress, October 2008.
draft-ietf-sipping-overload-reqs-05 (work in progress),
[REQS] Rosenberg, J., "Requirements for Management of Overload
in the Session Initiation Protocol", Work in Progress,
July 2008. 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.
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[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
Nortel Networks, Inc. Nortel Networks, Inc.
600 Technology Park 600 Technology Park
Billerica, MA 01821 Billerica, MA 01821
USA USA
Phone: +1 978 248 5508 Phone: +1 978 288 5508
Email: scott.lawrence@nortel.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 USA
Phone: +1 650 623 1300 Phone: +1 650 623 1300
Email: alan.ietf@polyphase.ca EMail: alan.ietf@polyphase.ca
Byron Campen Byron Campen
Tekelec Tekelec
17210 Campbell Road 17210 Campbell Road
Suite 250 Suite 250
Dallas, Texas 75254-4203 Dallas, Texas 75254-4203
USA USA
Email: bcampen@estacado.net EMail: bcampen@estacado.net
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.
 End of changes. 111 change blocks. 
413 lines changed or deleted 308 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/