idnits 2.17.1 draft-ietf-sipcore-keep-12.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 (January 20, 2011) is 4807 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 631, but not defined ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). 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 January 20, 2011 5 Expires: July 24, 2011 7 Indication of support for keep-alive 8 draft-ietf-sipcore-keep-12.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 July 24, 2011. 37 Copyright Notice 39 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.3. Keep-alive negotiation associated with dialog: UA-proxy . 11 75 7.4. Keep-alive negotiation associated with dialog: UA-UA . . . 13 76 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 83 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 86 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive 92 mechanisms. Even though the keep-alive mechanisms are separated from 93 the rest of the SIP Outbound mechanism, SIP Outbound does not define 94 a mechanism to explicitly negotiate usage of the keep-alive 95 mechanisms. In some cases usage of keep-alives can be implicitly 96 negotiated as part of the SIP Outbound negotiation. 98 However, there are SIP Outbound use-cases where usage of keep-alives 99 is not implicitly negotiated as part of the SIP Outbound negotiation. 100 In addition, there are cases where SIP Outbound is not supported, or 101 where it cannot be applied, but where there is still a need to be 102 able to negotiate usage of keep-alives. Last, SIP Outbound only 103 allows keep-alives to be negotiated between a UA and an edge proxy, 104 and not between other SIP entities. 106 This specification defines a new Session Initiation Protocol (SIP) 107 [RFC3261] Via header field parameter, "keep", which allows adjacent 108 SIP entities to explicitly negotiate usage of the NAT keep-alive 109 mechanisms defined in SIP Outbound. The "keep" parameter allows SIP 110 entities to indicate willingness to send keep-alives, to indicate 111 willingness to receive keep-alives, and for SIP entities willing to 112 receive keep-alives to provide a recommended keep-alive frequency. 114 The following sections describe use-cases where a mechanism to 115 explicitly negotiate usage of keep-alives is needed. 117 1.1. Use-case: Dialog from non-registered UAs 119 In some cases a User Agent Client (UAC) does not register itself 120 before it establishes a dialog, but in order to maintain NAT bindings 121 open during the lifetime of the dialog it still needs to be able to 122 negotiate sending of keep-alives towards its adjacent downstream SIP 123 entity. A typical example is an emergency call, where a registration 124 is not always required in order to make the call. 126 1.2. Use-case: SIP Outbound not supported 128 In some cases some SIP entities that need to be able to negotiate the 129 use of keep-alives might not support SIP Outbound. However, they 130 might still support the keep-alive mechanisms defined in SIP 131 Outbound, and need to be able to negotiate usage of them. 133 1.3. Use-case: SIP dialog initiated Outbound flows 135 SIP Outbound allows the establishment of flows using the initial 136 request for a dialog. As specified in RFC 5626 [RFC5626], usage of 137 keep-alives is not implicitly negotiated for such flows. 139 2. Conventions 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in BCP 14, RFC 2119 144 [RFC2119]. 146 3. Definitions 148 Edge proxy: As defined in RFC 5626, a SIP proxy that is located 149 topologically between the registering User Agent (UA) and the 150 Authoritative Proxy. 152 NOTE: In some deployments the edge proxy might physically be located 153 in the same SIP entity as the Authoritative Proxy. 155 Keep-alives: The keep-alive messages defined in RFC 5626. 157 "keep" parameter: A SIP Via header field parameter that a SIP entity 158 can insert in the topmost Via header field that it adds to the 159 request, to explicitly indicate willingness to send keep-alives 160 towards its adjacent downstream SIP entity. A SIP entity can add a 161 parameter value to the "keep" parameter in a response to explicitly 162 indicate willingness to receive keep-alives from its adjacent 163 upstream SIP entity. 165 SIP entity: SIP User Agent (UA), or proxy, as defined in RFC 3261. 167 Adjacent downstream SIP entity: The adjacent SIP entity in the 168 direction towards which a SIP request is sent. 170 Adjacent upstream SIP entity: The adjacent SIP entity in the 171 direction from which a SIP request is received. 173 4. User Agent and Proxy behavior 175 4.1. General 177 This section describes how SIP UAs and proxies negotiate usage of 178 keep-alives associated with a registration, or a dialog, which types 179 of SIP requests can be used in order to negotiate the usage, and the 180 lifetime of the negotiated keep-alives. 182 SIP entities indicate willingness to send keep-alives towards the 183 adjacent downstream SIP entity using SIP requests. The associated 184 responses are used by SIP entities to indicate willingness to receive 185 keep-alives. SIP entities that indicate willingness to receive keep- 186 alives can provide a recommended keep-alive frequency. 188 The procedures to negotiate usage of keep-alives are identical for 189 SIP UAs and proxies. 191 In general, it can be useful for SIP entities to indicate willingness 192 to send keep-alives, even if they are not aware of any necessity for 193 them to send keep-alives, since the adjacent downstream SIP entity 194 might have knowledge about the necessity. Similarly, if the adjacent 195 upstream SIP entity has indicated willingness to send keep-alives, it 196 can be useful for SIP entities to indicate willingness to receive 197 keep-alives, even if they are not aware of any necessity for the 198 adjacent upstream SIP entity to send them. 200 NOTE: Usage of keep-alives is negotiated per direction. If a SIP 201 entity has indicated willingness to receive keep-alives from an 202 adjacent SIP entity, sending of keep-alives towards that adjacent SIP 203 entity needs to be separately negotiated. 205 NOTE: Since there are SIP entities that already use a combination of 206 Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP 207 entities are expected to be able to receive those, this specification 208 does not forbid the sending of double-CRLF keep-alive messages 209 towards an adjacent SIP entity even if usage of keep-alives with that 210 SIP entity has not been negotiated. However, the "keep" parameter is 211 still important in order for a SIP entity to indicate that it 212 supports sending of double-CRLF keep-alive messages, so that the 213 adjacent downstream SIP entity does not use other mechanisms (e.g. 214 short registration refresh intervals) in order to keep NAT bindings 215 open. 217 4.2. Lifetime of keep-alives 219 4.2.1. General 221 The lifetime of negotiated keep-alives depends on whether the keep- 222 alives are associated with a registration or a dialog. This section 223 describes the lifetime of negotiated keep-alives. 225 4.2.2. Keep-alives associated with registration 227 SIP entities use a registration request in order to negotiate usage 228 of keep-alives associated with a registration. Usage of keep-alives 229 can be negotiated when the registration is established, or later 230 during the registration. Once negotiated, keep-alives are sent until 231 the registration is terminated, or until a subsequent registration 232 refresh request is sent or forwarded. When a subsequent registration 233 refresh request is sent or forwarded, if a SIP entity is willing to 234 continue sending keep-alives associated with the registration, usage 235 of keep-alives MUST be re-negotiated. If usage is not successfully 236 re-negotiated, the SIP entity MUST cease sending of keep-alives 237 associated with the registration. 239 NOTE: Sending of keep-alives associated with a registration can only 240 be negotiated in the direction from the registering SIP entity 241 towards the registrar. 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 RFC 5626, 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 RFC 5626, and it must support the CRLF keep-alive 262 mechanism defined in RFC 5626. RFC 5626 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 the topmost Via 268 header field that it adds to the request, to indicate willingness to 269 send keep-alives. 271 When the SIP entity receives the associated response, if the "keep" 272 parameter in the topmost Via header field of the response contains a 273 "keep" parameter value, it MUST start sending keep-alives towards the 274 same destination where it would send a subsequent request (e.g. 275 REGISTER requests and initial requests for dialog) associated with 276 the registration (if the keep-alive negotiation is for a 277 registration), or where it would send subsequent mid-dialog requests 278 (if the keep-alive negotiation is for a dialog). Subsequent mid- 279 dialog requests are addressed based on the dialog route set. 281 Once a SIP entity has negotiated sending of keep-alives associated 282 with a dialog towards an adjacent SIP entity, it MUST NOT insert a 283 "keep" parameter in any subsequent SIP requests, associated with the 284 dialog, towards that adjacent SIP entity. Such "keep" parameter MUST 285 be ignored, if received. 287 Since an ACK request does not have an associated response, it can not 288 be used to negotiate usage of keep-alives. Therefore, a SIP entity 289 MUST NOT insert a "keep" parameter in the topmost Via header field of 290 an ACK request. Such "keep" parameter MUST be ignored, if received. 292 A SIP entity MUST NOT indicates willingness to send keep-alives 293 associated with a dialog, unless it has also inserted itself in the 294 dialog route set [RFC3261]. 296 NOTE: When a SIP entity sends an initial request for a dialog, if the 297 adjacent downstream SIP entity does not insert itself in the dialog 298 route set using a Record-Route header field [RFC3261], the adjacent 299 downstream SIP entity will change once the dialog route set has been 300 established. If a SIP entity inserts a "keep" parameter in the 301 topmost Via header field of an initial request for a dialog, and the 302 "keep" parameter in the associated response does not contain a 303 parameter value, the SIP entity might choose to insert a "keep" 304 parameter in the topmost Via header field of a subsequent SIP request 305 associated with the dialog, in case the new adjacent downstream SIP 306 entity (based on the dialog route set) is willing to receive keep- 307 alives (in which case it will add a parameter value to the "keep" 308 parameter). 310 If an INVITE request is used to indicate willingness to send keep- 311 alives, as long as at least one response (provisional or final) to 312 the INVITE request contains a "keep" parameter with a parameter 313 value, it is seen as an indication that the adjacent downstream SIP 314 entity is willing to receive keep-alives associated with the dialog 315 on which the response is received. 317 4.4. Behavior of a SIP entity willing to receive keep-alives 319 As defined in RFC 5626, a SIP entity that supports receiving of keep- 320 alives must act as a STUN server [RFC5389]. The SIP entity must 321 support those aspects of STUN that are required in order to apply the 322 STUN keep-alive mechanism defined in RFC 5626, and it must support 323 the CRLF keep-alive mechanism defined in RFC 5626. 325 When a SIP entity sends or forwards a response, and the adjacent 326 upstream SIP entity indicated willingness to send keep-alives, if the 327 SIP entity is willing to receive keep-alives associated with the 328 registration, or the dialog, from the adjacent upstream SIP entity it 329 MUST add a parameter value to the "keep" parameter, before sending or 330 forwarding the response. The parameter value, if present and with a 331 value other than zero, represents a recommended keep-alive frequency, 332 given in seconds. 334 There might be multiple responses to an INVITE request. When a SIP 335 entity indicates willingness to receive keep-alives in a response to 336 an INVITE request, it MUST add a parameter value to the "keep" 337 parameter in at least one reliable response to the request. The SIP 338 entity MAY add identical parameter values to the "keep" parameters in 339 other responses to the same request. The SIP entity MUST NOT add 340 different parameter value to the "keep" parameters in responses to 341 the same request. The SIP entity SHOULD indicate the willingness to 342 receive keep-alives as soon as possible. 344 A SIP entity MUST NOT indicates willingness to receive keep-alives 345 associated with a dialog, unless it has also inserted itself in the 346 dialog route set [RFC3261]. 348 5. Keep-alive frequency 350 If a SIP entity receives a SIP response, where the topmost Via header 351 field contains a "keep" parameter with a non-zero value that 352 indicates a recommended keep-alive frequency, given in seconds, it 353 MUST use the procedures defined for the Flow-Timer header field 354 [RFC5626]. According to the procedures, the SIP entity must send 355 keep-alives at least as often as the indicated recommended keep-alive 356 frequency, and if the SIP entity uses the recommended keep-alive 357 frequency then it should send its keep-alives so that the interval 358 between each keep-alive is randomly distributed between 80% and 100% 359 of the recommended keep-alive frequency. 361 If the received "keep" parameter value is zero, the SIP entity can 362 send keep-alives at its discretion. RFC 5626 provides additional 363 guidance on selecting the keep-alive frequency in case a recommended 364 keep-alive frequency is not provided. 366 This specification does not specify actions to take if negotiated 367 keep-alives are not received. As defined in RFC 5626, the receiving 368 SIP entity may consider a connection to be dead in such situations. 370 If a SIP entity that adds a parameter value to the "keep" parameter, 371 in order to indicate willingness to receive keep-alives, also inserts 372 a Flow-Timer header field (that can happen if the SIP entity is using 373 both the Outbound mechanism and the keep-alive mechanism) in the same 374 SIP message, the header field value and the "keep" parameter value 375 MUST be identical. 377 SIP Outbound uses the Flow-Timer header field to indicate the server- 378 recommended keep-alive frequency. However, it will only be sent 379 between a UA and an edge proxy. Using the "keep" parameter, however, 380 the sending and receiving of keep-alives might be negotiated between 381 multiple entities on the signalling path. In addition, since the 382 server-recommended keep-alive frequency might vary between different 383 SIP entities, a single Flow-Timer header field can not be used to 384 indicate all the different frequency values. 386 6. Connection reuse 388 Keep-alives are often sent in order to keep NAT bindings open, so 389 that the NAT may be passed by SIP requests sent in the reverse 390 direction, reusing the same connection, or for non-connection- 391 oriented transport protocols, reusing the same path. This 392 specification does not define such connection reuse mechanism. The 393 keep-alive mechanism defined in this specification is only used to 394 negotiate the sending and receiving of keep-alives. Entities that 395 want to reuse connections need to use another mechanism to ensure 396 that security aspects associated with connection reuse are taken into 397 consideration. 399 RFC 5923 [RFC5923] specifies a mechanism for using connection- 400 oriented transports to send requests in the reverse direction, and an 401 entity that wants to use connection-reuse as well as indicate support 402 of keep-alives on that connection will insert both the "alias" 403 parameter defined in RFC 5923 as well as the "keep" parameter defined 404 in this specification. 406 SIP Outbound specifies how registration flows are used to send 407 requests in the reverse direction. 409 7. Examples 411 7.1. General 413 This section shows example flows where usage of keep-alives, 414 associated with a registration and a dialog, is negotiated between 415 different SIP entities. 417 NOTE: The examples do not show the actual syntactical encoding of the 418 request lines, response lines and the Via header fields, but rather a 419 pseudo code in order to identity the message type and to which SIP 420 entity a Via header field is associated. 422 7.2. Keep-alive negotiation associated with registration: UA-proxy 424 Figure 1 shows an example where Alice sends an REGISTER request. She 425 indicates willingness of sending keep-alive by inserting a "keep" 426 parameter in her Via header field of the request. The edge proxy 427 (P1) forwards the request towards the registrar. 429 P1 is willing to receive keep-alives from Alice for the duration of 430 the registration, so when P1 receives the associated response it adds 431 a "keep" parameter value, which indicates a recommended keep-alive 432 frequency of 30 seconds, to Alice's Via header field, before it 433 forwards the response towards Alice. 435 When Alice receives the response, she determines from her Via header 436 field that P1 is willing to receive keep-alives associated with the 437 registration. Until the registration expires, or Alice sends a 438 registration refresh request, Alice then sends periodic keep-alives 439 (in this example using the STUN keep-alive technique) towards P1, 440 using the recommended keep-alive frequency indicated by the "keep" 441 parameter value. 443 Alice P1 REGISTRAR 444 | | | 445 |--- REGISTER------------->| | 446 | Via: Alice;keep | | 447 | |--- REGISTER-------------->| 448 | | Via: P1 | 449 | | Via: Alice;keep | 450 | | | 451 | |<-- 200 OK ----------------| 452 | | Via: P1 | 453 | | Via: Alice;keep | 454 |<-- 200 OK ---------------| | 455 | Via: Alice;keep=30 | | 456 | | | 457 | | | 458 | *** Timeout *** | 459 | | | 460 |=== STUN request ========>| | 461 |<== STUN response ========| | 462 | | | 463 | *** Timeout *** | 464 | | | 465 |=== STUN request ========>| | 466 |<== STUN response ========| | 467 | | | 469 Figure 1: Example call flow 471 7.3. Keep-alive negotiation associated with dialog: UA-proxy 473 Figure 2 shows an example where Alice sends an initial INVITE request 474 for a dialog. She indicates willingness to send keep-alive by 475 inserting a "keep" parameter in her Via header field of the request. 476 The edge proxy (P1) adds itself to the dialog route set by adding 477 itself to a Record-Route header field, before it forwards the request 478 towards Bob. 480 P1 is willing to receive keep-alives from Alice for the duration of 481 the dialog, so When P1 receives the associated response it adds a 482 "keep" parameter value, which indicates a recommended keep-alive 483 frequency of 30 seconds, to Alice's Via header field, before it 484 forwards the response towards Alice. 486 When Alice receives the response, she determines from her Via header 487 field that P1 is willing to receive keep-alives associated with the 488 dialog. For the lifetime of the dialog, Alice then sends periodic 489 keep-alives (in this example using the STUN keep-alive technique) 490 towards P1, using the recommended keep-alive frequency indicated by 491 the "keep" parameter value. 493 Alice P1 Bob 494 | | | 495 |--- INVITE -------------->| | 496 | Via: Alice;keep | | 497 | |--- INVITE --------------->| 498 | | Via: P1 | 499 | | Via: Alice;keep | 500 | | Record-Route: P1 | 501 | | | 502 | |<-- 200 OK ----------------| 503 | | Via: P1 | 504 | | Via: Alice;keep | 505 | | Record-Route: P1 | 506 |<-- 200 OK ---------------| | 507 | Via: Alice;keep=30 | | 508 | Record-Route: P1 | | 509 | | | 510 |--- ACK ----------------->| | 511 | | | 512 | |--- ACK ------------------>| 513 | | | 514 | *** Timeout *** | 515 | | | 516 |=== STUN request ========>| | 517 |<== STUN response ========| | 518 | | | 519 | *** Timeout *** | 520 | | | 521 |=== STUN request ========>| | 522 |<== STUN response ========| | 523 | | | 524 | | | 525 |--- BYE ----------------->| | 526 | | | 527 | |--- BYE ------------------>| 528 | | | 529 | |<-- 200 OK ----------------| 530 | | | 532 Figure 2: Example call flow 534 7.4. Keep-alive negotiation associated with dialog: UA-UA 536 Figure 3 shows an example where Alice sends an initial INVITE request 537 for a dialog. She indicates willingness to send keep-alive by 538 inserting a "keep" parameter in her Via header field of the request. 539 The edge proxy (P1) does not add itself to the dialog route set, by 540 adding itself to a Record-Route header field, before it forwards the 541 request towards Bob. 543 When Alice receives the response, she determines from her Via header 544 field that P1 is not willing to receive keep-alives associated with 545 the dialog from her. When the dialog route set has been established, 546 Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not 547 insert itself in the dialog route set), and she once again indicates 548 willingness to send keep-alives by inserting a "keep" parameter in 549 her Via header field of the request. Bob supports the keep-alive 550 mechanism, and is willing to receive keep-alives associated with the 551 dialog from Alice, so he creates a response and adds a "keep" 552 parameter value, which indicates a recommended keep-alive frequency 553 of 30 seconds, to Alice's Via header field, before he forwards the 554 response towards Alice. 556 When Alice receives the response, she determines from her Via header 557 field that Bob is willing to receive keep-alives associated with the 558 dialog. For the lifetime of the dialog, Alice then sends periodic 559 keep-alives (in this example using the STUN keep-alive technique) 560 towards Bob, using the recommended keep-alive frequency indicated by 561 the "keep" parameter value. 563 Alice P1 Bob 564 | | | 565 |--- INVITE -------------->| | 566 | Via: Alice;keep | | 567 | |--- INVITE --------------->| 568 | | Via: P1 | 569 | | Via: Alice:keep | 570 | | | 571 | |<-- 200 OK ----------------| 572 | | Via: P1 | 573 | | Via: Alice;keep | 574 |<-- 200 OK ---------------| | 575 | Via: Alice;keep | | 576 | | | 577 | | 578 |--- ACK --------------------------------------------->| 579 | | 580 |--- UPDATE ------------------------------------------>| 581 | Via: Alice;keep | 582 | | 583 |<-- 200 OK ------------------------------------------>| 584 | Via: UAC;keep=30 | 585 | | 586 | | 587 | *** Timeout *** | 588 | | 589 |=== STUN request ====================================>| 590 |<== STUN response ====================================| 591 | | 592 | *** Timeout *** | 593 | | 594 |=== STUN request ====================================>| 595 |<== STUN response ====================================| 596 | | 597 | | 598 |--- BYE --------------------------------------------->| 599 | | 600 |<-- 200 OK -------------------------------------------| 601 | | 603 Figure 3: Example call flow 605 8. Grammar 606 8.1. General 608 This section describes the syntax extensions to the ABNF syntax 609 defined in RFC 3261, by defining a new Via header field parameter, 610 "keep". The ABNF defined in this specification is conformant to RFC 611 5234 [RFC5234]. 613 8.2. ABNF 615 via-params =/ keep 617 keep = "keep" [ EQUAL 1*(DIGIT) ] 619 9. IANA Considerations 621 9.1. keep 623 This specification defines a new Via header field parameter called 624 keep in the "Header Field Parameters and Parameter Values" sub- 625 registry as per the registry created by [RFC3968]. The syntax is 626 defined in Section 8. The required information is: 628 Predefined 629 Header Field Parameter Name Values Reference 630 ---------------------- --------------------- ---------- --------- 631 Via keep No [RFCXXXX] 633 10. Security Considerations 635 SIP entities that send or receive keep-alives are often required to 636 use a connection reuse mechanism, in order to ensure that requests 637 sent in the reverse direction, towards the sender of the keep-alives, 638 traverse NATs etc. This specification does not specify a connection 639 reuse mechanism, and it does not address security issues related to 640 connection reuse. SIP entities that wish to reuse connections need 641 to use a dedicated connection reuse mechanism, in conjunction with 642 the keep-alive negotiation mechanism. 644 Unless SIP messages are integrity protected hop-by-hop, e.g. using 645 Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer 646 Security (DTLS) [RFC4347], a man-in-the-middle can modify Via header 647 fields used by two entities to negotiate sending of keep-alives, e.g. 649 by removing the indications used to indicate willingness to send and 650 receive keep-alives, or by decreasing the timer value to a very low 651 value, which might trigger additional resource consumption due to the 652 frequently sent keep-alives. 654 The behavior defined in Sections 4.3 and 4.4 require a SIP entity 655 using the mechanism defined in this specification to place a value in 656 the "keep" parameter in the topmost Via header field value of a 657 response the SIP entity sends. They do not instruct the entity to 658 place a value in a "keep" parameter of any request it forwards. In 659 particular, SIP proxies MUST NOT place a value into the keep 660 parameter of the topmost Via header field value of a request it 661 receives before forwarding it. A SIP proxy implementing this 662 specification SHOULD remove any keep parameter values in any Via 663 header field values below the topmost one in responses it receives 664 before forwarding them. 666 When requests are forwarded across multiple hops, it is possible for 667 a malicious downstream SIP entity to tamper with the accrued values 668 in the Via header field. The malicious SIP entity could place a 669 value, or change an existing value in a "keep" parameter in any of 670 the Via header field values, not just the topmost value. A proxy 671 implementation that simply forwards responses by stripping the 672 topmost Via header field value and not inspecting the resulting new 673 topmost Via header field value risks being adversely affected by such 674 a malicious downstream SIP entity. In particular, such a proxy may 675 start receiving STUN requests if it blindly forwards a response with 676 a keep parameter with a value it did not create in the topmost Via 677 header field. 679 To lower the chances of the malicious SIP entity's actions having 680 adverse affects on such proxies, when a SIP entity sends STUN keep- 681 alives to an adjacent downstream SIP entity and does not receive a 682 response to those STUN messages, it MUST, based on the procedure in 683 section 4.4.2 of RFC 5626, after 7 retransmissions, or when an error 684 response is received for the STUN request, stop sending keep-alives 685 for the remaining duration of the dialog (if the sending of keep- 686 alives were negotiated for a dialog) or until the sending of keep- 687 alives is re-negotiated for the registration (if the sending keep- 688 alives were negotiated for a registration). 690 Apart from the issues described above, this specification does not 691 introduce security considerations in addition to those specified for 692 keep-alives in [RFC5626]. 694 11. Acknowledgements 696 Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer 697 and Milo Orsic for their comments on the initial draft. Thanks to 698 Juha Heinaenen, Jiri Kuthan, Dean Willis, John Elwell, Paul Kyzivat, 699 Peter Musgrave, Dale Worley, Adam Roach and Robert Sparks for their 700 comments on the list. Thanks to Vijay Gurbani for providing text 701 about the relationship with the connect reuse specification. 703 12. Change Log 705 [RFC EDITOR NOTE: Please remove this section when publishing] 707 Changes from draft-ietf-sipcore-keep-11 708 o Editorial fixes based on last call comments by Peter Saint-Andre 709 (Jan 11th) 710 o - TLS and DTLS references added 711 o - Clarification that the sending of keep-alives stops after 7 712 retranmissions 713 o Editorial fixes based on last call comments by Alexey Melnikov 714 (Jan 12th) 715 o - Additional text added to Grammar section 716 o Editorial fixes based on last call comments by Adrian Farrel (Jan 717 16th) 718 o Editorial fixes based on last call comments by Sean Turner (Jan 719 20th) 720 o Reference clean-ups 722 Changes from draft-ietf-sipcore-keep-10 723 o Editorial fixes based on last call comments by Juergen 724 Schoenwaelder (Dec 21st) 725 o Editorial fixes based on last call comments by Roni Even (Dec 726 28th) 728 Changes from draft-ietf-sipcore-keep-09 729 o Changes based on AD review comments by Robert Sparks 730 o Redundant paragraph removed from security considerations 732 Changes from draft-ietf-sipcore-keep-08 733 o Changes based on AD review comments by Robert Sparks 734 o Additional security considerations text provided by Robert Sparks 735 o http://www.ietf.org/mail-archive/web/sipcore/current/msg03779.html 736 (Nov 23rd) 737 o http://www.ietf.org/mail-archive/web/sipcore/current/msg03780.html 738 (Nov 23rd) 740 Changes from draft-ietf-sipcore-keep-07 741 o Last paragraph of section 4.2.2 removed 742 o Reference correction 744 Changes from draft-ietf-sipcore-keep-06 745 o New text added to the security considerations 747 Changes from draft-ietf-sipcore-keep-05 748 o New section about connection reuse added 749 o Clarify that the specification does not define a mechanism for 750 connection reuse 751 o New text added to the security considerations 752 o CRLF changed to double-CRLF in some places 754 13. References 756 13.1. Normative References 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, March 1997. 761 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 762 A., Peterson, J., Sparks, R., Handley, M., and E. 763 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 764 June 2002. 766 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 767 Specifications: ABNF", STD 68, RFC 5234, January 2008. 769 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 770 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 771 October 2008. 773 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 774 Initiated Connections in the Session Initiation Protocol 775 (SIP)", RFC 5626, October 2009. 777 13.2. Informative References 779 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 780 (IANA) Header Field Parameter Registry for the Session 781 Initiation Protocol (SIP)", BCP 98, RFC 3968, 782 December 2004. 784 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 785 Security", RFC 4347, April 2006. 787 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 788 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 790 [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in 791 the Session Initiation Protocol (SIP)", RFC 5923, 792 June 2010. 794 Author's Address 796 Christer Holmberg 797 Ericsson 798 Hirsalantie 11 799 Jorvas 02420 800 Finland 802 Email: christer.holmberg@ericsson.com