draft-ietf-sip-fork-loop-fix-06.txt   draft-ietf-sip-fork-loop-fix-07.txt 
Network Working Group R. Sparks, Ed. Network Working Group R. Sparks, Ed.
Internet-Draft Estacado Systems 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 Bluesocket Inc.
Expires: May 6, 2008 A. Hawrylyshen Expires: January 4, 2009 A. Hawrylyshen
Ditech Networks Inc. Ditech Networks Inc.
B. Campen B. Campen
Estacado Systems Tekelec
November 3, 2007 July 3, 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-06 draft-ietf-sip-fork-loop-fix-07
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 May 6, 2008. This Internet-Draft will expire on January 4, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 . . . . . . . . . . . . . . . . . 4 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 4 3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 5
4. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . . . 8 4. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . . . 9
4.1. Strengthening the Requirement to Perform Loop-detection . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Update to section 16.6 . . . . . . . . . . . . . . . . 8 4.2.1. Update to section 16.6 . . . . . . . . . . . . . . . . 9
4.2.2. Update to Section 16.3 . . . . . . . . . . . . . . . . 9 4.2.2. Update to Section 16.3 . . . . . . . . . . . . . . . . 10
4.2.3. Impact of Loop-detection on Overall Network 4.2.3. Impact of Loop-detection on Overall Network
Performance . . . . . . . . . . . . . . . . . . . . . 10 Performance . . . . . . . . . . . . . . . . . . . . . 11
4.2.4. Note to Implementors . . . . . . . . . . . . . . . . . 10 4.2.4. Note to Implementors . . . . . . . . . . . . . . . . . 11
5. Max-Breadth . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Max-Breadth . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Formal Mechanism . . . . . . . . . . . . . . . . . . . . . 13 5.3. Formal Mechanism . . . . . . . . . . . . . . . . . . . . . 14
5.3.1. "Max-Breadth" Header . . . . . . . . . . . . . . . . . 13 5.3.1. "Max-Breadth" Header . . . . . . . . . . . . . . . . . 14
5.3.2. Terminology . . . . . . . . . . . . . . . . . . . . . 13 5.3.2. Terminology . . . . . . . . . . . . . . . . . . . . . 14
5.3.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 13 5.3.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 15
5.3.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 14 5.3.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 15
5.3.5. UAS behavior . . . . . . . . . . . . . . . . . . . . . 14 5.3.5. UAS behavior . . . . . . . . . . . . . . . . . . . . . 16
5.4. Implementor Notes . . . . . . . . . . . . . . . . . . . . 15 5.4. Implementor Notes . . . . . . . . . . . . . . . . . . . . 16
5.4.1. Treatment of CANCEL . . . . . . . . . . . . . . . . . 15 5.4.1. Treatment of CANCEL . . . . . . . . . . . . . . . . . 16
5.4.2. Reclamation of Max-Breadth on 2xx Responses . . . . . 15 5.4.2. Reclamation of Max-Breadth on 2xx Responses . . . . . 16
5.4.3. Max-Breadth and Automaton UAs . . . . . . . . . . . . 15 5.4.3. Max-Breadth and Automaton UAs . . . . . . . . . . . . 16
5.5. Parallel and Sequential Forking . . . . . . . . . . . . . 15 5.5. Parallel and Sequential Forking . . . . . . . . . . . . . 16
5.6. Max-Breadth Split Weight Selection . . . . . . . . . . . . 16 5.6. Max-Breadth Split Weight Selection . . . . . . . . . . . . 17
5.7. Max-Breadth's Effect on Forking-based Amplification 5.7. Max-Breadth's Effect on Forking-based Amplification
Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 16 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.8. Max-Breadh Header Field ABNF Definition . . . . . . . . . 16 5.8. Max-Breadh Header Field ABNF Definition . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1. Max-Forwards Header Field . . . . . . . . . . . . . . . . 16 6.1. Max-Forwards Header Field . . . . . . . . . . . . . . . . 17
6.2. 440 Max-Breadth Exceeded response . . . . . . . . . . . . 17 6.2. 440 Max-Breadth Exceeded response . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 20
9.3. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 19 9.3. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 20
9.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 19 9.4. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 20
9.5. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 20 9.5. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.6. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 24
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 25 skipping to change at page 6, line 25
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 to any of the four
AoRs, say a@P1. This request will fork to two requests handled by AoRs, say a@P1. This request will fork to two requests handled by
P2, which will fork to four requests handled by P1, which will fork P2, which will fork to four requests handled by P1, which will fork
to eight messages handled by P2, and so on. This message flow is to eight messages handled by P2, and so on. This message flow is
represented in Figure 2. 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 2: 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
3260 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 worth of requests is longer than
Timer C at either proxy. In this case, a storm of 408s, and/or a Timer C at either proxy. In this case, a storm of 408s, and/or a
storm of CANCELs will also be propagating through the tree along with storm of CANCELs will also be propagating through the tree along with
the INVITEs. Remember that there are only two proxies involved in the INVITEs. Remember that there are only two proxies involved in
this scenario - each having to hold the state for all the this scenario - each having to hold the state for all the
transactions it sees (at least 2^70 simultaneously active transactions it sees (at least 2^70 simultaneously active
transactions near the end of the scenario). 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
skipping to change at page 6, line 45 skipping to change at page 7, line 45
complete the processing of the single INVITE that initiated the complete the processing of the single INVITE that initiated the
attack. It is interesting to note that a few proxies rebooted during attack. It is interesting to note that a few proxies rebooted during
the scenario, and rejoined in the attack when they restarted (as long the scenario, and rejoined in the attack when they restarted (as long
as they maintained registration state across reboots). This points as they maintained registration state across reboots). This points
out that if this attack were launched on the Internet at large, it out that if this attack were launched on the Internet at large, it
might require coordination among all the affected elements to stop might require coordination among all the affected elements to stop
it. 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. However, there is a variant of the attack that uses immediately. (If all the proxies involved implemented this loop-
multiple AORs where loop-detection alone is insufficient protection. detection, the total number of stimulated messages in the first
In this variation, each participating AOR forks to all the other scenario described is reduced to 14, and in the variation involving
one server, the number of stimulated messages is reduced to 10.)
However, there is a variant of the attack that uses multiple AORs
where loop-detection alone is insufficient protection. In this
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
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-
skipping to change at page 8, line 13 skipping to change at page 9, line 17
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
destination, 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 in 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
[I-D.ietf-sip-outbound] would know those branches will not loop. [I-D.ietf-sip-outbound] would know those branches will not loop.
skipping to change at page 10, line 32 skipping to change at page 11, line 35
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 which 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 [RFC3309] 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.
skipping to change at page 11, line 24 skipping to change at page 12, line 27
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, thier concurrent branches they may spawn. As branches complete, their
portion Max-Breadth value becomes available for subsequent branches, portion of the Max-Breadth value becomes available for subsequent
if needed. If there is insufficient Max-Breadth to carry out a branches, if needed. If there is insufficient Max-Breadth to carry
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 may be
forked to. As Section 3 shows, the number of branches in a tree of forked to. As Section 3 shows, the number of branches in a tree of
even limited depth can be made large (exponential with depth) by even 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
that it its request did not reach all possible destinations.
Recovery options are similar to those when receiving a 483 (Too Many
Hops) response, and include affecting the routing decisions through
whatever mechanisms are appropriate to result in a less broad search,
or refining the request itself before submission to make the search
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 | |
skipping to change at page 14, line 16 skipping to change at page 15, line 23
All proxied requests MUST contain a single Max-Breadth header field All proxied requests MUST contain a single Max-Breadth header field
value. value.
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 Exceeded sending a redirect, that proxy MUST return a 440 (Max-Breadth
response. Exceeded) response.
Notice that these requirements means a proxy receiving a request with Notice that these requirements means 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
skipping to change at page 14, line 47 skipping to change at page 16, line 7
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 UAC MAY place a Max-Breadth header field value in outgoing
requests. If so, this value is RECOMMENDED to be 60. 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. This mechanism does not affect UAS behavior. A UAS receiving a
request with a Max-Breadth header field will ignore that field while
processing the request.
5.4. Implementor Notes 5.4. Implementor 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 effects 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 effects the Incoming Max-
Breadth of the associated INVITE response context. Breadth of the associated INVITE response context.
skipping to change at page 18, line 45 skipping to change at page 20, line 5
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
9.1. -05 to -06 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 Integrated Max-Breadth based on working group discussion of the
secdir review secdir review
Added a paragraph pointing out that removing or modifying other Added a paragraph pointing out that removing or modifying other
node's branch parameters defeats their ability to loop detect 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 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 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 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 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_). doesn't change - (the point being that the number is _big_).
Made the new 4xx concrete (choosing 440) Made the new 4xx concrete (choosing 440)
skipping to change at page 19, line 20 skipping to change at page 20, line 40
2^i which is 2^(Max-Forwards+1) - 1. The point of the text 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_). doesn't change - (the point being that the number is _big_).
Made the new 4xx concrete (choosing 440) Made the new 4xx concrete (choosing 440)
Added a sentence reinforcing that if you forward to only one Added a sentence reinforcing that if you forward to only one
branch, you still potentially have a constant multiplier of branch, you still potentially have a constant multiplier of
messages in the network as Max-Forwards runs out (based on messages in the network as Max-Forwards runs out (based on
feedback from Thomas Cross.) feedback from Thomas Cross.)
9.2. -04 to -05 9.3. -04 to -05
Boilerplate update, editorial nits fixed Boilerplate update, editorial nits fixed
9.3. -03 to -04 9.4. -03 to -04
Addressed WGLC comments Addressed WGLC comments
Changed the hash recommendation per list consensus Changed the hash recommendation per list consensus
Reintroduced Call-ID and CSeq (list discussion rediscovered one Reintroduced Call-ID and CSeq (list discussion rediscovered one
use for them in avoiding repeated hash collisions) use for them in avoiding repeated hash collisions)
9.4. -02 to -03 9.5. -02 to -03
Closed Open Issue 1 "Why are we including all of the Route headers Closed Open Issue 1 "Why are we including all of the Route headers
values?". The text has been modified to include only those values values?". The text has been modified to include only those values
used in processing the request. used in processing the request.
Closed Open Issues 2 and 3 "Why did 3261 include Call-ID To-tag, 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 From-tag and CSeq?" and "Why did 3261 include Proxy-Require
and Proxy-Authorization?". The group has not been able to and Proxy-Authorization?". The group has not been able to
identify why these fields would be included in the hash generally, identify why these fields would be included in the hash generally,
and successful interoperability tests have not included them. and successful interoperability tests have not included them.
Since they were not included in the text for -02, the text for Since they were not included in the text for -02, the text for
this version was not affected. this version was not affected.
Removed the word "cryptographic" from the hash description in the Removed the word "cryptographic" from the hash description in the
non-normative note to implementers (per list discussion) and added non-normative note to implementers (per list discussion) and added
characterization of the properties the hash chosen should have. characterization of the properties the hash chosen should have.
9.5. -01 to -02 9.6. -01 to -02
Integrated several editorial fixes suggested by Jonathan Rosenberg Integrated several editorial fixes suggested by Jonathan Rosenberg
Noted that the reduction of the attack to a single registration Noted that the reduction of the attack to a single registration
against a single URI as documented in previous versions, is, in against a single URI as documented in previous versions, is, in
fact, going to be effective against implementations conforming to fact, going to be effective against implementations conforming to
the standards before this repair. the standards before this repair.
Re-incorporated motivation from the original maxforwards-problem Re-incorporated motivation from the original maxforwards-problem
draft into the security considerations section based on feedback draft into the security considerations section based on feedback
skipping to change at page 20, line 45 skipping to change at page 22, line 15
[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 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-10 (work in progress), July 2007. draft-ietf-sip-outbound-15 (work in progress), June 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.
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
Transmission Protocol (SCTP) Checksum Change", RFC 3309, RFC 4960, September 2007.
September 2002.
Authors' Addresses Authors' Addresses
Robert Sparks (editor) Robert Sparks (editor)
Estacado Systems 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. Bluesocket Inc.
10 North Ave. 10 North Ave.
skipping to change at page 21, line 36 skipping to change at page 23, line 14
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
Estacado Systems 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 Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 22, line 44 skipping to change at line 995
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 31 change blocks. 
81 lines changed or deleted 106 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/