draft-ietf-sip-fork-loop-fix-03.txt   draft-ietf-sip-fork-loop-fix-04.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: March 9, 2007 Pingtel Corp. Expires: April 24, 2007 Pingtel Corp.
A. Hawrylyshen A. Hawrylyshen
Ditech Networks Inc. Ditech Networks Inc.
September 5, 2006 October 21, 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-03 draft-ietf-sip-fork-loop-fix-04
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 March 9, 2007. This Internet-Draft will expire on April 24, 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 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . 7 4.2.3. Note to Implementers . . . . . . . . . . . . . . . . . 7
5. Impact on overall network performance . . . . . . . . . . . . 8 5. Impact on overall network performance . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. -03 to -04 (addressing WGLC comments) . . . . . . . . . . 10
9.2. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 10
9.3. -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 7, line 13 skipping to change at page 7, line 13
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 include 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 RFC 3261).
skipping to change at page 7, line 47 skipping to change at page 7, line 47
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 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. An MD5 [RFC1321] hash expressed in while processing this request. The hash should be chosen so that
hexadecimal (base64 is not permissible for a token) is a reasonable there is a low probability that two distinct sets of these parameters
choice of a hash function. Any hash function chosen should have the will collide. Because the maximum number of inputs which need to be
property of very low probability of collision. Hashes resulting in compared is 70 the chance of a collision is low even with a
fewer than 128 bits are not recommended. relatively small hash value, such as 32 bits. CRC-32c as specified
in [RFC3309] is a specific acceptable function, as is MD5 [RFC1321].
Note that MD5 is being chosen purely for non-cryptographic
properties. An attacker who can control the inputs in order to
produce a hash collision can attack the connection in a variety of
other ways. When forming the second part using a hash,
implementations SHOULD include at least one field in the input to the
hash that varies between different transactions attempting to reach
the same destination to avoid repeated failure should the hash
collide. The Call-ID and CSeq fields would be good inputs for this
purpose.
A common point of failure to interoperate at SIPit events has been A common point of failure to interoperate at SIPit events has been
due to parsers objecting to the contents of other's Via header field due to parsers objecting to the contents of other'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 48 skipping to change at page 10, line 14
Deprecate forking : This attack does not exist in a system that Deprecate forking : This attack does not exist in a system that
relies entirely on redirection and initiation of new requests by relies entirely on redirection and initiation of new requests by
the original endpoint. Removing such a large architectural the original endpoint. Removing such a large architectural
component from the system at this time was deemed a too extreme component from the system at this time was deemed a too extreme
solution. solution.
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. Eric Rescorla
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. -02 to -03 9.1. -03 to -04 (addressing 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.2. -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.2. -01 to -02 9.3. -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
from Cullen Jennings from Cullen Jennings
Introduced replacement text for the loop detection algorithm Introduced replacement text for the loop detection algorithm
skipping to change at page 12, line 5 skipping to change at page 11, line 45
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-04 (work in progress), June 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.
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
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
Email: RjS@nostrum.com Email: RjS@nostrum.com
 End of changes. 13 change blocks. 
17 lines changed or deleted 39 lines changed or added

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