draft-ietf-sip-fork-loop-fix-02.txt   draft-ietf-sip-fork-loop-fix-03.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: December 27, 2006 Pingtel Corp. Expires: March 9, 2007 Pingtel Corp.
A. Hawrylyshen A. Hawrylyshen
Ditech Networks Inc. Ditech Networks Inc.
June 25, 2006 September 5, 2006
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-02 draft-ietf-sip-fork-loop-fix-03
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 38 skipping to change at page 1, line 38
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 December 27, 2006. This Internet-Draft will expire on March 9, 2007.
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 22 skipping to change at page 2, line 22
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
4.1. Strengthening the requirement to perform loop-detection . 5 4.1. Strengthening the requirement to perform loop-detection . 5
4.2. Correcting and clarifying the RFC 3261 loop-detection 4.2. Correcting and clarifying the RFC 3261 loop-detection
algorithm . . . . . . . . . . . . . . . . . . . . . . . . 6 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Update to section 16.6 . . . . . . . . . . . . . . . . 6 4.2.1. Update to section 16.6 . . . . . . . . . . . . . . . . 6
4.2.2. Update to section 16.3 . . . . . . . . . . . . . . . . 7 4.2.2. Update to section 16.3 . . . . . . . . . . . . . . . . 7
4.2.3. Note to Implementers . . . . . . . . . . . . . . . . . 8 4.2.3. Note to Implementers . . . . . . . . . . . . . . . . . 7
5. Impact on overall network performance . . . . . . . . . . . . 8 5. Impact on overall network performance . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 13
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
skipping to change at page 6, line 47 skipping to change at page 6, line 47
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 XXXX (RFC-Editor:
replace XXXX with the RFC number of this document) have an additional replace XXXX with the RFC number of this document) have an additional
constraint on the value they place in the Via header field. Such constraint on the value they place in the Via header field. Such
proxies SHOULD crate a branch value separable into two parts in any proxies SHOULD create a branch value separable into two parts in any
implementation dependent way. The first part MUST satisfy the implementation dependent way. The first part MUST satisfy the
constraints of Section 8.1.1.7. The second part is used to perform constraints of Section 8.1.1.7. The second part is used to perform
loop detection and distinguish loops from spirals. loop detection and distinguish loops from spirals.
This second part MUST vary with any field used by the location This second part MUST vary with any field used by the location
service logic in determining where to retarget or forward this service logic in determining where to retarget or forward this
request. This is necessary to distinguish looped requests from request. This is necessary to distinguish looped requests from
spirals by allowing the proxy to recognize if none of the values spirals by allowing the proxy to recognize if none of the values
affecting the processing of the request have changed. Hence, The affecting the processing of the request have changed. Hence, The
second part MUST depend at least on the received Request-URI and any second part MUST depend at least on the received Request-URI and any
Route header field values in the received request. Implementers need Route header field values used when processing the received request.
to take care to include all fields used by the location service logic Implementers need to take care to include all fields used by the
in that particular implementation. location service logic in that particular implementation.
This second part MUST NOT include the request method. CANCEL and This second part MUST NOT include 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).
Open Issue 1 : Why do all the Route header field values need to be
included? Only the top two in the received request will normally
influence processing (in general, the topmost and any others this
proxy removes from the message, plus the topmost in the message
the proxy emits). Can we simplify this to only include those
Route header field values that actually affect the processing of
the message?
Open Issue 2 : RFC 3261 recommends Call-ID, To-tag, and From-tag and
CSeq be included in this second part. Why? This are guaranteed
to be invariant each time the request passes through this proxy.
Further the created value will only be compared with Vias received
from previous times the request went through this proxy, so there
is no possibility of comparing this value with a hash created from
some other request with a different Call-ID, To-tag, or From-tag
or CSeq. I've removed these fields from the recommended set for
this version of the draft.
Open Issue 3 : RFC 3261 recommends including any Proxy-Require and
Proxy-Authorization header field values in the second part. Why
it it valuable to call these out as special cases? What is the
use case where they will be the only thing in a message returning
to a proxy that varies, making the return a spiral instead of a
loop? I haven't been able to remember the motivation - we need to
re-identify that and capture it here or remove the text making
these anything other than a case covered by the abstract "fields
used by the location service logic". This draft is taking the
second option.
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 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-XXXX (RFC-Editor:
replace XXXX with the RFC number of this document) MUST perform the replace XXXX with the RFC number of this document) MUST perform the
following loop-detection test before forwarding a request. Each Via following loop-detection test before forwarding a request. Each Via
skipping to change at page 8, line 25 skipping to change at page 7, line 44
proxy MUST perform the second part calculation described in proxy MUST perform the second part calculation described in
Section 4.2.1 of RFC-XXXX on this request and compare the result to Section 4.2.1 of RFC-XXXX on this request and compare the result to
the value from the Via header field. If these values are equal, the the value from the Via header field. If these values are equal, the
request has looped and the proxy MUST reject the request with a 482 request has looped and the proxy MUST reject the request with a 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. Note to Implementers 4.2.3. 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 cryptographic hash over the when forking a request is to compute a hash over the concatenation of
concatenation of the Request-URI, all Route header field values, and the Request-URI, any Route header field values used during processing
any other values used by the location service logic while processing the request and any other values used by the location service logic
this request. An MD5 [RFC1321] hash expressed in hexadecimal (base64 while processing this request. An MD5 [RFC1321] hash expressed in
is not permissible for a token) is a reasonable choice of a hash hexadecimal (base64 is not permissible for a token) is a reasonable
function. choice of a hash function. Any hash function chosen should have the
property of very low probability of collision. Hashes resulting in
fewer than 128 bits are not recommended.
A common point of failure to interoperate at SIPit events has been A common point of failure to interoperate at SIPit events has been
due to parsers objecting to the contents of other's Via header field due to parsers objecting to the contents of other's Via header field
values when inspecting the Via stack for loops. Implementers need to values when inspecting the Via stack for loops. Implementers need to
take care to avoid making assumptions about the format of another take care to avoid making assumptions about the format of another
element's Via header field value beyond the basic constraints placed element's Via header field value beyond the basic constraints placed
on that format by RFC 3261. In particular, parsing a header field on that format by RFC 3261. In particular, parsing a header field
value with unknown parameter names, parameters with no values, value with unknown parameter names, parameters with no values,
parameters values with and without quoted strings must not cause an parameters values with and without quoted strings must not cause an
implementation to fail. implementation to fail.
skipping to change at page 9, line 10 skipping to change at page 8, line 29
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. 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 = N(N+1)/2. sum of k from k=1 to k=N which is N(N+1)/2.
6. IANA Considerations 6. IANA Considerations
None. None.
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.
skipping to change at page 10, line 38 skipping to change at page 10, line 9
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. scenario and helped analyze the results at SIPit 17.
9. Change Log 9. Change Log
RFC Editor - Remove this section before publication RFC Editor - Remove this section before publication
9.1. -01 to -02 9.1. -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.2. -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 11, line 31 skipping to change at page 11, line 20
[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-03 (work in progress), March 2006. draft-ietf-sip-outbound-04 (work in progress), June 2006.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
Authors' Addresses Authors' Addresses
Robert Sparks (editor) Robert Sparks (editor)
Estacado Systems Estacado Systems
17210 Campbell Road 17210 Campbell Road
Suite 250 Suite 250
 End of changes. 14 change blocks. 
51 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/