From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6026.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc6026.txt (limited to 'doc/rfc/rfc6026.txt') 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] + -- cgit v1.2.3