idnits 2.17.1 draft-ietf-sipcore-invfix-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 20 form feeds but 265 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Mar 8, 2010) is 5153 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 677 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sparks 3 Internet-Draft Tekelec 4 Updates: 3261 (if approved) T. Zourzouvillys 5 Intended status: Standards Track Skype 6 Expires: September 9, 2010 Mar 8, 2010 8 Correct transaction handling for 2xx responses to Session Initiation 9 Protocol (SIP) INVITE requests 10 draft-ietf-sipcore-invfix-01 12 Abstract 14 This document normatively updates RFC 3261, the Session Initiation 15 Protocol (SIP), to address an error in the specified handling of 16 success (2xx class) responses to INVITE requests. Elements following 17 RFC 3261 exactly will misidentify retransmissions of the request as a 18 new, unassociated, request. The correction involves modifying the 19 INVITE transaction state machines. The correction also changes the 20 way responses that cannot be matched to an existing transaction are 21 handled to address a security risk. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 9, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Reason for Change . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Summary of Change . . . . . . . . . . . . . . . . . . . . . . 4 67 5. Consequences if Not Implemented . . . . . . . . . . . . . . . 4 68 6. The Change . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 7. Change Details . . . . . . . . . . . . . . . . . . . . . . . . 5 70 7.1. Server Transaction Impacts . . . . . . . . . . . . . . . . 5 71 7.2. Client Transaction Impacts . . . . . . . . . . . . . . . . 9 72 7.3. Proxy Considerations . . . . . . . . . . . . . . . . . . . 10 73 8. Exact changes to RFC3261 . . . . . . . . . . . . . . . . . . . 11 74 8.1. Page 85 . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.2. Page 107 . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.3. Page 114 . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 8.4. Pages 126 through 128 . . . . . . . . . . . . . . . . . . 12 78 8.5. Pages 134 to 135 . . . . . . . . . . . . . . . . . . . . . 15 79 8.6. Page 136 . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 8.7. Page 137 . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 8.8. Page 141 . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 8.9. Page 144 . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 8.10. Page 146 . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 8.11. Page 265 . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 88 12. Normative References . . . . . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Conventions and Definitions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC-2119 [RFC2119]. 97 2. Introduction 99 This document describes an essential correction to the Session 100 Initiation Protocol (SIP), defined in [RFC3261]. The change 101 addresses an error in the handling of 2xx class responses to INVITE 102 requests that leads to retransmissions of the INVITE being treated as 103 new requests and forbids forwarding stray INVITE responses. 105 3. Reason for Change 107 One use of the INVITE method in SIP is to establish new sessions. 108 These "initial" INVITEs may fork at intermediaries, and more than one 109 receiving endpoint may choose to accept the request. SIP is designed 110 such that the requester receives all of these success responses. 112 Two sets of requirements in [RFC3261] work together to allow multiple 113 2xx responses to be processed correctly by the requester. First, all 114 elements are required to immediately destroy any INVITE client 115 transaction state upon forwarding a matching 2xx class response. 116 This requirement applies to both proxies and user agents (proxies 117 forward the response upstream, the transaction layer at user agents 118 forward the response to its "UA (User-Agent) core"). Second, all 119 proxies are required to statelessly forward any 2xx class responses 120 that do not match an existing transaction, also called stray 121 responses, upstream. The transaction layer at user agents is 122 required to forward these responses to its UA core. Logic in the UA 123 core deals with acknowledging each of these responses. 125 This technique for specifying the behavior was chosen over adjusting 126 INVITE client transaction state machines as a simpler way to specify 127 the correct behavior. 129 Over time, implementation experience demonstrated the existing text 130 is in error. Once any element with a server transaction (say, a 131 proxy in the path of the INVITE) deletes that transaction state, any 132 retransmission of the INVITE will be treated as a new request, 133 potentially forwarded to different locations than the original. Many 134 implementations in the field have made proprietary adjustments to 135 their transaction logic to avoid this error. 137 The requirement to statelessly forward stray responses has also been 138 identified as a security risk. Through it, elements compliant to 139 [RFC3261] are compelled to do work (forward packets) that is not 140 protected by the admission policies applied to requests. This can be 141 leveraged to, for instance, use a SIP proxy as an anonymizing 142 forwarder of packets in a distributed DOS attack. General internet 143 endpoints can also collude to tunnel non-SIP content through such 144 proxies by wrapping them in an SIP response envelope. 146 Additionally, [RFC3261] requires that if an unrecoverable transport 147 error is encountered while sending a response in a client 148 transaction, that the transaction moves immediately into the 149 Terminated state. This will result in any re-transmitted INVITE 150 requests received after such an error was encountered be processed as 151 a new request instead of being absorbed as a re-transmission. 153 4. Summary of Change 155 This correction document updates [RFC3261], adding a state and 156 changing the transitions in the INVITE client state machine such that 157 the INVITE client transaction remains in place to receive multiple 158 2xx responses. It adds a state to the INVITE server state machine to 159 absorb retransmissions of the INVITE after a 2xx response has been 160 sent. It modifies state transitions in the INVITE server state 161 machine to absorb retransmissions of the INVITE request after 162 encountering a unrecoverable transport error when sending a response. 163 It also forbids forwarding stray responses to INVITE requests (not 164 just 2xx responses), which RFC3261 requires. 166 5. Consequences if Not Implemented 168 Implementations strictly conformant to [RFC3261] will process 169 retransmitted initial INVITE requests as new requests. Proxies may 170 forward them to different locations than the original. Proxies may 171 also be used as anonymizing forwarders of bulk traffic. 172 Implementations will process any retransmitted INVITE request as new 173 request after an attempt to send a response resulted in a 174 unrecoverable error. 176 6. The Change 178 An element sending or receiving a 2xx to an INVITE transaction MUST 179 NOT destroy any matching INVITE transaction state. This state is 180 necessary to ensure correct processing of retransmissions of the 181 request and the retransmission of the 2xx and ACK that follow. 183 An element encountering an unrecoverable tranport error when trying 184 to send a response to an INVITE request MUST NOT immediately destroy 185 the associated INVITE server transaction state. This state is 186 necessary to ensure correct processing of retransmissions of the 187 request. 189 When receiving any SIP response, a transaction-stateful proxy MUST 190 compare the transaction identifier in that response against its 191 existing transaction state machines. The proxy MUST NOT forward the 192 response if there is no matching transaction state machine. 194 When receiving an ACK that matches an existing INVITE server 195 transaction, and the ACK does not contain a branch parameter 196 containing the magic cookie defined in RFC 3261, the matching 197 transaction MUST be checked to see if it is in the "Accepted" state. 198 If it is, then the ACK must be passed directly to the transaction 199 user instead of absorbing it in the transaction. This is necessary 200 as requests from RFC 2543 clients will not include a unique branch 201 parameter, and the mechanisms for calculating the transaction id from 202 such a request will be the same for both INVITE and ACKs. 204 7. Change Details 206 These changes impact requirements in several sections of RFC3261. 207 The exact effect on that text is detailed in Section 8. This section 208 describes the details of the change, particularly the impact on the 209 INVITE state machines, more succinctly to facilitate review and 210 simplify implementation. 212 7.1. Server Transaction Impacts 214 To allow a SIP element to recognize retransmissions of an INVITE as 215 retransmissions instead of new requests, a new state, "Accepted", is 216 added to the INVITE server transaction state machine. A new timer, 217 Timer L, is also added to ultimately allow the state machine to 218 terminate. A server transaction in the "Proceeding" state will 219 transition to the "Accepted" state when it issues a 2xx response, and 220 will remain in that state just long enough to absorb any 221 retransmissions of the INVITE. 223 If the SIP element's TU (Transaction User) issues a 2xx response for 224 this transaction while the state machine is in the "Proceeding" 225 state, it MUST transition to the "Accepted" state and set Timer L to 226 64*T1. 228 While in the "Accepted" state, any retransmissions of the INVITE 229 received will match this transaction state machine and will be 230 absorbed by the machine without changing its state. These 231 retransmissions are not passed onto the TU. RFC3261 requires the TU 232 to periodically retransmit the 2xx response until it receives an ACK. 233 The server transaction MUST NOT generate 2xx retransmissions on its 234 own. Any retransmission of the 2xx response passed from the TU to 235 the transaction while in the "Accepted" state MUST be passed to the 236 transport layer for transmission. Any ACKs received from the network 237 while in the "Accepted" state MUST be passed directly to the TU and 238 not absorbed. 240 When Timer L fires and the state machine is in the "Accepted" state, 241 the machine MUST transition to the "Terminated" state. Once the 242 transaction is in the "Terminated" state, it MUST be destroyed 243 immediately. Timer L reflects the amount of time the server 244 transaction could receive 2xx responses for retransmission from the 245 TU while it is waiting to receive an ACK. 247 A server transaction MUST NOT discard transaction state based only on 248 encountering a non-recoverable transport error when sending a 249 response. Instead the assocated INVITE server transaction state 250 machine MUST remain in its current state. (Timers will eventually 251 cause it to transition to the Terminated state). This allows 252 retransmissions of the INVITE to be absorbed instead of being 253 processed as a new request. 255 Figure 1 and Figure 2 graphically show the parts of the INVITE server 256 state machine that has changed. The entire new INVITE server state 257 machine is shown in Figure 5. 259 BEFORE AFTER 261 +-----------+ +-----------+ 262 | | | | 263 | Proceeding| | Proceeding| 264 | | | | 265 | | | | 266 | | | | 267 | | | | 268 +-----------+ +-----------+ 269 |2xx from TU |2xx from TU 270 |send response |send response 271 +-------------->+ +------->+ 272 | | 273 | | 274 | | 275 | | Transport 276 | INVITE | Error 277 | - | Inform TU 278 | +-----+ | +--+ 279 | | | V | v 280 | | +------------+ 281 | | | |<--+ 282 | +->| Accepted | | ACK 283 | | |---+ to TU 284 | +------------+ 285 | | ^ | 286 | +--+ | | 287 | | +-----+ 288 | | 2xx from TU 289 | | send response 290 | | 291 | | Timer L fires 292 | | - 293 | | 294 | V 295 +-----------+ | +------------+ 296 | | | | | 297 | Terminated|<-----------+ | Terminated | 298 | | | | 299 +-----------+ +------------+ 301 Figure 1: Changes to the INVITE server transaction state machine when 302 sending 2xx 304 BEFORE AFTER 306 +-----------+ +------------+ 307 | | | | 308 | Proceeding| | Proceeding | Transport Err. 309 | | | | Inform TU 310 | | Transport Err. | |----------+ 311 | | Inform TU | | | 312 | |--------------->+ | |<---------+ 313 +-----------+ | +------------+ 314 | 315 | 316 | 317 | 318 | Transport Err. 319 +-----------+ | +-----------+ Inform TU 320 | | | | |---------+ 321 | Completed | | | Completed | | 322 | | | | |<--------+ 323 +-----------+ | +-----------+ 324 | | 325 | | 326 +------------------>+ 327 Transport Err.| 328 Inform TU | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | 337 | 338 +-----------+ | 339 | | | 340 | Terminated|<---------------+ 341 | | 342 +-----------+ 344 Figure 2: Changes to the INVITE server transaction state machine on 345 encountering transport error 347 7.2. Client Transaction Impacts 349 In order to correctly distinguish retransmissions of 2xx responses 350 from stray 2xx responses, the INVITE client state machine is modified 351 to not transition immediately to "Terminated" on receipt of a 2xx 352 response. Instead, the machine will transition to a new "Accepted" 353 state, and remain there just long enough, determined by a new timer 354 M, to receive and pass to the TU any retransmissions of the 2xx 355 response or any additional 2xx responses from other branches of a 356 downstream fork of the matching request. If a 2xx response is 357 received while the client INVITE state machine is in the "Calling" or 358 "Proceeding" states, it MUST transition to the "Accepted" state, pass 359 the 2xx response to the TU, and set Timer M to 64*T1. A 2xx response 360 received while in the "Accepted" state MUST be passed to the TU and 361 the machine remains in the "Accepted" state. The client transaction 362 MUST NOT generate an ACK to any 2xx response on its own. The TU 363 responsible for the transaction will generate the ACK. 365 When Timer M fires and the state machine is in the "Accepted" state, 366 the machine MUST transition to the "Terminated" state. Once the 367 transaction is in the "Terminated" state, it MUST be destroyed 368 immediately. 370 Any response received which does not match an existing client 371 transaction state machine is simply dropped. (Implementations are, 372 of course, free to log or do other implementation specific things 373 with such responses, but the implementer should be sure to consider 374 the impact of large numbers of malicious stray responses). 376 Note that it is not necessary to preserve client transaction state 377 upon the detection of unrecoverable transport errors. Existing 378 requirements ensure the TU has been notified, and the new 379 requirements in this document ensure that any received retransmitted 380 response will be dropped since there will no longer be any matching 381 transaction state. 383 Figure 3 graphically shows the part of the INVITE client state 384 machine that has changed. The entire new INVITE client state machine 385 is shown in Figure 4. 387 +-----------+ +-----------+ 388 | | | | 389 | Calling | | Calling | 390 | |----------->+ | |-----------+ 391 +-----------+ 2xx | +-----------+ 2xx | 392 2xx to TU | 2xx to TU | 393 | | 394 | | 395 | | 396 | | 397 +-----------+ | +-----------+ | 398 | | | | | | 399 |Proceeding |----------->| |Proceeding |---------->| 400 | | 2xx | | | 2xx | 401 +-----------+ 2xx to TU | +-----------+ 2xx to TU | 402 | | 403 | | 404 | | 405 | V 406 | +-----------+ 407 | | | 408 | | Accepted | 409 | +---| | 410 | 2xx | +-----------+ 411 | 2xx to TU | ^ | 412 | | | | 413 | +-----+ | 414 | | 415 | +-----------------+ 416 | | Timer M fires 417 | | - 418 | V 419 +-----------+ | +-----------+ 420 | | | | | 421 | Terminated|<-----------+ | Terminated| 422 | | | | 423 +-----------+ +-----------+ 425 Figure 3: Changes to the INVITE client transaction state machine 427 7.3. Proxy Considerations 429 This document changes the behaviour of transaction-stateful proxies 430 to not forward stray INVITE responses. When receiving any SIP 431 response, a transaction-stateful proxy MUST compare the transaction 432 identifier in that response against its existing transaction state 433 machines. The proxy MUST NOT forward the response if there is no 434 matching transaction state machine. 436 8. Exact changes to RFC3261 438 This section describes exactly the same changes as above, but shows 439 exactly which text in RFC3261 is affected. 441 Section 13.3.1.4 paragraph 4 is replaced entirely by 443 Once the response has been constructed, it is passed to the INVITE 444 server transaction. In order to ensure reliable end-to-end 445 transport of the response, it is necessary to periodically pass 446 the response directly to the transport until the ACK arrives. The 447 2xx response is passed to the transport with an interval that 448 starts at T1 seconds and doubles for each retransmission until it 449 reaches T2 seconds (T1 and T2 are defined in Section 17). 450 Response retransmissions cease when an ACK request for the 451 response is received. This is independent of whatever transport 452 protocols are used to send the response. 454 Section 16.7 paragraphs 1 and 2 are replaced entirely by 456 When a response is received by an element, it first tries to 457 locate a client transaction (Section 17.1.3) matching the 458 response. If a transaction is found, the response is handed to 459 the client transaction. If none is found, the element MUST NOT 460 forward the response. 462 Section 16.7, part 9, first paragraph. Replace this sentence 464 If the server transaction is no longer available to handle the 465 transmission, the element MUST forward the response statelessly by 466 sending it to the server transport. 468 with 470 If the server transaction is no longer available to handle the 471 transmission, the response is simply discarded. 473 8.4. Pages 126 through 128 475 Section 17.1.1.2. Replace paragraph 7 (starting "When in either") 476 through the end of the section with 478 When in either the "Calling" or "Proceeding" states, reception of 479 a response with status code from 300-699 MUST cause the client 480 transaction to transition to "Completed". The client transaction 481 MUST pass the received response up to the TU, and the client 482 transaction MUST generate an ACK request, even if the transport is 483 reliable (guidelines for constructing the ACK from the response 484 are given in Section 17.1.1.3) and then pass the ACK to the 485 transport layer for transmission. The ACK MUST be sent to the 486 same address, port, and transport to which the original request 487 was sent. 489 The client transaction MUST start timer D when it enters the 490 "Completed" state for any reason, with a value of at least 32 491 seconds for unreliable transports, and a value of zero seconds for 492 reliable transports. Timer D reflects the amount of time that the 493 server transaction can remain in the "Completed" state when 494 unreliable transports are used. This is equal to Timer H in the 495 INVITE server transaction, whose default is 64*T1, and is also 496 equal to the time a UAS core will wait for an ACK once it sends a 497 2xx response. However, the client transaction does not know the 498 value of T1 in use by the server transaction or any downstream UAS 499 cores, so an absolute minimum of 32s is used instead of basing 500 Timer D on T1. 502 Any retransmissions of a response with status code 300-699 that 503 are received while in the "Completed" state MUST cause the ACK to 504 be re-passed to the transport layer for retransmission, but the 505 newly received response MUST NOT be passed up to the TU. 507 A retransmission of the response is defined as any response which 508 would match the same client transaction based on the rules of 509 Section 17.1.3. 511 If timer D fires while the client transaction is in the 512 "Completed" state, the client transaction MUST move to the 513 "Terminated" state. 515 When a 2xx response is received while in either the "Calling" or 516 "Proceeding" states, the client transaction MUST transition to the 517 "Accepted" state, and Timer M MUST be started with a value of 518 64*T1. The 2xx response MUST be passed up to the TU. The client 519 transaction MUST NOT generate an ACK to the 2xx response - its 520 handling is delegated to the TU. A UAC core will send an ACK to 521 the 2xx response using a new transaction. A proxy core will 522 always forward the 2xx response upstream. 524 The purpose of the "Accepted" state is to allow the client 525 transaction to continue to exist to receive, and pass to the TU, 526 any retransmissions of the 2xx response and any additional 2xx 527 responses from other branches of the INVITE if it forked 528 downstream. Timer M reflects the amount of time that transaction 529 user will wait for such messages. 531 Any 2xx responses matching this client transaction that are 532 received while in the "Accepted" state MUST be passed up to the 533 TU. The client transaction MUST NOT generate an ACK to the 2xx 534 response. The client transaction takes no further action. 536 If timer M fires while the client transaction is in the "Accepted" 537 state, the client transaction MUST move to the "Terminated" state. 539 The client transaction MUST be destroyed the instant it enters the 540 "Terminated" state. 542 Replace Figure 5 with 543 |INVITE from TU 544 Timer A fires |INVITE sent Timer B fires 545 Reset A, V or Transport Err. 546 INVITE sent +-----------+ inform TU 547 +---------| |--------------------------+ 548 | | Calling | | 549 +-------->| |-----------+ | 550 300-699 +-----------+ 2xx | | 551 ACK sent | | 2xx to TU | | 552 resp. to TU | |1xx | | 553 +-----------------------------+ |1xx to TU | | 554 | | | | 555 | 1xx V | | 556 | 1xx to TU +-----------+ | | 557 | +---------| | | | 558 | | |Proceeding | | | 559 | +-------->| | | | 560 | +-----------+ 2xx | | 561 | 300-699 | | 2xx to TU | | 562 | ACK sent, +--------+ +---------------+ | 563 | resp. to TU| | | 564 | | | | 565 | V V | 566 | +-----------+ +----------+ | 567 +------------->| |Transport Err. | | | 568 | Completed |Inform TU | Accepted | | 569 +--| |-------+ | |-+ | 570 300-699 | +-----------+ | +----------+ | | 571 ACK sent| ^ | | | ^ | | 572 | | | | | | | | 573 +----+ | | | +-----+ | 574 |Timer D fires | Timer M fires| 2xx | 575 |- | - | 2xx to TU | 576 +--------+ | +-----------+ | 577 NOTE: V V V | 578 transitions +------------+ | 579 labeled with | | | 580 the event | Terminated |<-----------------------+ 581 over the action | | 582 to take +------------+ 584 Figure 4: INVITE client transaction 586 8.5. Pages 134 to 135 588 Section 17.2.1 paragraph 4 is replaced with 590 If, while in the "Proceeding" state, the TU passes a 2xx response 591 to the server transaction, the server transaction MUST pass this 592 response to the transport layer for transmission. It is not 593 retransmitted by the server transaction; retransmissions of 2xx 594 responses are handled by the TU. The server transaction MUST then 595 transition to the "Accepted" state. 597 Replace Figure 7 with 598 |INVITE 599 |pass INV to TU 600 INVITE V send 100 if TU won't in 200ms 601 send response+------------+ 602 +--------| |--------+ 101-199 from TU 603 | | | | send response 604 +------->| |<-------+ 605 | Proceeding | 606 | |--------+ Transport Err. 607 | | | Inform TU 608 | |<-------+ 609 +------------+ 610 300-699 from TU | |2xx from TU 611 send response | |send response 612 +--------------+ +------------+ 613 | | 614 INVITE V Timer G fires | 615 send response +-----------+ send response | 616 +--------| |--------+ | 617 | | | | | 618 +------->| Completed |<-------+ INVITE | Transport Err. 619 | | - | Inform TU 620 +--------| |----+ +-----+ | +---+ 621 | +-----------+ | ACK | | v | v 622 | ^ | | - | +------------+ 623 | | | | | | |---+ ACK 624 +----------+ | | +->| Accepted | | to TU 625 Transport Err. | | | |<--+ 626 Inform TU | V +------------+ 627 | +-----------+ | ^ | 628 | | | | | | 629 | | Confirmed | | +-----+ 630 | | | | 2xx from TU 631 Timer H fires | +-----------+ | send response 632 - | | | 633 | | Timer I fires | 634 | | - | Timer L fires 635 | V | - 636 | +------------+ | 637 | | |<----+ 638 +------->| Terminated | 639 | | 640 +------------+ 642 Figure 5: INVITE server transaction 644 Section 17.2.1 - Replace the last paragraph (starting "Once the 645 transaction") with 647 The purpose of the "Accepted" state is to absorb retransmissions 648 of an accepted INVITE request. Any such retransmissions are 649 absorbed entirely within the server transaction. They are not 650 passed up to the TU since any downstream UAS cores that accepted 651 the request have taken responsibility for reliability and will 652 already retransmit their 2xx responses if neccessary. 654 While in the "Accepted" state, if the TU passes a 2xx response, 655 the server transaction MUST pass the response to the transport 656 layer for transmission. 658 When the INVITE server transaction enters the "Accepted" state, 659 Timer L MUST be set to fire in 64*T1 for all transports. This 660 value matches both Timer B in the next upstream client state 661 machine (the amount of time the previous hop will wait for a 662 response when no provisionals have been sent) and the amount of 663 time this (or any downstream) UAS core might be retransmitting the 664 2xx while waiting for an ACK. If an ACK is received while the 665 INVITE server transaction is in the "Accepted" state, then the ACK 666 must be passed up to the TU. If Timer L fires while the INVITE 667 server transaction is in the "Accepted" state, the transaction 668 MUST transition to the "Terminated" state. 670 Once the transaction is in the "Terminated" state, it MUST be 671 destroyed immediately. 673 Section 17.2.4 - Replace the second paragraph with 675 First, the procedures in [4] are followed, which attempt to 676 deliver the response to a backup. If those should all fail, based 677 on the definition of failure in [4], the server transaction SHOULD 678 inform the TU that a failure has occurred, and MUST remain in the 679 current state. 681 Section 18.1.2 - Replace the second paragraph with 682 The client transport uses the matching procedures of Section 683 17.1.3 to attempt to match the response to an existing 684 transaction. If there is a match, the response MUST be passed to 685 that transaction. Otherwise, any element other than a stateless 686 proxy MUST silently discard the response. 688 Section 18.2.1 - Replace the last paragraph with 690 Next, the server transport attempts to match the request to a 691 server transaction. It does so using the matching rules described 692 in Section 17.2.3. If a matching server transaction is found, the 693 request is passed to that transaction for processing. If no match 694 is found, the request is passed to the core, which may decide to 695 construct a new server transaction for that request. 697 Add to Table 4: 699 Timer L 64*T1 Section 17.2.1 Wait time for 700 accepted INVITE 701 request retransmits 703 Timer M 64*T1 Section 17.1.1 Wait time for 704 retransmission of 705 2xx to INVITE or 706 additional 2xx from 707 other branches of 708 a forked INVITE 710 9. IANA Considerations 712 None. 714 10. Security Considerations 716 This document makes two changes to the Session Initiation Protocol to 717 address the error discussed in Section 3. It changes the behavior of 718 both the client and server INVITE transaction state machines, and it 719 changes the way "stray" responses (those that don't match any 720 existing transaction) are handled at transaction stateful elements. 722 The changes to the state machines cause elements to hold onto each 723 accepted INVITE transaction state longer (32 seconds) than what was 724 specified in RFC 3261. This will have a direct impact on the amount 725 of work an attacker leveraging state exhaustion will have to exert 726 against the system. However, this additional state is necessary to 727 achieve correct operation. 729 RFC 3261 required SIP proxies to forward any stray 2xx class 730 responses to an INVITE request upstream statelessly. As a result, 731 conformant proxies can be forced to forward packets (that look 732 sufficiently like SIP responses) to destinations of the sender's 733 choosing. Section 3 discusses some of the malicious behavior this 734 enables. This document reverses the stateless forwarding 735 requirement, making it a violation of the specification to forward 736 stray responses. 738 RFC 3261 defines a "stateless proxy" which forwards requests and 739 responses without creating or maintaining any transaction state. The 740 requirements introduced in this document do not change the behavior 741 of these elements in any way. Stateless proxies are inherently 742 vulnerable to the abuses discussed in Section 3. One way operators 743 might mitigate this vulnerability is to carefully control which peer 744 elements can present traffic to a given stateless proxy. 746 The changes introduced by this document are backward-compatible. 747 Transaction behavior will be no less correct, and possible more 748 correct, when only one peer in a transaction implements these 749 changes. Except for the considerations mentioned earlier in this 750 section, introducing elements implementing these changes into 751 deployments with RFC 3261 implementations adds no additional security 752 concerns. 754 11. Acknowledgments 756 Pekka Pessi reported the improper handling of INVITE retransmissions. 757 Brett Tate performed a careful review uncovering the need for the 758 Accepted state and Timer M in the client transaction state machine. 759 Jan Kolomaznik noticed that a server transaction should let a TU know 760 about transport errors when it attempts to send a 2xx-class response. 761 Michael Procter corrected several nits. 763 12. Normative References 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", BCP 14, RFC 2119, March 1997. 768 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 769 A., Peterson, J., Sparks, R., Handley, M., and E. 770 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 771 June 2002. 773 Authors' Addresses 775 Robert Sparks 776 Tekelec 777 17210 Campbell Road 778 Suite 250 779 Dallas, Texas 75252 780 USA 782 Email: RjS@nostrum.com 784 Theo Zourzouvillys 785 Skype 786 3rd Floor 787 8000 Marina Blvd 788 Brisbane, California 84005 789 US 791 Email: theo@crazygreek.co.uk