doc: Add RFC documents

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]
+