idnits 2.17.1 draft-ietf-sipcore-keep-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 -- The document date (October 13, 2010) is 4915 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) == Missing Reference: 'RFCXXXX' is mentioned on line 619, but not defined ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track October 13, 2010 5 Expires: April 16, 2011 7 Indication of support for keep-alive 8 draft-ietf-sipcore-keep-07.txt 10 Abstract 12 This specification defines a new Session Initiation Protocol (SIP) 13 Via header field parameter, "keep", which allows adjacent SIP 14 entities to explicitly negotiate usage of the Network Address 15 Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in 16 cases where SIP Outbound is not supported, cannot be applied, or 17 where usage of keep-alives is not implicitly negotiated as part of 18 the SIP Outbound negotiation. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 16, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Use-case: Dialog from non-registered UAs . . . . . . . . . 3 56 1.2. Use-case: SIP Outbound not supported . . . . . . . . . . . 3 57 1.3. Use-case: SIP dialog initiated Outbound flows . . . . . . 3 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. User Agent and Proxy behavior . . . . . . . . . . . . . . . . 4 61 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Lifetime of keep-alives . . . . . . . . . . . . . . . . . 5 63 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2.2. Keep-alives associated with registration . . . . . . . 5 65 4.2.3. Keep-alives associated with dialog . . . . . . . . . . 6 66 4.3. Behavior of a SIP entity willing to send keep-alives . . . 6 67 4.4. Behavior of a SIP entity willing to receive keep-alives . 7 68 5. Keep-alive frequency . . . . . . . . . . . . . . . . . . . . . 8 69 6. Connection reuse . . . . . . . . . . . . . . . . . . . . . . . 9 70 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.2. Keep-alive negotiation associated with registration: 73 UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.3. Keep-alive negotiation associated with dialog: UA-proxy . 11 75 7.4. Keep-alive negotiation associated with dialog: UA-UA . . . 12 76 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 81 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 84 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive 90 mechanisms. Even though the keep-alive mechanisms are separated from 91 the rest of the SIP Outbound mechanism, SIP Outbound does not define 92 a mechanism to explicitly negotiate usage of the keep-alive 93 mechanisms. In some cases usage of keep-alives can be implicitly 94 negotiated as part of the SIP Outbound negotiation. 96 However, there are SIP Outbound use-cases where usage of keep-alives 97 is not implicitly negotiated as part of the SIP Outbound negotiation. 98 In addition, there are cases where SIP Outbound is not supported, or 99 where it cannot be applied, but where there is still a need to be 100 able to negotiate usage of keep-alives. Last, [RFC5626] only allows 101 keep-alives to be negotiated between a UA and an edge proxy, and not 102 between other SIP entities. 104 This specification defines a new Session Initiation Protocol (SIP) 105 [RFC3261] Via header field parameter, "keep", which allows adjacent 106 SIP entities to explicitly negotiate usage of the NAT keep-alive 107 mechanisms defined in SIP Outbound. The "keep" parameter allows SIP 108 entities to indicate willingness to send keep-alives, to indicate 109 willingness to receive keep-alives, and for SIP entities willing to 110 receive keep-alives to provide a recommended keep-alive frequency. 112 The following sections describe use-cases where a mechanism to 113 explicitly negotiate usage of keep-alives is needed. 115 1.1. Use-case: Dialog from non-registered UAs 117 In some cases a User Agent Client (UAC) does not register itself 118 before it establishes a dialog, but in order to maintain NAT bindings 119 open during the lifetime of the dialog it still needs to be able to 120 negotiate sending of keep-alives towards its adjacent downstream SIP 121 entity. A typical example is an emergency call, where a registration 122 is not always required in order to make the call. 124 1.2. Use-case: SIP Outbound not supported 126 In some cases all SIP entities that need to be able to negotiate the 127 usage of keep-alives might not support SIP Outbound. However, they 128 might still support the keep-alive mechanisms defined in SIP 129 Outbound, and need to be able to negotiate usage of them. 131 1.3. Use-case: SIP dialog initiated Outbound flows 133 SIP Outbound allows the establishment of flows using the initial 134 request for a dialog. As specified in [RFC5626], usage of keep- 135 alives is not implicitly negotiated for such flows. 137 2. Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in BCP 14, RFC 2119 142 [RFC2119]. 144 3. Definitions 146 Edge proxy: As defined in [RFC5626], a SIP proxy that is located 147 topologically between the registering User Agent (UA) and the 148 Authoritative Proxy. 150 NOTE: In some deployments the edge proxy might physically be located 151 in the same entity as the Authoritative Proxy. 153 Keep-alives: The keep-alive messages defined in SIP Outbound 154 [RFC5626]. 156 "keep" parameter: A SIP Via header field parameter that a SIP entity 157 can insert in its Via header field of a request to explicitly 158 indicate willingness to send keep-alives towards its adjacent 159 downstream SIP entity. A SIP entity can also insert the header field 160 in a response to explicitly indicate willingness to receive keep- 161 alives from its adjacent upstream SIP entity. 163 SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261]. 165 Adjacent downstream SIP entity: The adjacent SIP entity in the 166 direction towards which a SIP request is sent. 168 Adjacent upstream SIP entity: The adjacent SIP entity in the 169 direction from which a SIP request is received. 171 4. User Agent and Proxy behavior 173 4.1. General 175 This section describes how SIP UAs and proxies negotiate usage of 176 keep-alives associated with a registration, or a dialog, which types 177 of SIP requests can be used in order to negotiate the usage, and the 178 lifetime of the negotiated keep-alives. 180 SIP entities indicate willingness to send keep-alives towards the 181 adjacent downstream SIP entity using SIP requests. The associated 182 responses are used by SIP entities to indicate willingness to receive 183 keep-alives. SIP entities that indicate willingness to receive keep- 184 alives can provide a recommended keep-alive frequency. 186 The procedures to negotiate usage of keep-alives are identical for 187 SIP UAs and proxies. 189 In general, it can be useful for SIP entities to indicate willingness 190 to send keep-alives, even if they are not aware of any necessity for 191 them to send keep-alives, since the adjacent downstream SIP entity 192 might have knowledge about the necessity. Similarly, if the adjacent 193 upstream SIP entity has indicated willingness to send keep-alives, it 194 can be useful for SIP entities to indicate willingness to receive 195 keep-alives, even if they are not aware of any necessity for the 196 adjacent upstream SIP entity to send them. 198 NOTE: Usage of keep-alives is negotiated per direction. If a SIP 199 entity has indicated willingness to receive keep-alives from an 200 adjacent SIP entity, sending of keep-alives towards the same SIP 201 entity needs to be separately negotiated. 203 NOTE: Since there are SIP entities that already use a combination of 204 Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP 205 entities are expected to be able to receive those, this specification 206 does not forbid the sending of double-CRLF keep-alive messages 207 towards an adjacent SIP entity even if usage of keep-alives with that 208 SIP entity has not been negotiated. However, the "keep" parameter is 209 still important in order for a SIP entity to indicate that it 210 supports sending of double-CRLF keep-alive messages, so that the 211 adjacent downstream SIP entity does not use other mechanisms (e.g. 212 short registration refresh intervals) in order to keep NAT bindings 213 open. 215 4.2. Lifetime of keep-alives 217 4.2.1. General 219 The lifetime of negotiated keep-alives depends on whether the keep- 220 alives are associated with a registration or a dialog. This section 221 describes the lifetime of negotiated keep-alives. 223 4.2.2. Keep-alives associated with registration 225 SIP entities use a registration request in order to negotiate usage 226 of keep-alives associated with a registration. Usage of keep-alives 227 can be negotiated when the registration is established, or later 228 during the registration. Once negotiated, keep-alives are sent until 229 the registration is terminated, or until a subsequent registration 230 refresh request is sent or forwarded. When a subsequent registration 231 refresh request is sent or forwarded, if a SIP entity is willing to 232 continue sending keep-alives associated with the registration, usage 233 of keep-alives MUST be re-negotiated. If usage is not successfully 234 re-negotiated, the SIP entity MUST cease sending of keep-alives 235 associated with the registration. 237 In case a SIP entity establishes multiple registration flows 238 [RFC5626], usage of keep-alives needs to be negotiated separately for 239 each individual registration flow. A SIP entity MUST NOT send keep- 240 alives associated with a registration flow for which usage of keep- 241 alives has not been negotiated. 243 4.2.3. Keep-alives associated with dialog 245 SIP entities use an initial request for a dialog, or a mid-dialog 246 target refresh request [RFC3261], in order to negotiate sending and 247 receiving of keep-alives associated with a dialog. Usage of keep- 248 alives can be negotiated when the dialog is established, or later 249 during the lifetime of the dialog. Once negotiated, keep-alives MUST 250 be sent for the lifetime of the dialog, until the dialog is 251 terminated. Once usage of keep-alives associated with a dialog has 252 been negotiated, it is not possible to re-negotiate the usage 253 associated with the dialog. 255 4.3. Behavior of a SIP entity willing to send keep-alives 257 As defined in [RFC5626], a SIP entity that supports sending of keep- 258 alives must act as a Session Traversal Utilities for NAT (STUN) 259 client [RFC5389]. The SIP entity must support those aspects of STUN 260 that are required in order to apply the STUN keep-alive mechanism 261 defined in [RFC5626], and it must support the CRLF keep-alive 262 mechanism defined in [RFC5626]. [RFC5626] defines when to use STUN, 263 respectively double-CRLF, for keep-alives. 265 When a SIP entity sends or forwards a request, if it wants to 266 negotiate the sending of keep-alives associated with a registration, 267 or a dialog, it MUST insert a "keep" parameter in its Via header 268 field of the request to indicate willingness to send keep-alives. 270 When the SIP entity receives the associated response, if the "keep" 271 parameter in its Via header field of the response contains a "keep" 272 parameter value, it MUST start to send keep-alives towards the same 273 destination where it would send a subsequent request (e.g. REGISTER 274 requests and initial requests for dialog) associated with the 275 registration (if the keep-alive negotiation is for a registration), 276 or where it would send subsequent mid-dialog requests (if the keep- 277 alive negotiation is for a dialog). Subsequent mid-dialog requests 278 are addressed based on the dialog route set. 280 Once a SIP entity has negotiated sending of keep-alives associated 281 with a dialog towards an adjacent SIP entity, it MUST NOT insert a 282 "keep" parameter in any subsequent SIP requests, associated with the 283 dialog, towards that adjacent SIP entity. Such "keep" parameter MUST 284 be ignored, if received. 286 Since an ACK request does not have an associated response, it can not 287 be used to negotiate usage of keep-alives. Therefore, a SIP entity 288 MUST NOT insert a "keep" parameter in its Via header field of an ACK 289 request. Such "keep" parameter MUST be ignored, if received. 291 A SIP entity MUST NOT indicates willingness to send keep-alives 292 associated with a dialog, unless it has also inserted itself in the 293 dialog route set [RFC3261]. 295 NOTE: When a SIP entity sends an initial request for a dialog, if the 296 adjacent downstream SIP entity does not insert itself in the dialog 297 route set using a Record-Route header field [RFC3261], the adjacent 298 downstream SIP entity will change once the dialog route set has been 299 established. If a SIP entity inserts a "keep" parameter in its Via 300 header field of an initial request for a dialog, and the "keep" 301 parameter in the associated response does not contain a parameter 302 value, the SIP entity might choose to insert a "keep" parameter in 303 its Via header field of a subsequent SIP request associated with the 304 dialog, in case the new adjacent SIP downstream entity (based on the 305 dialog route set) is willing to receive keep-alives (in which case it 306 will add a parameter value to the "keep" parameter). 308 If an INVITE request is used to indicate willingness to send keep- 309 alives, as long as at least one response (provisional or final) to 310 the INVITE request contains a "keep" parameter with a parameter 311 value, it is seen as an indication that the adjacent downstream SIP 312 entity is willing to receive keep-alives associated with the dialog 313 on which the response is received. 315 4.4. Behavior of a SIP entity willing to receive keep-alives 317 As defined in [RFC5626], a SIP entity that supports receiving of 318 keep-alives must act as a STUN server [RFC5389]. The SIP entity must 319 support those aspects of STUN that are required in order to apply the 320 STUN keep-alive mechanism defined in [RFC5626], and it must support 321 the CRLF keep-alive mechanism defined in [RFC5626]. 323 When a SIP entity sends or forwards a response, and the adjacent 324 upstream SIP entity indicated willingness to send keep-alives, if the 325 SIP entity is willing to receive keep-alives associated with the 326 registration, or the dialog, from the adjacent upstream SIP entity it 327 MUST add a parameter value to the "keep" parameter, before sending or 328 forwarding the response. The parameter can contain a recommended 329 keep-alive frequency, given in seconds, or a zero value. 331 When a SIP entity indicates willingness to receive keep-alives in a 332 response to an INVITE request, it MUST insert a "keep" parameter in 333 at least one reliable response to the request. The SIP entity MAY 334 insert an identical "keep" parameter value in other responses to the 335 same request. The SIP entity MUST NOT insert "keep" parameters with 336 differing values in responses to a single INVITE request. The SIP 337 entity SHOULD indicate the willingness to receive keep-alives as soon 338 as possible. 340 A SIP entity MUST NOT indicates willingness to receive keep-alives 341 associated with a dialog, unless it has also inserted itself in the 342 dialog route set [RFC3261]. 344 5. Keep-alive frequency 346 If a SIP entity receives a SIP response, where its Via header field 347 contains a "keep" parameter with a non-zero value that indicates a 348 recommended keep-alive frequency, given in seconds, it MUST use the 349 procedures defined for the Flow-Timer header field [RFC5626]. 350 According to the procedures, the SIP entity must send keep-alives at 351 least as often as the indicated recommended keep-alive frequency, and 352 if the SIP entity uses the recommended keep-alive frequency then it 353 should send its keep-alives so that the interval between each keep- 354 alive is randomly distributed between 80% and 100% of the recommended 355 keep-alive frequency. 357 If the received "keep" parameter value is zero, the SIP entity can 358 send keep-alives at its discretion. [RFC5626] provides additional 359 guidance on selecting the keep-alive frequency in case a recommended 360 keep-alive frequency is not provided. 362 This specification does not specify actions to take if negotiated 363 keep-alives are not received. As defined in [RFC5626], the receiving 364 SIP entity may consider a connection to be dead in such situations. 366 If a SIP entity that uses the "keep" parameter to indicate 367 willingness to receive keep-alives also inserts a Flow-Timer header 368 field (that can happen if the SIP entity is using both the Outbound 369 mechanism and the keep-alive mechanism) in the same SIP message, the 370 header field value and the "keep" parameter value MUST be identical. 372 SIP Outbound uses the Flow-Timer header field to indicate the server- 373 recommended keep-alive frequency. However, it will only be sent 374 between a UA and an edge proxy. Using the "keep" parameter, however, 375 the sending and receiving of keep-alives might be negotiated between 376 multiple entities on the signalling path. In addition, since the 377 server-recommended keep-alive frequency might vary between different 378 SIP entities, a single Flow-Timer header field can not be used to 379 indicate all the different frequency values, without forcing entities 380 to re-write the value of the Flow-Timer header field. 382 6. Connection reuse 384 Keep-alives are often sent in order to keep NAT bindings open, so 385 that the NAT may be passed by SIP requests sent in the reverse 386 direction, reusing the same connection, or for non-connection- 387 oriented transport protocols, reusing the same path. This 388 specification does not define such connection reuse mechanism. The 389 keep-alive mechanism defined in this specification is only used to 390 negotiate the sending and receiving of keep-alives. Entities that 391 want to reuse connections MUST use a another mechanism to ensure that 392 security aspects associated with connection reuse are taken into 393 consideration. 395 RFC 5923 [RFC5923] specifies a mechanism for using connection- 396 oriented transports to send requests in the reverse direction, and an 397 entity that wants to use connection-reuse as well as indicate support 398 of keep-alives on that connection will insert both the "alias" 399 parameter defined in [RFC5923] as well as the "keep" parameter 400 defined in this specification. 402 SIP Outbound specifies how registration flows are used to send 403 requests in the reverse direction. 405 7. Examples 407 7.1. General 409 This section shows example flows where usage of keep-alives, 410 associated with a registration and a dialog, is negotiated between 411 different SIP entities. 413 7.2. Keep-alive negotiation associated with registration: UA-proxy 415 The figure shows an example where Alice sends an REGISTER request. 416 She indicates willingness of sending keep-alive by inserting a "keep" 417 parameter in her Via header field of the request. The edge proxy 418 (P1) forwards the request towards the registrar. 420 P1 is willing to receive keep-alives from Alice for the duration of 421 the registration, so when P1 receives the associated response it adds 422 a "keep" parameter value, which indicates a recommended keep-alive 423 frequency of 30 seconds, to Alice's Via header field, before it 424 forwards the response towards Alice. 426 When Alice receives the response, she determines from her Via header 427 field that P1 is willing to receive keep-alives associated with the 428 registration. Until the registration expires, or Alice sends a 429 registration refresh request, Alice then sends periodic keep-alives 430 (in this example using the STUN keep-alive technique) towards P1, 431 using the recommended keep-alive frequency indicated by the "keep" 432 parameter value. 434 Alice P1 REGISTRAR 435 | | | 436 |--- REGISTER------------->| | 437 | Via: Alice;keep | | 438 | |--- REGISTER-------------->| 439 | | Via: P1 | 440 | | Via: Alice;keep | 441 | | | 442 | |<-- 200 OK ----------------| 443 | | Via: P1 | 444 | | Via: Alice;keep | 445 |<-- 200 OK ---------------| | 446 | Via: Alice;keep=30 | | 447 | | | 448 | | | 449 | *** Timeout *** | 450 | | | 451 |=== STUN request ========>| | 452 |<== STUN response ========| | 453 | | | 454 | *** Timeout *** | 455 | | | 456 |=== STUN request ========>| | 457 |<== STUN response ========| | 458 | | | 460 Figure 1: Example call flow 462 7.3. Keep-alive negotiation associated with dialog: UA-proxy 464 The figure shows an example where Alice sends an initial INVITE 465 request for a dialog. She indicates willingness to send keep-alive 466 by inserting a "keep" parameter in her Via header field of the 467 request. The edge proxy (P1) adds itself to the dialog route set by 468 adding itself to a Record-Route header field, before it forwards the 469 request towards Bob. 471 P1 is willing to receive keep-alives from Alice for the duration of 472 the dialog, so When P1 receives the associated response it adds a 473 "keep" parameter value, which indicates a recommended keep-alive 474 frequency of 30 seconds, to Alice's Via header field, before it 475 forwards the response towards Alice. 477 When Alice receives the response, she determines from her Via header 478 field that P1 is willing to receive keep-alives associated with the 479 dialog. For the lifetime of the dialog, Alice then sends periodic 480 keep-alives (in this example using the STUN keep-alive technique) 481 towards P1, using the recommended keep-alive frequency indicated by 482 the "keep" parameter value. 484 Alice P1 Bob 485 | | | 486 |--- INVITE -------------->| | 487 | Via: Alice;keep | | 488 | |--- INVITE --------------->| 489 | | Via: P1 | 490 | | Via: Alice;keep | 491 | | Record-Route: P1 | 492 | | | 493 | |<-- 200 OK ----------------| 494 | | Via: P1 | 495 | | Via: Alice;keep | 496 | | Record-Route: P1 | 497 |<-- 200 OK ---------------| | 498 | Alice: UAC;keep=30 | | 499 | Record-Route: P1 | | 500 | | | 501 |--- ACK ----------------->| | 502 | | | 503 | |--- ACK ------------------>| 504 | | | 505 | *** Timeout *** | 506 | | | 507 |=== STUN request ========>| | 508 |<== STUN response ========| | 509 | | | 510 | *** Timeout *** | 511 | | | 512 |=== STUN request ========>| | 513 |<== STUN response ========| | 514 | | | 515 | | | 516 |--- BYE ----------------->| | 517 | | | 518 | |--- BYE ------------------>| 519 | | | 520 | |<-- 200 OK ----------------| 521 | | | 523 Figure 2: Example call flow 525 7.4. Keep-alive negotiation associated with dialog: UA-UA 527 The figure shows an example where Alice sends an initial INVITE 528 request for a dialog. She indicates willingness to send keep-alive 529 by inserting a "keep" parameter in her Via header field of the 530 request. The edge proxy (P1) does not add itself to the dialog route 531 set, by adding itself to a Record-Route header field, before it 532 forwards the request towards Bob. . 534 When Alice receives the response, she determines from her Via header 535 field that P1 is not willing to receive keep-alives associated with 536 the dialog from her. When the dialog route set has been established, 537 Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not 538 insert itself in the dialog route set), and she once again indicates 539 willingness to send keep-alives by inserting a "keep" parameter in 540 her Via header field of the request. Bob supports the keep-alive 541 mechanism, and is willing to receive keep-alives associated with the 542 dialog from Alice, so he creates a response and adds a "keep" 543 parameter value, which indicates a recommended keep-alive frequency 544 of 30 seconds, to Alice's Via header field, before he forwards the 545 response towards Alice. 547 When Alice receives the response, she determines from her Via header 548 field that P1 is willing to receive keep-alives associated with the 549 dialog. For the lifetime of the dialog, Alice then sends periodic 550 keep-alives (in this example using the STUN keep-alive technique) 551 towards Bob, using the recommended keep-alive frequency indicated by 552 the "keep" parameter value. 554 Alice P1 Bob 555 | | | 556 |--- INVITE -------------->| | 557 | Via: Alice;keep | | 558 | |--- INVITE --------------->| 559 | | Via: P1 | 560 | | Via: Alice:keep | 561 | | | 562 | |<-- 200 OK ----------------| 563 | | Via: P1 | 564 | | Via: Alice;keep | 565 |<-- 200 OK ---------------| | 566 | Via: Alice;keep | | 567 | | | 568 | | 569 |--- ACK --------------------------------------------->| 570 | | 571 |--- UPDATE ------------------------------------------>| 572 | Via: Alice;keep | 573 | | 574 |<-- 200 OK ------------------------------------------>| 575 | Via: UAC;keep=30 | 576 | | 577 | | 578 | *** Timeout *** | 579 | | 580 |=== STUN request ====================================>| 581 |<== STUN response ====================================| 582 | | 583 | *** Timeout *** | 584 | | 585 |=== STUN request ====================================>| 586 |<== STUN response ====================================| 587 | | 588 | | 589 |--- BYE --------------------------------------------->| 590 | | 591 |<-- 200 OK -------------------------------------------| 592 | | 594 Figure 3: Example call flow 596 8. Grammar 598 This specification defines a new Via header field parameter, "keep". 599 The grammar includes the definitions from [RFC5626]. 601 The ABNF [RFC5234] is: 603 via-params =/ keep 605 keep = "keep" [ EQUAL 1*(DIGIT) ] 607 9. IANA Considerations 609 9.1. keep 611 This specification defines a new Via header field parameter called 612 keep in the "Header Field Parameters and Parameter Values" sub- 613 registry as per the registry created by [RFC5626]. The syntax is 614 defined in Section 8. The required information is: 616 Predefined 617 Header Field Parameter Name Values Reference 618 ---------------------- --------------------- ---------- --------- 619 Via keep No [RFCXXXX] 621 10. Security Considerations 623 SIP entities that send or receive keep-alives are often required to 624 use a connection reuse mechanism, in order to ensure that requests 625 sent in the reverse direction, towards the sender of the keep-alives, 626 traverse NATs etc. This specification does not specify a connection 627 reuse mechanism, and it does it address security issues related to 628 connection reuse. SIP entities that wish to reuse connections are 629 required to use a dedicated connection reuse mechanism, in 630 conjunction with the keep-alive negotiation mechanism. 632 Unless SIP messages are integrity protected, a man-in-the-middle can 633 modify Via header fields used by two entities to negotiate sending of 634 keep-alives, e.g. by removing the indications used to indicate 635 willingness to send and receive keep-alives, or by decreasing the 636 timer value to a very low value, which might trigger additional 637 resource consumption due to the frequently sent keep-alives. 639 Downstream SIP entities can modify Via header fields identifying 640 other SIP entities, and cause keep-alives to be sent (at high rates) 641 to entities that do not support the keep-alive mechanism. SIP 642 entities can prevent this, when a SIP response is received, by 643 examining their own Via header field to determine that downstream 644 entities have not added a "keep" parameter or set an existing "keep" 645 parameter to a value not supported by the implementation. 647 Apart from the issues described above, this specification does not 648 introduce security considerations in addition to those specified for 649 keep-alives in [RFC5626]. 651 11. Acknowledgements 653 Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer 654 and Milo Orsic for their comments on the initial draft. Thanks to 655 Juha Heinaenen, Jiri Kuthan, Dean Willis, John Elwell, Paul Kyzivat, 656 Peter Musgrave, Dale Worley and Adam Roach for their comments on the 657 list. Thanks to Vijay Gurbani for providing text about the 658 relationship with the connect reuse specification. 660 12. Change Log 662 [RFC EDITOR NOTE: Please remove this section when publishing] 664 Changes from draft-ietf-sipcore-keep-06 665 o New text added to the security considerations 667 Changes from draft-ietf-sipcore-keep-05 668 o New section about connection reuse added 669 o Clarify that the specification does not define a mechanism for 670 connection reuse 671 o New text added to the security considerations 672 o CRLF changed to double-CRLF in some places 674 13. References 676 13.1. Normative References 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, March 1997. 681 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 682 A., Peterson, J., Sparks, R., Handley, M., and E. 683 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 684 June 2002. 686 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 687 Specifications: ABNF", STD 68, RFC 5234, January 2008. 689 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 690 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 691 October 2008. 693 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 694 Initiated Connections in the Session Initiation Protocol 695 (SIP)", RFC 5626, October 2009. 697 13.2. Informative References 699 [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in 700 the Session Initiation Protocol (SIP)", RFC 5923, 701 June 2010. 703 Author's Address 705 Christer Holmberg 706 Ericsson 707 Hirsalantie 11 708 Jorvas 02420 709 Finland 711 Email: christer.holmberg@ericsson.com