draft-ietf-sip-fork-loop-fix-00.txt   draft-ietf-sip-fork-loop-fix-01.txt 
Network Working Group R. Sparks, Ed. Network Working Group R. Sparks, Ed.
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Updates: 3261 (if approved) S. Lawrence Updates: 3261 (if approved) S. Lawrence
Expires: August 28, 2006 Pingtel Corp. Expires: October 2, 2006 Pingtel Corp.
A. Hawrylyshen A. Hawrylyshen
Ditech Communications Corp. Ditech Communications Corp.
February 24, 2006 March 31, 2006
Addressing an Amplification Vulnerability in Forking Proxies Addressing an Amplification Vulnerability in Forking Proxies
draft-ietf-sip-fork-loop-fix-00 draft-ietf-sip-fork-loop-fix-01
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 37 skipping to change at page 1, line 37
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 August 28, 2006. This Internet-Draft will expire on October 2, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . . 3 1. Conventions and Definitions . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 3 3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 3
4. Normative changes to RFC 3261 . . . . . . . . . . . . . . . . . 5 4. Normative changes to RFC 3261 . . . . . . . . . . . . . . . . . 5
5. Impact on overall network performance . . . . . . . . . . . . . 6 5. Impact on overall network performance . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 9
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].
skipping to change at page 3, line 32 skipping to change at page 3, line 32
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.
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 accont 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>
skipping to change at page 5, line 25 skipping to change at page 5, line 25
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 scenerio 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 increases, 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 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 in the wild, it might require out that if this attack were launched on the Internet at large, it
coordination among all the affected elements to stop it. might require coordination among all the affected elements to stop
it.
4. Normative changes to RFC 3261 4. Normative changes to RFC 3261
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 destination, 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 as an optional step in performing the Loop-Detection steps defined as an optional step in
Section 16.3 of RFC 3261. Other loop-detection mechanisms, such as Section 16.3 of RFC 3261.
an adaptation of Knuth's algorithm, or the technique described in
[I-D.campen-sipping-stack-loop-detect] MAY be used. The requirement to use the loop-detection algorithm in RFC 3261 is
set at should-strength since it is expected that other mechanisms
that will allow a proxy to determine it is not looping will be
standardized in the near future. For example, a proxy forking to
destinations established using the sip-outbound mechanism [I-D.ietf-
sip-outbound] 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 is sufficient to protect the network. A the Max-Forwards mechanism is sufficient to protect the network. A
proxy is not required to peform loop detection when forwarding a proxy is not required to perform loop detection when forwarding a
request to a single location even if it previously forked that request to a single location even if it previously forked that
request in its progression through the network. request in its progression through the network.
5. Impact on overall network performance 5. Impact 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 from RFC 3261 make the favorable trade of exponential mechanisms from RFC 3261 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 case 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. Optimizations one location. In practice, m is expected to be small.
such as that described in [I-D.campen-sipping-stack-loop-detect]
could reduce this to work that is linear with m and independent of n.
6. IANA Considerations 6. IANA Considerations
None. None.
7. Security Considerations 7. Security Considerations
This document is entirely about addressing a vulnerability in SIP This document is entirely about addressing a vulnerability in SIP
proxies as defined by RFC 3261 that can lead to an exponentially proxies as defined by RFC 3261 that can lead to an exponentially
growing message exchange attack. growing message exchange attack.
8. Acknowledgements 8. Acknowledgements
Thanks go to the implementors that subjected thier code to this Thanks go to the implementors that subjected their code to this
scenario and helped analyze the results at SIPIT 17. scenario and helped analyze the results at SIPit 17.
Dave Oran brought the idea of using a Knuth's-algorithm-like
alternative to the loop detection mechanisms in RFC 3261 to the SIP
working group's attention many times in the development of the SIP
protocol.
9. References 9. References
9.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.
9.2. Informative References 9.2. Informative References
[I-D.campen-sipping-stack-loop-detect] [I-D.ietf-sip-outbound]
Campen, B., "An Efficient Loop Detection Algorithm for SIP Jennings, C. and R. Mahy, "Managing Client Initiated
Proxies", draft-campen-sipping-stack-loop-detect-00 (work Connections in the Session Initiation Protocol (SIP)",
in progress), February 2006. draft-ietf-sip-outbound-03 (work in progress), March 2006.
Authors' Addresses Authors' Addresses
Robert Sparks (editor) Robert Sparks (editor)
Estacado Systems Estacado Systems
17210 Campbell Road 17210 Campbell Road
Suite 250 Suite 250
Dallas, Texas 75254-4203 Dallas, Texas 75254-4203
USA USA
 End of changes. 13 change blocks. 
28 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/