idnits 2.17.1 draft-sparks-sip-invfix-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (Feb 28, 2009) is 5534 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 651 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) Feb 28, 2009 5 Intended status: Standards Track 6 Expires: September 1, 2009 8 Correct transaction handling for 200 responses to Session Initiation 9 Protocol INVITE requests 10 draft-sparks-sip-invfix-03 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 1, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document normatively updates RFC 3261, the Session Initiation 49 Protocol (SIP), to address an error in the specified handling of 50 success (200 class) responses to INVITE requests. Elements following 51 RFC 3261 exactly will misidentify retransmissions of the request as a 52 new, unassociated, request. The correction involves modifying the 53 INVITE transaction state machines. The correction also changes the 54 way responses that cannot be matched to an existing transaction are 55 handled to address a security risk. 57 Table of Contents 59 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Reason for Change . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Summary of Change . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Consequences if Not Approved . . . . . . . . . . . . . . . . . 4 64 6. The Change . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 7. Change Details . . . . . . . . . . . . . . . . . . . . . . . . 5 66 7.1. UAS Impacts . . . . . . . . . . . . . . . . . . . . . . . 5 67 7.2. UAC Impacts . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.3. Proxy Considerations . . . . . . . . . . . . . . . . . . . 10 69 8. Exact changes to RFC3261 . . . . . . . . . . . . . . . . . . . 11 70 8.1. Page 85 . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.2. Page 107 . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 8.3. Page 114 . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 8.4. Pages 126 through 128 . . . . . . . . . . . . . . . . . . 12 74 8.5. Pages 134 to 135 . . . . . . . . . . . . . . . . . . . . . 15 75 8.6. Page 136 . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 8.7. Page 137 . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 8.8. Page 141 . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 8.9. Page 144 . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8.10. Page 146 . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 8.11. Page 265 . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 1. Conventions and Definitions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC-2119 [RFC2119]. 95 2. Introduction 97 This document describes an essential correction to the Session 98 Initiation Protocol (SIP), defined in [RFC3261], using the process 99 defined in [I-D.drage-sip-essential-correction]. The change 100 addresses an error in the handling of 200 class responses to INVITE 101 requests that leads to retransmissions of the INVITE being treated as 102 new requests and forbids forwarding stray INVITE responses. 104 3. Reason for Change 106 One use of the INVITE method in SIP is to establish new sessions. 107 These "initial" INVITEs may fork at intermediaries, and more than one 108 receiving endpoint may choose to accept the request. SIP is designed 109 such that the requester receives all of these success responses. 111 Two sets of requirements in [RFC3261] work together to allow multiple 112 200s to be processed correctly by the requester. First, all elements 113 are required to immediately destroy any INVITE client transaction 114 state upon forwarding a matching 200 OK response. This requirement 115 applies to both proxies and user agents (proxies forward the response 116 upstream, the transaction layer at user agents forward the response 117 to its "UA core"). Second, all proxies are required to statelessly 118 forward any 200 OK responses that do not match an existing 119 transaction, also called stray responses, upstream. The transaction 120 layer at user agents is required to forward these responses to its UA 121 core. Logic in the UA core deals with acknowledging each of these 122 responses. 124 This technique for specifying the behavior was chosen over adjusting 125 INVITE client transaction state machines as a simpler way to specify 126 the correct behavior. 128 Over time, implementation experience demonstrated the existing text 129 is in error. Once any element with a server transaction (say, a 130 proxy in the path of the INVITE) deletes that transaction state, any 131 retransmission of the INVITE will be treated as a new request, 132 potentially forwarded to different locations than the original. Many 133 implementations in the field have made proprietary adjustments to 134 their transaction logic to avoid this error. 136 The requirement to statelessly forward stray responses has also been 137 identified as a security risk. Through it, elements compliant to 138 [RFC3261] are compelled to do work (forward packets) that is not 139 protected by the admission policies applied to requests. This can be 140 leveraged to, for instance, use a SIP proxy as an anonymizing 141 forwarder of packets in a distributed DOS attack. General internet 142 endpoints can also collude to tunnel non-SIP content through such 143 proxies by wrapping them in an SIP response envelope. 145 4. Summary of Change 147 This correction document updates [RFC3261], adding a state and 148 changing the transitions in the INVITE client state machine such that 149 the INVITE client transaction remains in place to receive multiple 150 200 OK responses. It adds a state to the INVITE server state machine 151 to absorb retransmissions of the INVITE after a 200 OK response has 152 been sent. It modifies state transitions in the INVITE server state 153 machine to absorb retransmissions of the INVITE request after 154 encountering a unrecoverable transport error when sending a response. 155 It also forbids forwarding stray responses to INVITE requests (not 156 just 200 OK responses), which RFC3261 requires. 158 5. Consequences if Not Approved 160 Implementations strictly conformant to [RFC3261] will process 161 retransmitted initial INVITE requests as new requests. Proxies may 162 forward them to different locations than the original. Proxies may 163 also be used as anonymizing forwarders of bulk traffic. 165 6. The Change 167 An element sending or receiving a 200 OK to an INVITE transaction 168 MUST NOT destroy any matching INVITE transaction state. This state 169 is necessary to ensure correct processing of retransmissions of the 170 request and the retransmission of the 200 OK and ACK that follow. 172 An element encountering an unrecoverable tranport error when trying 173 to send a response to an INVITE request MUST NOT immediately destroy 174 the associated INVITE server transaction state. This state is 175 necessary to ensure correct processing of retransmissions of the 176 request. 178 When receiving any SIP response, a transaction-stateful proxy MUST 179 compare the transaction identifier in that response against its 180 existing transaction state machines. The proxy MUST NOT forward the 181 response if there is no matching transaction state machine. 183 7. Change Details 185 These changes impact requirements in several sections of RFC3261. 186 The exact effect on that text is detailed in Section 8. This section 187 describes the details of the change, particularly the impact on the 188 INVITE state machines, more succinctly to facilitate review and 189 simplify implementation. 191 7.1. UAS Impacts 193 To allow a UAS to recognize retransmissions of an INVITE as 194 retransmissions instead of new requests, a new state, "Accepted", is 195 added to the INVITE server transaction state machine. A new timer, 196 Timer L, is also added to ultimately allow the state machine to 197 terminate. A UAS in the "Proceeding" state will transition to the 198 "Accepted" state when it issues a 2xx response, and will remain in 199 that state just long enough to absorb any retransmissions of the 200 INVITE. 202 If the UAS's TU issues a 2xx response for this transaction while the 203 state machine is in the "Proceeding" state, it MUST transition to the 204 "Accepted" state and set Timer L to 64*T1. 206 While in the "Accepted" state, any retransmissions of the INVITE 207 received will match this transaction state machine and will be 208 absorbed by the machine without changing its state. These 209 retransmissions are not passed onto the TU. RFC3261 requires the TU 210 to periodically retransmit the 2xx response until it receives an ACK. 211 The server transaction MUST NOT generate 2xx retransmissions on its 212 own. Any retransmission of the 2xx response passed from the TU to 213 the transaction while in the "Accepted" state MUST be passed to the 214 transport layer for transmission. 216 When Timer L fires and the state machine is in the "Accepted" state, 217 the machine MUST transition to the "Terminated" state. Once the 218 transaction is in the "Terminated" state, it MUST be destroyed 219 immediately. Timer L reflects the amount of time the TU will wait to 220 receive an ACK for the 2xx it is emitting before considering the 221 transaction failed. 223 A UAS MUST NOT discard transaction state based only on encountering a 224 non-recoverable transport error when sending a response. Instead the 225 assocated INVITE server transaction state machine MUST remain in its 226 current state. (Timers will eventually cause it to transition to the 227 Terminated state). This allows retransmissions of the INVITE to be 228 absorbed instead of being processed as a new request. 230 Figure 1 and Figure 2 graphically show the parts of the INVITE server 231 state machine that has changed. The entire new INVITE server state 232 machine is shown in Figure 5. 234 BEFORE AFTER 236 +-----------+ +-----------+ 237 | | | | 238 | Proceeding| | Proceeding| 239 | | | | 240 | | | | 241 | | | | 242 | | | | 243 +-----------+ +-----------+ 244 |2xx from TU |2xx from TU 245 |send response |send response 246 +-------------->+ +------->+ 247 | | 248 | | 249 | | 250 | | Transport 251 | INVITE | Error 252 | - | Inform TU 253 | +-----+ | +--+ 254 | | | V | v 255 | | +------------+ 256 | | | | 257 | +->| Accepted | 258 | | | 259 | +------------+ 260 | | ^ | 261 | +--+ | | 262 | | +-----+ 263 | | 2xx from TU 264 | | send response 265 | | 266 | | Timer L fires 267 | | - 268 | | 269 | V 270 +-----------+ | +------------+ 271 | | | | | 272 | Terminated|<-----------+ | Terminated | 273 | | | | 274 +-----------+ +------------+ 276 Figure 1: Changes to the INVITE server transaction state machine when 277 sending 2xx 279 BEFORE AFTER 281 +-----------+ +------------+ 282 | | | | 283 | Proceeding| | Proceeding | Transport Err. 284 | | | | Inform TU 285 | | Transport Err. | |----------+ 286 | | Inform TU | | | 287 | |--------------->+ | |<---------+ 288 +-----------+ | +------------+ 289 | 290 | 291 | 292 | 293 | Transport Err. 294 +-----------+ | +-----------+ Inform TU 295 | | | | |---------+ 296 | Completed | | | Completed | | 297 | | | | |<--------+ 298 +-----------+ | +-----------+ 299 | | 300 | | 301 +------------------>+ 302 Transport Err.| 303 Inform TU | 304 | 305 | 306 | 307 | 308 | 309 | 310 | 311 | 312 | 313 +-----------+ | 314 | | | 315 | Terminated|<---------------+ 316 | | 317 +-----------+ 319 Figure 2: Changes to the INVITE server transaction state machine on 320 encountering transport error 322 7.2. UAC Impacts 324 In order to correctly distinguish retransmissions of 2xx responses 325 from stray 2xx responses, the INVITE client state machine is modified 326 to not transition immediately to "Terminated" on receipt of a 2xx 327 response. Instead, the machine will transition to a new "Accepted" 328 state, and remain there just long enough, determined by a new timer 329 M, to receive and pass to the TU any retransmissions of the 2xx 330 response or any additional 2xx responses from other branches of a 331 downstream fork of the matching request. If a 2xx response is 332 received while the client INVITE state machine is in the "Calling" or 333 "Proceeding" states, it MUST transition to the "Accepted" state, pass 334 the 2xx response to the TU, and set Timer M to 64*T1. A 2xx response 335 received while in the "Accepted" state MUST be passed to the TU and 336 the machine remains in the "Accepted" state. The client transaction 337 MUST NOT generate an ACK to any 2xx response on its own. The TU 338 responsible for the transaction will generate the ACK. 340 When Timer M fires and the state machine is in the "Accepted" state, 341 the machine MUST transition to the "Terminated" state. Once the 342 transaction is in the "Terminated" state, it MUST be destroyed 343 immediately. 345 Any response received which does not match an existing client 346 transaction state machine is simply dropped. (Implementations are, 347 of course, free to log or do other implementation specific things 348 with such responses, but the implementer should be sure to consider 349 the impact of large numbers of malicious stray responses). 351 Note that it is not necessary to preserve client transaction state 352 upon the detection of unrecoverable transport errors. Existing 353 requirements ensure the TU has been notified, and the new 354 requirements in this document ensure that any received retransmitted 355 response will be dropped since there will no longer be any matching 356 transaction state. 358 Figure 3 graphically shows the part of the INVITE client state 359 machine that has changed. The entire new INVITE client state machine 360 is shown in Figure 4. 362 +-----------+ +-----------+ 363 | | | | 364 | Calling | | Calling | 365 | |----------->+ | |-----------+ 366 +-----------+ 2xx | +-----------+ 2xx | 367 2xx to TU | 2xx to TU | 368 | | 369 | | 370 | | 371 | | 372 +-----------+ | +-----------+ | 373 | | | | | | 374 |Proceeding |----------->| |Proceeding |---------->| 375 | | 2xx | | | 2xx | 376 +-----------+ 2xx to TU | +-----------+ 2xx to TU | 377 | | 378 | | 379 | | 380 | V 381 | +-----------+ 382 | | | 383 | | Accepted | 384 | +---| | 385 | 2xx | +-----------+ 386 | 2xx to TU | ^ | 387 | | | | 388 | +-----+ | 389 | | 390 | +-----------------+ 391 | | Timer M fires 392 | | - 393 | V 394 +-----------+ | +-----------+ 395 | | | | | 396 | Terminated|<-----------+ | Terminated| 397 | | | | 398 +-----------+ +-----------+ 400 Figure 3: Changes to the INVITE client transaction state machine 402 7.3. Proxy Considerations 404 A direct consequence of the change to the UAC state machine is that a 405 transaction-stateful proxy will not foward any stray INVITE 406 responses. When receiving any SIP response, a transaction-stateful 407 proxy MUST compare the transaction identifier in that response 408 against its existing transaction state machines. The proxy MUST NOT 409 forward the response if there is no matching transaction state 410 machine. 412 8. Exact changes to RFC3261 414 This section describes exactly the same changes as above, but shows 415 exactly which text in RFC3261 is affected. 417 Section 13.3.1.4 paragraph 4 is replaced entirely by 419 Once the response has been constructed, it is passed to the INVITE 420 server transaction. In order to ensure reliable end-to-end 421 transport of the response, it is necessary to periodically pass 422 the response directly to the transport until the ACK arrives. The 423 2xx response is passed to the transport with an interval that 424 starts at T1 seconds and doubles for each retransmission until it 425 reaches T2 seconds (T1 and T2 are defined in Section 17). 426 Response retransmissions cease when an ACK request for the 427 response is received. This is independent of whatever transport 428 protocols are used to send the response. 430 Section 16.7 paragraphs 1 and 2 are replaced entirely by 432 When a response is received by an element, it first tries to 433 locate a client transaction (Section 17.1.3) matching the 434 response. If a transaction is found, the response is handed to 435 the client transaction. If none is found, the element MUST NOT 436 forward the response. 438 Section 16.7, part 9, first paragraph. Replace this sentence 440 If the server transaction is no longer available to handle the 441 transmission, the element MUST forward the response statelessly by 442 sending it to the server transport. 444 with 446 If the server transaction is no longer available to handle the 447 transmission, the response is simply discarded. 449 8.4. Pages 126 through 128 451 Section 17.1.1.2. Replace paragraph 7 (starting "When in either") 452 through the end of the section with 454 When in either the "Calling" or "Proceeding" states, reception of 455 a response with status code from 300-699 MUST cause the client 456 transaction to transition to "Completed". The client transaction 457 MUST pass the received response up to the TU, and the client 458 transaction MUST generate an ACK request, even if the transport is 459 reliable (guidelines for constructing the ACK from the response 460 are given in Section 17.1.1.3) and then pass the ACK to the 461 transport layer for transmission. The ACK MUST be sent to the 462 same address, port, and transport to which the original request 463 was sent. 465 The client transaction MUST start timer D when it enters the 466 "Completed" state for any reason, with a value of at least 32 467 seconds for unreliable transports, and a value of zero seconds for 468 reliable transports. Timer D reflects the amount of time that the 469 server transaction can remain in the "Completed" state when 470 unreliable transports are used. This is equal to Timer H in the 471 INVITE server transaction, whose default is 64*T1, and is also 472 equal to the time a UAS core will wait for an ACK once it sends a 473 2xx response. However, the client transaction does not know the 474 value of T1 in use by the server transaction or any downstream UAS 475 cores, so an absolute minimum of 32s is used instead of basing 476 Timer D on T1. 478 Any retransmissions of a response with status code 300-699 that 479 are received while in the "Completed" state MUST cause the ACK to 480 be re-passed to the transport layer for retransmission, but the 481 newly received response MUST NOT be passed up to the TU. 483 A retransmission of the response is defined as any response which 484 would match the same client transaction based on the rules of 485 Section 17.1.3. 487 If timer D fires while the client transaction is in the 488 "Completed" state, the client transaction MUST move to the 489 "Terminated" state. 491 When a 2xx response is received while in either the "Calling" or 492 "Proceeding" states, the client transaction MUST transition to the 493 "Accepted" state, and Timer M MUST be started with a value of 494 64*T1. The 2xx response MUST be passed up to the TU. The client 495 transaction MUST NOT generate an ACK to the 2xx response - its 496 handling is delegated to the TU. A UAC core will send an ACK to 497 the 2xx response using a new transaction. A proxy core will 498 always forward the 2xx response upstream. 500 The purpose of the "Accepted" state is to allow the client 501 transaction to continue to exist to receive, and pass to the TU, 502 any retransmissions of the 2xx response and any additional 2xx 503 responses from other branches of the INVITE if it forked 504 downstream. Timer M reflects the amount of time that transaction 505 user will wait for such messages. 507 Any 2xx responses matching this client transaction that are 508 received while in the "Accepted" state MUST be passed up to the 509 TU. The client transaction MUST NOT generate an ACK to the 2xx 510 response. The client transaction takes no further action. 512 If timer M fires while the client transaction is in the "Accepted" 513 state, the client transaction MUST move to the "Terminated" state. 515 The client transaction MUST be destroyed the instant it enters the 516 "Terminated" state. 518 Replace Figure 5 with 519 |INVITE from TU 520 Timer A fires |INVITE sent Timer B fires 521 Reset A, V or Transport Err. 522 INVITE sent +-----------+ inform TU 523 +---------| |--------------------------+ 524 | | Calling | | 525 +-------->| |-----------+ | 526 300-699 +-----------+ 2xx | | 527 ACK sent | | 2xx to TU | | 528 resp. to TU | |1xx | | 529 +-----------------------------+ |1xx to TU | | 530 | | | | 531 | 1xx V | | 532 | 1xx to TU +-----------+ | | 533 | +---------| | | | 534 | | |Proceeding | | | 535 | +-------->| | | | 536 | +-----------+ 2xx | | 537 | 300-699 | | 2xx to TU | | 538 | ACK sent, +--------+ +---------------+ | 539 | resp. to TU| | | 540 | | | | 541 | V V | 542 | +-----------+ +----------+ | 543 +------------->| |Transport Err. | | | 544 | Completed |Inform TU | Accepted | | 545 +--| |-------+ | |-+ | 546 300-699 | +-----------+ | +----------+ | | 547 ACK sent| ^ | | | ^ | | 548 | | | | | | | | 549 +----+ | | | +-----+ | 550 |Timer D fires | Timer M fires| 2xx | 551 |- | - | 2xx to TU | 552 +--------+ | +-----------+ | 553 NOTE: V V V | 554 transitions +------------+ | 555 labeled with | | | 556 the event | Terminated |<-----------------------+ 557 over the action | | 558 to take +------------+ 560 Figure 4: INVITE client transaction 562 8.5. Pages 134 to 135 564 Section 17.2.1 paragraph 4 is replaced with 566 If, while in the "Proceeding" state, the TU passes a 2xx response 567 to the server transaction, the server transaction MUST pass this 568 response to the transport layer for transmission. It is not 569 retransmitted by the server transaction; retransmissions of 2xx 570 responses are handled by the TU. The server transaction MUST then 571 transition to the "Accepted" state. 573 Replace Figure 7 with 574 |INVITE 575 |pass INV to TU 576 INVITE V send 100 if TU won't in 200ms 577 send response+------------+ 578 +--------| |--------+ 101-199 from TU 579 | | | | send response 580 +------->| |<-------+ 581 | Proceeding | 582 | |--------+ Transport Err. 583 | | | Inform TU 584 | |<-------+ 585 +------------+ 586 300-699 from TU | |2xx from TU 587 send response | |send response 588 +--------------+ +------------+ 589 | | 590 INVITE V Timer G fires | 591 send response +-----------+ send response | 592 +--------| |--------+ | 593 | | | | | 594 +------->| Completed |<-------+ INVITE | Transport Err. 595 | | - | Inform TU 596 +--------| |----+ +-----+ | +---+ 597 | +-----------+ | ACK | | v | v 598 | ^ | | - | +------------+ 599 | | | | | | | 600 +----------+ | | +->| Accepted | 601 Transport Err. | | | | 602 Inform TU | V +------------+ 603 | +-----------+ | ^ | 604 | | | | | | 605 | | Confirmed | | +-----+ 606 | | | | 2xx from TU 607 Timer H fires | +-----------+ | send response 608 - | | | 609 | | Timer I fires | 610 | | - | Timer L fires 611 | V | - 612 | +------------+ | 613 | | |<----+ 614 +------->| Terminated | 615 | | 616 +------------+ 618 Figure 5: INVITE server transaction 620 Section 17.2.1 - Replace the last paragraph (starting "Once the 621 transaction") with 623 The purpose of the "Accepted" state is to absorb retransmissions 624 of an accepted INVITE request. Any such retransmissions are 625 absorbed entirely within the server transaction. They are not 626 passed up to the TU since any downstream UAS cores that accepted 627 the request have taken responsibility for reliability and will 628 already retransmit their 2xx responses if neccessary. 630 While in the "Accepted" state, if the TU passes a 2xx response, 631 the server transaction MUST pass the response to the transport 632 layer for transmission. 634 When the INVITE server transaction enters the "Accepted" state, 635 Timer L MUST be set to fire in 64*T1 for all transports. This 636 value matches both Timer B in the next upstream client state 637 machine (the amount of time the previous hop will wait for a 638 response when no provisionals have been sent) and the amount of 639 time this (or any downstream) UAS core might be retransmitting the 640 2xx while waiting for an ACK. If Timer L fires while the INVITE 641 server transaction is in the "Accepted" state, the transaction 642 MUST transition to the "Terminated" state. 644 Once the transaction is in the "Terminated" state, it MUST be 645 destroyed immediately. 647 Section 17.2.4 - Replace the second paragraph with 649 First, the procedures in [4] are followed, which attempt to 650 deliver the response to a backup. If those should all fail, based 651 on the definition of failure in [4], the server transaction SHOULD 652 inform the TU that a failure has occurred, and MUST remain in the 653 current state. 655 Section 18.1.2 - Replace the second paragraph with 657 The client transport uses the matching procedures of Section 658 17.1.3 to attempt to match the response to an existing 659 transaction. If there is a match, the response MUST be passed to 660 that transaction. Otherwise, any element other than a stateless 661 proxy MUST silently discard the response. 663 Section 18.2.1 - Replace the last paragraph with 665 Next, the server transport attempts to match the request to a 666 server transaction. It does so using the matching rules described 667 in Section 17.2.3. If a matching server transaction is found, the 668 request is passed to that transaction for processing. If no match 669 is found, the request is passed to the core, which may decide to 670 construct a new server transaction for that request. 672 Add to Table 4: 674 Timer L 64*T1 Section 17.2.1 Wait time for 675 accepted INVITE 676 request retransmits 678 Timer M 64*T1 Section 17.1.1 Wait time for 679 retransmission of 680 2xx to INVITE or 681 additional 2xx from 682 other branches of 683 a forked INVITE 685 9. IANA Considerations 687 None. 689 10. Security Considerations 691 This document makes two changes to the Session Initiation Protocol to 692 address the error discussed in Section 3. It changes the behavior of 693 both the client and server INVITE transaction state machines, and it 694 changes the way "stray" responses (those that don't match any 695 existing transaction) are handled at transaction stateful elements. 697 The changes to the state machines cause elements to hold onto each 698 accepted INVITE transaction state longer (32 seconds) than what was 699 specified in RFC 3261. This will have a direct impact on the amount 700 of work an attacker leveraging state exhaustion will have to exert 701 against the system. However, this additional state is necessary to 702 achieve correct operation. 704 RFC 3261 required SIP proxies to forward any stray 200 class 705 responses to an INVITE request upstream statelessly. As a result, 706 conformant proxies can be forced to forward packets (that look 707 sufficiently like SIP responses) to destinations of the sender's 708 choosing. Section 3 discusses some of the malicious behavior this 709 enables. This document reverses the stateless forwarding 710 requirement, making it a violation of the specification to forward 711 stray responses. 713 RFC 3261 defines a "stateless proxy" which forwards requests and 714 responses without creating or maintaining any transaction state. The 715 requirements introduced in this document do not change the behavior 716 of these elements in any way. Stateless proxies are inherently 717 vulnerable to the abuses discussed in Section 3. One way operators 718 might mitigate this vulnerability is to carefully control which peer 719 elements can present traffic to a given stateless proxy. 721 The changes introduced by this document are backward-compatible. 722 Transaction behavior will be no less correct, and possible more 723 correct, when only one peer in a transaction implements these 724 changes. Except for the considerations mentioned earlier in this 725 section, introducing elements implementing these changes into 726 deployments with RFC 3261 implementations adds no additional security 727 concerns. 729 11. Acknowledgments 731 Pekka Pessi reported the improper handling of INVITE retransmissions. 732 Bret Tate performed a careful review uncovering the need for the 733 Accepted state and Timer M in the client transaction state machine. 734 Jan Kolomaznik noticed that a server transaction should let a TU know 735 about transport errors when it attempts to send a 200-class response. 736 Michael Proctor corrected several nits. 738 12. References 740 12.1. Normative References 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, March 1997. 745 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 746 A., Peterson, J., Sparks, R., Handley, M., and E. 747 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 748 June 2002. 750 12.2. Informative References 752 [I-D.drage-sip-essential-correction] 753 Drage, K., "A Process for Handling Essential Corrections 754 to the Session Initiation Protocol (SIP)", 755 draft-drage-sip-essential-correction-03 (work in 756 progress), July 2008. 758 Author's Address 760 Robert Sparks 761 Tekelec 762 17210 Campbell Road 763 Suite 250 764 Dallas, Texas 75252 765 USA 767 Email: RjS@nostrum.com