summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6026.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6026.txt')
-rw-r--r--doc/rfc/rfc6026.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc6026.txt b/doc/rfc/rfc6026.txt
new file mode 100644
index 0000000..b1998c6
--- /dev/null
+++ b/doc/rfc/rfc6026.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Sparks
+Request for Comments: 6026 Tekelec
+Updates: 3261 T. Zourzouvillys
+Category: Standards Track Skype
+ISSN: 2070-1721 September 2010
+
+
+ Correct Transaction Handling for 2xx Responses
+ to Session Initiation Protocol (SIP) INVITE Requests
+
+Abstract
+
+ This document normatively updates RFC 3261, the Session Initiation
+ Protocol (SIP), to address an error in the specified handling of
+ success (2xx class) responses to INVITE requests. Elements following
+ RFC 3261 exactly will misidentify retransmissions of the request as a
+ new, unassociated request. The correction involves modifying the
+ INVITE transaction state machines. The correction also changes the
+ way responses that cannot be matched to an existing transaction are
+ handled to address a security risk.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6026.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 1]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Conventions and Definitions .....................................3
+ 3. Reason for Change ...............................................3
+ 4. Summary of Change ...............................................4
+ 5. Consequences if Not Implemented .................................4
+ 6. The Change ......................................................4
+ 7. Change Details ..................................................5
+ 7.1. Server Transaction Impacts .................................5
+ 7.2. Client Transaction Impacts .................................9
+ 7.3. Proxy Considerations ......................................10
+ 8. Exact Changes to RFC 3261 ......................................11
+ 8.1. Page 85 ...................................................11
+ 8.2. Page 107 ..................................................11
+ 8.3. Page 114 ..................................................11
+ 8.4. Pages 126 through 128 .....................................12
+ 8.5. Pages 134 to 135 ..........................................15
+ 8.6. Page 136 ..................................................15
+ 8.7. Page 137 ..................................................17
+ 8.8. Page 141 ..................................................17
+ 8.9. Page 144 ..................................................18
+ 8.10. Page 146 .................................................18
+ 8.11. Page 265 .................................................18
+ 9. IANA Considerations ............................................18
+ 10. Security Considerations .......................................19
+ 11. Acknowledgments ...............................................20
+ 12. Normative References ..........................................20
+
+
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 2]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+1. Introduction
+
+ This document describes an essential correction to the Session
+ Initiation Protocol (SIP), defined in [RFC3261]. The change
+ addresses an error in the handling of 2xx class responses to INVITE
+ requests that leads to retransmissions of the INVITE being treated as
+ new requests and forbids forwarding stray INVITE responses.
+
+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. Reason for Change
+
+ One use of the INVITE method in SIP is to establish new sessions.
+ These "initial" INVITEs may fork at intermediaries, and more than one
+ receiving endpoint may choose to accept the request. SIP is designed
+ such that the requester receives all of these success responses.
+
+ Two sets of requirements in [RFC3261] work together to allow multiple
+ 2xx responses to be processed correctly by the requester. First, all
+ elements are required to immediately destroy any INVITE client
+ transaction state upon forwarding a matching 2xx class response.
+ This requirement applies to both UAs (user agents) and proxies
+ (proxies forward the response upstream, the transaction layer at user
+ agents forwards the response to its "UA core"). Second, all proxies
+ are required to statelessly forward upstream any 2xx class responses
+ that do not match an existing transaction, also called stray
+ responses. The transaction layer at user agents is required to
+ forward these responses to its UA core. Logic in the UA core deals
+ with acknowledging each of these responses.
+
+ This technique for specifying the behavior was chosen over adjusting
+ INVITE client transaction state machines as a simpler way to specify
+ the correct behavior.
+
+ Over time, implementation experience demonstrated the existing text
+ is in error. Once any element with a server transaction (say, a
+ proxy in the path of the INVITE) deletes that transaction state, any
+ retransmission of the INVITE will be treated as a new request,
+ potentially forwarded to different locations than the original. Many
+ implementations in the field have made proprietary adjustments to
+ their transaction logic to avoid this error.
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 3]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+ The requirement to statelessly forward stray responses has also been
+ identified as a security risk. Through it, elements compliant to
+ [RFC3261] are compelled to do work (forward packets) that is not
+ protected by the admission policies applied to requests. This can be
+ leveraged to, for instance, use a SIP proxy as an anonymizing
+ forwarder of packets in a distributed denial-of-service attack.
+ General Internet endpoints can also collude to tunnel non-SIP content
+ through such proxies by wrapping them in an SIP response envelope.
+
+ Additionally, [RFC3261] requires that if an unrecoverable transport
+ error is encountered while sending a response in a client
+ transaction, that the transaction moves immediately into the
+ "Terminated" state. This will result in any retransmitted INVITE
+ requests received after such an error was encountered to be processed
+ as a new request instead of being absorbed as a retransmission.
+
+4. Summary of Change
+
+ This correction document updates [RFC3261], adding a state and
+ changing the transitions in the INVITE client state machine such that
+ the INVITE client transaction remains in place to receive multiple
+ 2xx responses. It adds a state to the INVITE server state machine to
+ absorb retransmissions of the INVITE after a 2xx response has been
+ sent. It modifies state transitions in the INVITE server state
+ machine to absorb retransmissions of the INVITE request after
+ encountering an unrecoverable transport error when sending a
+ response. It also forbids forwarding stray responses to INVITE
+ requests (not just 2xx responses), which RFC 3261 requires.
+
+5. Consequences if Not Implemented
+
+ Implementations strictly conformant to [RFC3261] will process
+ retransmitted initial INVITE requests as new requests. Proxies may
+ forward them to different locations than the original. Proxies may
+ also be used as anonymizing forwarders of bulk traffic.
+ Implementations will process any retransmitted INVITE request as a
+ new request after an attempt to send a response results in an
+ unrecoverable error.
+
+6. The Change
+
+ An element sending or receiving a 2xx to an INVITE transaction MUST
+ NOT destroy any matching INVITE transaction state. This state is
+ necessary to ensure correct processing of retransmissions of the
+ request and the retransmission of the 2xx and ACK that follow.
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 4]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+ An element encountering an unrecoverable transport error when trying
+ to send a response to an INVITE request MUST NOT immediately destroy
+ the associated INVITE server transaction state. This state is
+ necessary to ensure correct processing of retransmissions of the
+ request.
+
+ When receiving any SIP response, a transaction-stateful proxy MUST
+ compare the transaction identifier in that response against its
+ existing transaction state machines. The proxy MUST NOT forward the
+ response if there is no matching transaction state machine.
+
+ When receiving an ACK that matches an existing INVITE server
+ transaction and that does not contain a branch parameter containing
+ the magic cookie defined in RFC 3261, the matching transaction MUST
+ be checked to see if it is in the "Accepted" state. If it is, then
+ the ACK must be passed directly to the transaction user instead of
+ being absorbed by the transaction state machine. This is necessary
+ as requests from RFC 2543 clients will not include a unique branch
+ parameter, and the mechanisms for calculating the transaction ID from
+ such a request will be the same for both INVITE and ACKs.
+
+7. Change Details
+
+ These changes impact requirements in several sections of RFC 3261.
+ The exact effect on that text is detailed in Section 8. This section
+ describes the details of the change, particularly the impact on the
+ INVITE state machines, more succinctly to facilitate review and
+ simplify implementation.
+
+7.1. Server Transaction Impacts
+
+ To allow a SIP element to recognize retransmissions of an INVITE as
+ retransmissions instead of new requests, a new state, "Accepted", is
+ added to the INVITE server transaction state machine. A new timer,
+ Timer L, is also added to ultimately allow the state machine to
+ terminate. A server transaction in the "Proceeding" state will
+ transition to the "Accepted" state when it issues a 2xx response and
+ will remain in that state just long enough to absorb any
+ retransmissions of the INVITE.
+
+ If the SIP element's TU (Transaction User) issues a 2xx response for
+ this transaction while the state machine is in the "Proceeding"
+ state, the state machine MUST transition to the "Accepted" state and
+ set Timer L to 64*T1, where T1 is the round-trip time estimate
+ defined in Section 17.1.1.1 of [RFC3261].
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 5]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+ While in the "Accepted" state, any retransmissions of the INVITE
+ received will match this transaction state machine and will be
+ absorbed by the machine without changing its state. These
+ retransmissions are not passed onto the TU. RFC 3261 requires the TU
+ to periodically retransmit the 2xx response until it receives an ACK.
+ The server transaction MUST NOT generate 2xx retransmissions on its
+ own. Any retransmission of the 2xx response passed from the TU to
+ the transaction while in the "Accepted" state MUST be passed to the
+ transport layer for transmission. Any ACKs received from the network
+ while in the "Accepted" state MUST be passed directly to the TU and
+ not absorbed.
+
+ When Timer L fires and the state machine is in the "Accepted" state,
+ the machine MUST transition to the "Terminated" state. Once the
+ transaction is in the "Terminated" state, it MUST be destroyed
+ immediately. Timer L reflects the amount of time the server
+ transaction could receive 2xx responses for retransmission from the
+ TU while it is waiting to receive an ACK.
+
+ A server transaction MUST NOT discard transaction state based only on
+ encountering a non-recoverable transport error when sending a
+ response. Instead, the associated INVITE server transaction state
+ machine MUST remain in its current state. (Timers will eventually
+ cause it to transition to the "Terminated" state). This allows
+ retransmissions of the INVITE to be absorbed instead of being
+ processed as a new request.
+
+ Figures 1 and 2 show the parts of the INVITE server state machine
+ that have changed. The entire new INVITE server state machine is
+ shown in Figure 5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 6]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+ BEFORE AFTER
+
+ +-----------+ +-----------+
+ | | | |
+ | Proceeding| | Proceeding|
+ | | | |
+ | | | |
+ | | | |
+ | | | |
+ +-----------+ +-----------+
+ |2xx from TU |2xx from TU
+ |send response |send response
+ +-------------->+ +------->+
+ | |
+ | |
+ | |
+ | | Transport
+ | INVITE | Error
+ | - | Inform TU
+ | +-----+ | +--+
+ | | | V | v
+ | | +------------+
+ | | | |<--+
+ | +->| Accepted | | ACK
+ | | |---+ to TU
+ | +------------+
+ | | ^ |
+ | +--+ | |
+ | | +-----+
+ | | 2xx from TU
+ | | send response
+ | |
+ | | Timer L fires
+ | | -
+ | |
+ | V
+ +-----------+ | +------------+
+ | | | | |
+ | Terminated|<-----------+ | Terminated |
+ | | | |
+ +-----------+ +------------+
+
+ Figure 1: Changes to the INVITE server transaction state machine
+ when sending 2xx
+
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 7]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+ BEFORE AFTER
+
+ +-----------+ +------------+
+ | | | |
+ | Proceeding| | Proceeding | Transport Err.
+ | | | | Inform TU
+ | | Transport Err. | |----------+
+ | | Inform TU | | |
+ | |--------------->+ | |<---------+
+ +-----------+ | +------------+
+ |
+ |
+ |
+ |
+ | Transport Err.
+ +-----------+ | +-----------+ Inform TU
+ | | | | |---------+
+ | Completed | | | Completed | |
+ | | | | |<--------+
+ +-----------+ | +-----------+
+ | |
+ | |
+ +------------------>+
+ Transport Err.|
+ Inform TU |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ +-----------+ |
+ | | |
+ | Terminated|<---------------+
+ | |
+ +-----------+
+
+ Figure 2: Changes to the INVITE server transaction state machine on
+ encountering transport error
+
+
+
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 8]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+7.2. Client Transaction Impacts
+
+ In order to correctly distinguish retransmissions of 2xx responses
+ from stray 2xx responses, the INVITE client state machine is modified
+ to not transition immediately to "Terminated" on receipt of a 2xx
+ response. Instead, the machine will transition to a new "Accepted"
+ state, and remain there just long enough, determined by a new timer
+ M, to receive and pass to the TU any retransmissions of the 2xx
+ response or any additional 2xx responses from other branches of a
+ downstream fork of the matching request. If a 2xx response is
+ received while the client INVITE state machine is in the "Calling" or
+ "Proceeding" states, it MUST transition to the "Accepted" state, pass
+ the 2xx response to the TU, and set Timer M to 64*T1. A 2xx response
+ received while in the "Accepted" state MUST be passed to the TU and
+ the machine remains in the "Accepted" state. The client transaction
+ MUST NOT generate an ACK to any 2xx response on its own. The TU
+ responsible for the transaction will generate the ACK.
+
+ When Timer M fires and the state machine is in the "Accepted" state,
+ the machine MUST transition to the "Terminated" state. Once the
+ transaction is in the "Terminated" state, it MUST be destroyed
+ immediately.
+
+ Any response received that does not match an existing client
+ transaction state machine is simply dropped. (Implementations are,
+ of course, free to log or do other implementation-specific things
+ with such responses, but the implementer should be sure to consider
+ the impact of large numbers of malicious stray responses.)
+
+ Note that it is not necessary to preserve client transaction state
+ upon the detection of unrecoverable transport errors. Existing
+ requirements ensure the TU has been notified, and the new
+ requirements in this document ensure that any received retransmitted
+ response will be dropped since there will no longer be any matching
+ transaction state.
+
+ Figure 3 shows the part of the INVITE client state machine that has
+ changed. The entire new INVITE client state machine is shown in
+ Figure 5.
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 9]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+ +-----------+ +-----------+
+ | | | |
+ | Calling | | Calling |
+ | |----------->+ | |-----------+
+ +-----------+ 2xx | +-----------+ 2xx |
+ 2xx to TU | 2xx to TU |
+ | |
+ | |
+ | |
+ | |
+ +-----------+ | +-----------+ |
+ | | | | | |
+ |Proceeding |----------->| |Proceeding |---------->|
+ | | 2xx | | | 2xx |
+ +-----------+ 2xx to TU | +-----------+ 2xx to TU |
+ | |
+ | |
+ | |
+ | V
+ | +-----------+
+ | | |
+ | | Accepted |
+ | +---| |
+ | 2xx | +-----------+
+ | 2xx to TU | ^ |
+ | | | |
+ | +-----+ |
+ | |
+ | +-----------------+
+ | | Timer M fires
+ | | -
+ | V
+ +-----------+ | +-----------+
+ | | | | |
+ | Terminated|<-----------+ | Terminated|
+ | | | |
+ +-----------+ +-----------+
+
+ Figure 3: Changes to the INVITE client transaction state machine
+
+7.3. Proxy Considerations
+
+ This document changes the behavior of transaction-stateful proxies to
+ not forward stray INVITE responses. When receiving any SIP response,
+ a transaction-stateful proxy MUST compare the transaction identifier
+ in that response against its existing transaction state machines.
+ The proxy MUST NOT forward the response if there is no matching
+ transaction state machine.
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 10]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+8. Exact Changes to RFC 3261
+
+ This section describes exactly the same changes as above, but shows
+ exactly which text in RFC 3261 is affected. This document
+ intentionally does not contain a Figure 4 or Figure 6 so that the
+ labels for Figures 5 and 7 are identical to the labels of the figures
+ they are replacing in RFC 3261.
+
+8.1. Page 85
+
+ Section 13.3.1.4, paragraph 4, is replaced entirely by:
+
+ Once the response has been constructed, it is passed to the INVITE
+ server transaction. In order to ensure reliable end-to-end
+ transport of the response, it is necessary to periodically pass
+ the response directly to the transport until the ACK arrives. The
+ 2xx response is passed to the transport with an interval that
+ starts at T1 seconds and doubles for each retransmission until it
+ reaches T2 seconds (T1 and T2 are defined in Section 17).
+ Response retransmissions cease when an ACK request for the
+ response is received. This is independent of whatever transport
+ protocols are used to send the response.
+
+8.2. Page 107
+
+ Section 16.7, paragraphs 1 and 2, are replaced entirely by:
+
+ When a response is received by an element, it first tries to
+ locate a client transaction (Section 17.1.3) matching the
+ response. If a transaction is found, the response is handed to
+ the client transaction. If none is found, the element MUST NOT
+ forward the response.
+
+8.3. Page 114
+
+ Section 16.7, part 9, first paragraph. Replace this sentence:
+
+ If the server transaction is no longer available to handle the
+ transmission, the element MUST forward the response statelessly by
+ sending it to the server transport.
+
+ with
+
+ If the server transaction is no longer available to handle the
+ transmission, the response is simply discarded.
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 11]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+8.4. Pages 126 through 128
+
+ Section 17.1.1.2. Replace paragraph 7 (starting "When in either")
+ through the end of the section with:
+
+ When in either the "Calling" or "Proceeding" states, reception of
+ a response with status code from 300-699 MUST cause the client
+ transaction to transition to "Completed". The client transaction
+ MUST pass the received response up to the TU, and the client
+ transaction MUST generate an ACK request, even if the transport is
+ reliable (guidelines for constructing the ACK from the response
+ are given in Section 17.1.1.3), and then pass the ACK to the
+ transport layer for transmission. The ACK MUST be sent to the
+ same address, port, and transport to which the original request
+ was sent.
+
+ The client transaction MUST start Timer D when it enters the
+ "Completed" state for any reason, with a value of at least 32
+ seconds for unreliable transports, and a value of zero seconds for
+ reliable transports. Timer D reflects the amount of time that the
+ server transaction can remain in the "Completed" state when
+ unreliable transports are used. This is equal to Timer H in the
+ INVITE server transaction, whose default is 64*T1, and is also
+ equal to the time a UAS core will wait for an ACK once it sends a
+ 2xx response. However, the client transaction does not know the
+ value of T1 in use by the server transaction or any downstream UAS
+ cores, so an absolute minimum of 32 s is used instead of basing
+ Timer D on T1.
+
+ Any retransmissions of a response with status code 300-699 that
+ are received while in the "Completed" state MUST cause the ACK to
+ be re-passed to the transport layer for retransmission, but the
+ newly received response MUST NOT be passed up to the TU.
+
+ A retransmission of the response is defined as any response that
+ would match the same client transaction based on the rules of
+ Section 17.1.3.
+
+ If Timer D fires while the client transaction is in the
+ "Completed" state, the client transaction MUST move to the
+ "Terminated" state.
+
+ When a 2xx response is received while in either the "Calling" or
+ "Proceeding" states, the client transaction MUST transition to the
+ "Accepted" state, and Timer M MUST be started with a value of
+ 64*T1. The 2xx response MUST be passed up to the TU. The client
+ transaction MUST NOT generate an ACK to the 2xx response -- its
+ handling is delegated to the TU. A UAC core will send an ACK to
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 12]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+ the 2xx response using a new transaction. A proxy core will
+ always forward the 2xx response upstream.
+
+ The purpose of the "Accepted" state is to allow the client
+ transaction to continue to exist to receive, and pass to the TU,
+ any retransmissions of the 2xx response and any additional 2xx
+ responses from other branches of the INVITE if it forked
+ downstream. Timer M reflects the amount of time that the
+ transaction user will wait for such messages.
+
+ Any 2xx responses that match this client transaction and that are
+ received while in the "Accepted" state MUST be passed up to the
+ TU. The client transaction MUST NOT generate an ACK to the 2xx
+ response. The client transaction takes no further action.
+
+ If Timer M fires while the client transaction is in the "Accepted"
+ state, the client transaction MUST move to the "Terminated" state.
+
+ The client transaction MUST be destroyed the instant it enters the
+ "Terminated" state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 13]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+ Replace Figure 5 with:
+
+ |INVITE from TU
+ Timer A fires |INVITE sent Timer B fires
+ Reset A, V or Transport Err.
+ INVITE sent +-----------+ inform TU
+ +---------| |--------------------------+
+ | | Calling | |
+ +-------->| |-----------+ |
+ 300-699 +-----------+ 2xx | |
+ ACK sent | | 2xx to TU | |
+ resp. to TU | |1xx | |
+ +-----------------------------+ |1xx to TU | |
+ | | | |
+ | 1xx V | |
+ | 1xx to TU +-----------+ | |
+ | +---------| | | |
+ | | |Proceeding | | |
+ | +-------->| | | |
+ | +-----------+ 2xx | |
+ | 300-699 | | 2xx to TU | |
+ | ACK sent, +--------+ +---------------+ |
+ | resp. to TU| | |
+ | | | |
+ | V V |
+ | +-----------+ +----------+ |
+ +------------->| |Transport Err. | | |
+ | Completed |Inform TU | Accepted | |
+ +--| |-------+ | |-+ |
+ 300-699 | +-----------+ | +----------+ | |
+ ACK sent| ^ | | | ^ | |
+ | | | | | | | |
+ +----+ | | | +-----+ |
+ |Timer D fires | Timer M fires| 2xx |
+ |- | - | 2xx to TU |
+ +--------+ | +-----------+ |
+ NOTE: V V V |
+ Transitions +------------+ |
+ are labeled | | |
+ with the event | Terminated |<-----------------------+
+ over the action | |
+ to take. +------------+
+
+ Figure 5: INVITE client transaction
+
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 14]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+8.5. Pages 134 to 135
+
+ Section 17.2.1, paragraph 4, is replaced with:
+
+ If, while in the "Proceeding" state, the TU passes a 2xx response
+ to the server transaction, the server transaction MUST pass this
+ response to the transport layer for transmission. It is not
+ retransmitted by the server transaction; retransmissions of 2xx
+ responses are handled by the TU. The server transaction MUST then
+ transition to the "Accepted" state.
+
+8.6. Page 136
+
+ Replace Figure 7 with:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 15]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+ |INVITE
+ |pass INV to TU
+ INVITE V send 100 if TU won't in 200 ms
+ send response+------------+
+ +--------| |--------+ 101-199 from TU
+ | | | | send response
+ +------->| |<-------+
+ | Proceeding |
+ | |--------+ Transport Err.
+ | | | Inform TU
+ | |<-------+
+ +------------+
+ 300-699 from TU | |2xx from TU
+ send response | |send response
+ +--------------+ +------------+
+ | |
+ INVITE V Timer G fires |
+ send response +-----------+ send response |
+ +--------| |--------+ |
+ | | | | |
+ +------->| Completed |<-------+ INVITE | Transport Err.
+ | | - | Inform TU
+ +--------| |----+ +-----+ | +---+
+ | +-----------+ | ACK | | v | v
+ | ^ | | - | +------------+
+ | | | | | | |---+ ACK
+ +----------+ | | +->| Accepted | | to TU
+ Transport Err. | | | |<--+
+ Inform TU | V +------------+
+ | +-----------+ | ^ |
+ | | | | | |
+ | | Confirmed | | +-----+
+ | | | | 2xx from TU
+ Timer H fires | +-----------+ | send response
+ - | | |
+ | | Timer I fires |
+ | | - | Timer L fires
+ | V | -
+ | +------------+ |
+ | | |<----+
+ +------->| Terminated |
+ | |
+ +------------+
+
+ Figure 7: INVITE server transaction
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 16]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+8.7. Page 137
+
+ In Section 17.2.1, replace the last paragraph (starting "Once the
+ transaction") with:
+
+ The purpose of the "Accepted" state is to absorb retransmissions
+ of an accepted INVITE request. Any such retransmissions are
+ absorbed entirely within the server transaction. They are not
+ passed up to the TU since any downstream UAS cores that accepted
+ the request have taken responsibility for reliability and will
+ already retransmit their 2xx responses if necessary.
+
+ While in the "Accepted" state, if the TU passes a 2xx response,
+ the server transaction MUST pass the response to the transport
+ layer for transmission.
+
+ When the INVITE server transaction enters the "Accepted" state,
+ Timer L MUST be set to fire in 64*T1 for all transports. This
+ value matches both Timer B in the next upstream client state
+ machine (the amount of time the previous hop will wait for a
+ response when no provisionals have been sent) and the amount of
+ time this (or any downstream) UAS core might be retransmitting the
+ 2xx while waiting for an ACK. If an ACK is received while the
+ INVITE server transaction is in the "Accepted" state, then the ACK
+ must be passed up to the TU. If Timer L fires while the INVITE
+ server transaction is in the "Accepted" state, the transaction
+ MUST transition to the "Terminated" state.
+
+ Once the transaction is in the "Terminated" state, it MUST be
+ destroyed immediately.
+
+8.8. Page 141
+
+ In Section 17.2.4, replace the second paragraph with:
+
+ First, the procedures in [4] are followed, which attempt to
+ deliver the response to a backup. If those should all fail, based
+ on the definition of failure in [4], the server transaction SHOULD
+ inform the TU that a failure has occurred, and MUST remain in the
+ current state.
+
+
+
+
+
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 17]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+8.9. Page 144
+
+ In Section 18.1.2, replace the second paragraph with:
+
+ The client transport uses the matching procedures of Section
+ 17.1.3 to attempt to match the response to an existing
+ transaction. If there is a match, the response MUST be passed to
+ that transaction. Otherwise, any element other than a stateless
+ proxy MUST silently discard the response.
+
+8.10. Page 146
+
+ In Section 18.2.1, replace the last paragraph with:
+
+ Next, the server transport attempts to match the request to a
+ server transaction. It does so using the matching rules described
+ in Section 17.2.3. If a matching server transaction is found, the
+ request is passed to that transaction for processing. If no match
+ is found, the request is passed to the core, which may decide to
+ construct a new server transaction for that request.
+
+8.11. Page 265
+
+ Add to Table 4:
+
+ Timer L 64*T1 Section 17.2.1 Wait time for
+ accepted INVITE
+ request retransmits
+
+ Timer M 64*T1 Section 17.1.1 Wait time for
+ retransmission of
+ 2xx to INVITE or
+ additional 2xx from
+ other branches of
+ a forked INVITE
+
+9. IANA Considerations
+
+ IANA has updated the SIP Parameters: Method and Response Codes
+ registry as follows:
+
+ OLD:
+
+ Methods Reference
+ ------- ---------
+ INVITE [RFC3261]
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 18]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+ NEW:
+
+ Methods Reference
+ ------- ---------
+ INVITE [RFC3261][RFC6026]
+
+10. Security Considerations
+
+ This document makes two changes to the Session Initiation Protocol to
+ address the error discussed in Section 3. It changes the behavior of
+ both the client and server INVITE transaction state machines, and it
+ changes the way "stray" responses (those that don't match any
+ existing transaction) are handled at transaction-stateful elements.
+
+ The changes to the state machines cause elements to hold onto each
+ accepted INVITE transaction state 32 seconds longer than what was
+ specified in RFC 3261. This will have a direct impact on the amount
+ of work an attacker that is leveraging state exhaustion will have to
+ exert against the system. However, this additional state is
+ necessary to achieve correct operation. There is some discussion of
+ avoiding state exhaustion and other denial-of-service attacks in RFC
+ 3261, Section 26.3.2.4.
+
+ RFC 3261 required SIP proxies to forward any stray 2xx class
+ responses to an INVITE request upstream statelessly. As a result,
+ conformant proxies can be forced to forward packets (that look
+ sufficiently like SIP responses) to destinations of the sender's
+ choosing. Section 3 discusses some of the malicious behavior this
+ enables. This document reverses the stateless forwarding
+ requirement, making it a violation of the specification to forward
+ stray responses.
+
+ RFC 3261 defines a "stateless proxy", which forwards requests and
+ responses without creating or maintaining any transaction state. The
+ requirements introduced in this document do not change the behavior
+ of these elements in any way. Stateless proxies are inherently
+ vulnerable to the abuses discussed in Section 3. One way operators
+ might mitigate this vulnerability is to carefully control which peer
+ elements can present traffic to a given stateless proxy.
+
+ The changes introduced by this document are backward-compatible.
+ Transaction behavior will be no less correct, and possibly more
+ correct, when only one peer in a transaction implements these
+ changes. Except for the considerations mentioned earlier in this
+ section, introducing elements implementing these changes into
+ deployments with RFC 3261 implementations adds no additional security
+ concerns.
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 19]
+
+RFC 6026 Correct Handling for SIP 2xx Responses September 2010
+
+
+11. Acknowledgments
+
+ Pekka Pessi reported the improper handling of INVITE retransmissions.
+ Brett Tate performed a careful review uncovering the need for the
+ "Accepted" state and Timer M in the client transaction state machine.
+ Jan Kolomaznik noticed that a server transaction should let a TU know
+ about transport errors when it attempts to send a 2xx class response.
+ Michael Procter corrected several nits.
+
+12. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+Authors' Addresses
+
+ Robert Sparks
+ Tekelec
+ 17210 Campbell Road
+ Suite 250
+ Dallas, Texas 75252
+ USA
+
+ EMail: RjS@nostrum.com
+
+
+ Theo Zourzouvillys
+ Skype
+ 3rd Floor
+ 8000 Marina Blvd
+ Brisbane, California 84005
+ US
+
+ EMail: theo@crazygreek.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks & Zourzouvillys Standards Track [Page 20]
+