idnits 2.17.1 draft-ietf-sipcore-keep-11.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 10, 2011) is 4856 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 626, 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 January 10, 2011 5 Expires: July 14, 2011 7 Indication of support for keep-alive 8 draft-ietf-sipcore-keep-11.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 14, 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 84 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 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 SIP 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 the topmost Via header field that it adds to the 158 request, to explicitly indicate willingness to send keep-alives 159 towards its adjacent downstream SIP entity. A SIP entity can add a 160 parameter value to the "keep" parameter in a response to explicitly 161 indicate willingness to receive keep-alives from its adjacent 162 upstream SIP entity. 164 SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261]. 166 Adjacent downstream SIP entity: The adjacent SIP entity in the 167 direction towards which a SIP request is sent. 169 Adjacent upstream SIP entity: The adjacent SIP entity in the 170 direction from which a SIP request is received. 172 4. User Agent and Proxy behavior 174 4.1. General 176 This section describes how SIP UAs and proxies negotiate usage of 177 keep-alives associated with a registration, or a dialog, which types 178 of SIP requests can be used in order to negotiate the usage, and the 179 lifetime of the negotiated keep-alives. 181 SIP entities indicate willingness to send keep-alives towards the 182 adjacent downstream SIP entity using SIP requests. The associated 183 responses are used by SIP entities to indicate willingness to receive 184 keep-alives. SIP entities that indicate willingness to receive keep- 185 alives can provide a recommended keep-alive frequency. 187 The procedures to negotiate usage of keep-alives are identical for 188 SIP UAs and proxies. 190 In general, it can be useful for SIP entities to indicate willingness 191 to send keep-alives, even if they are not aware of any necessity for 192 them to send keep-alives, since the adjacent downstream SIP entity 193 might have knowledge about the necessity. Similarly, if the adjacent 194 upstream SIP entity has indicated willingness to send keep-alives, it 195 can be useful for SIP entities to indicate willingness to receive 196 keep-alives, even if they are not aware of any necessity for the 197 adjacent upstream SIP entity to send them. 199 NOTE: Usage of keep-alives is negotiated per direction. If a SIP 200 entity has indicated willingness to receive keep-alives from an 201 adjacent SIP entity, sending of keep-alives towards that adjacent SIP 202 entity needs to be separately negotiated. 204 NOTE: Since there are SIP entities that already use a combination of 205 Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP 206 entities are expected to be able to receive those, this specification 207 does not forbid the sending of double-CRLF keep-alive messages 208 towards an adjacent SIP entity even if usage of keep-alives with that 209 SIP entity has not been negotiated. However, the "keep" parameter is 210 still important in order for a SIP entity to indicate that it 211 supports sending of double-CRLF keep-alive messages, so that the 212 adjacent downstream SIP entity does not use other mechanisms (e.g. 213 short registration refresh intervals) in order to keep NAT bindings 214 open. 216 4.2. Lifetime of keep-alives 218 4.2.1. General 220 The lifetime of negotiated keep-alives depends on whether the keep- 221 alives are associated with a registration or a dialog. This section 222 describes the lifetime of negotiated keep-alives. 224 4.2.2. Keep-alives associated with registration 226 SIP entities use a registration request in order to negotiate usage 227 of keep-alives associated with a registration. Usage of keep-alives 228 can be negotiated when the registration is established, or later 229 during the registration. Once negotiated, keep-alives are sent until 230 the registration is terminated, or until a subsequent registration 231 refresh request is sent or forwarded. When a subsequent registration 232 refresh request is sent or forwarded, if a SIP entity is willing to 233 continue sending keep-alives associated with the registration, usage 234 of keep-alives MUST be re-negotiated. If usage is not successfully 235 re-negotiated, the SIP entity MUST cease sending of keep-alives 236 associated with the registration. 238 NOTE: Sending of keep-alives associated with a registration can only 239 be negotiated in the direction from the registering SIP entity 240 towards the registrar. 242 4.2.3. Keep-alives associated with dialog 244 SIP entities use an initial request for a dialog, or a mid-dialog 245 target refresh request [RFC3261], in order to negotiate sending and 246 receiving of keep-alives associated with a dialog. Usage of keep- 247 alives can be negotiated when the dialog is established, or later 248 during the lifetime of the dialog. Once negotiated, keep-alives MUST 249 be sent for the lifetime of the dialog, until the dialog is 250 terminated. Once usage of keep-alives associated with a dialog has 251 been negotiated, it is not possible to re-negotiate the usage 252 associated with the dialog. 254 4.3. Behavior of a SIP entity willing to send keep-alives 256 As defined in [RFC5626], a SIP entity that supports sending of keep- 257 alives must act as a Session Traversal Utilities for NAT (STUN) 258 client [RFC5389]. The SIP entity must support those aspects of STUN 259 that are required in order to apply the STUN keep-alive mechanism 260 defined in [RFC5626], and it must support the CRLF keep-alive 261 mechanism defined in [RFC5626]. [RFC5626] defines when to use STUN, 262 respectively double-CRLF, for keep-alives. 264 When a SIP entity sends or forwards a request, if it wants to 265 negotiate the sending of keep-alives associated with a registration, 266 or a dialog, it MUST insert a "keep" parameter in the topmost Via 267 header field that it adds to the request, to indicate willingness to 268 send keep-alives. 270 When the SIP entity receives the associated response, if the "keep" 271 parameter in the topmost Via header field of the response contains a 272 "keep" parameter value, it MUST start sending keep-alives towards the 273 same destination where it would send a subsequent request (e.g. 274 REGISTER requests and initial requests for dialog) associated with 275 the registration (if the keep-alive negotiation is for a 276 registration), or where it would send subsequent mid-dialog requests 277 (if the keep-alive negotiation is for a dialog). Subsequent mid- 278 dialog requests 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 the topmost Via header field of 289 an ACK 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 the 300 topmost Via header field of an initial request for a dialog, and the 301 "keep" parameter in the associated response does not contain a 302 parameter value, the SIP entity might choose to insert a "keep" 303 parameter in the topmost Via header field of a subsequent SIP request 304 associated with the dialog, in case the new adjacent downstream SIP 305 entity (based on the dialog route set) is willing to receive keep- 306 alives (in which case it will add a parameter value to the "keep" 307 parameter). 309 If an INVITE request is used to indicate willingness to send keep- 310 alives, as long as at least one response (provisional or final) to 311 the INVITE request contains a "keep" parameter with a parameter 312 value, it is seen as an indication that the adjacent downstream SIP 313 entity is willing to receive keep-alives associated with the dialog 314 on which the response is received. 316 4.4. Behavior of a SIP entity willing to receive keep-alives 318 As defined in [RFC5626], a SIP entity that supports receiving of 319 keep-alives must act as a STUN server [RFC5389]. The SIP entity must 320 support those aspects of STUN that are required in order to apply the 321 STUN keep-alive mechanism defined in [RFC5626], and it must support 322 the CRLF keep-alive mechanism defined in [RFC5626]. 324 When a SIP entity sends or forwards a response, and the adjacent 325 upstream SIP entity indicated willingness to send keep-alives, if the 326 SIP entity is willing to receive keep-alives associated with the 327 registration, or the dialog, from the adjacent upstream SIP entity it 328 MUST add a parameter value to the "keep" parameter, before sending or 329 forwarding the response. The parameter value, if present and with a 330 value other than zero, represents a recommended keep-alive frequency, 331 given in seconds. 333 There might be multiple responses to an INVITE request. When a SIP 334 entity indicates willingness to receive keep-alives in a response to 335 an INVITE request, it MUST add a parameter value to the "keep" 336 parameter in at least one reliable response to the request. The SIP 337 entity MAY add identical parameter values to the "keep" parameters in 338 other responses to the same request. The SIP entity MUST NOT add 339 different parameter value to the "keep" parameters in responses to 340 the same request. The SIP entity SHOULD indicate the willingness to 341 receive keep-alives as soon as possible. 343 A SIP entity MUST NOT indicates willingness to receive keep-alives 344 associated with a dialog, unless it has also inserted itself in the 345 dialog route set [RFC3261]. 347 5. Keep-alive frequency 349 If a SIP entity receives a SIP response, where the topmost Via header 350 field contains a "keep" parameter with a non-zero value that 351 indicates a recommended keep-alive frequency, given in seconds, it 352 MUST use the procedures defined for the Flow-Timer header field 353 [RFC5626]. According to the procedures, the SIP entity must send 354 keep-alives at least as often as the indicated recommended keep-alive 355 frequency, and if the SIP entity uses the recommended keep-alive 356 frequency then it should send its keep-alives so that the interval 357 between each keep-alive is randomly distributed between 80% and 100% 358 of the recommended keep-alive frequency. 360 If the received "keep" parameter value is zero, the SIP entity can 361 send keep-alives at its discretion. [RFC5626] provides additional 362 guidance on selecting the keep-alive frequency in case a recommended 363 keep-alive frequency is not provided. 365 This specification does not specify actions to take if negotiated 366 keep-alives are not received. As defined in [RFC5626], the receiving 367 SIP entity may consider a connection to be dead in such situations. 369 If a SIP entity that adds a parameter value to the "keep" parameter, 370 in order to indicate willingness to receive keep-alives, also inserts 371 a Flow-Timer header field (that can happen if the SIP entity is using 372 both the Outbound mechanism and the keep-alive mechanism) in the same 373 SIP message, the header field value and the "keep" parameter value 374 MUST be identical. 376 SIP Outbound uses the Flow-Timer header field to indicate the server- 377 recommended keep-alive frequency. However, it will only be sent 378 between a UA and an edge proxy. Using the "keep" parameter, however, 379 the sending and receiving of keep-alives might be negotiated between 380 multiple entities on the signalling path. In addition, since the 381 server-recommended keep-alive frequency might vary between different 382 SIP entities, a single Flow-Timer header field can not be used to 383 indicate all the different frequency values. 385 6. Connection reuse 387 Keep-alives are often sent in order to keep NAT bindings open, so 388 that the NAT may be passed by SIP requests sent in the reverse 389 direction, reusing the same connection, or for non-connection- 390 oriented transport protocols, reusing the same path. This 391 specification does not define such connection reuse mechanism. The 392 keep-alive mechanism defined in this specification is only used to 393 negotiate the sending and receiving of keep-alives. Entities that 394 want to reuse connections need to use another mechanism to ensure 395 that security aspects associated with connection reuse are taken into 396 consideration. 398 RFC 5923 [RFC5923] specifies a mechanism for using connection- 399 oriented transports to send requests in the reverse direction, and an 400 entity that wants to use connection-reuse as well as indicate support 401 of keep-alives on that connection will insert both the "alias" 402 parameter defined in [RFC5923] as well as the "keep" parameter 403 defined in this specification. 405 SIP Outbound specifies how registration flows are used to send 406 requests in the reverse direction. 408 7. Examples 410 7.1. General 412 This section shows example flows where usage of keep-alives, 413 associated with a registration and a dialog, is negotiated between 414 different SIP entities. 416 NOTE: The examples do not show the actual syntactical encoding of the 417 request lines, response lines and the Via header fields, but rather a 418 pseudo code in order to identity the message type and to which SIP 419 entity a Via header field is associated. 421 7.2. Keep-alive negotiation associated with registration: UA-proxy 423 Figure 1 shows an example where Alice sends an REGISTER request. She 424 indicates willingness of sending keep-alive by inserting a "keep" 425 parameter in her Via header field of the request. The edge proxy 426 (P1) forwards the request towards the registrar. 428 P1 is willing to receive keep-alives from Alice for the duration of 429 the registration, so when P1 receives the associated response it adds 430 a "keep" parameter value, which indicates a recommended keep-alive 431 frequency of 30 seconds, to Alice's Via header field, before it 432 forwards the response towards Alice. 434 When Alice receives the response, she determines from her Via header 435 field that P1 is willing to receive keep-alives associated with the 436 registration. Until the registration expires, or Alice sends a 437 registration refresh request, Alice then sends periodic keep-alives 438 (in this example using the STUN keep-alive technique) towards P1, 439 using the recommended keep-alive frequency indicated by the "keep" 440 parameter value. 442 Alice P1 REGISTRAR 443 | | | 444 |--- REGISTER------------->| | 445 | Via: Alice;keep | | 446 | |--- REGISTER-------------->| 447 | | Via: P1 | 448 | | Via: Alice;keep | 449 | | | 450 | |<-- 200 OK ----------------| 451 | | Via: P1 | 452 | | Via: Alice;keep | 453 |<-- 200 OK ---------------| | 454 | Via: Alice;keep=30 | | 455 | | | 456 | | | 457 | *** Timeout *** | 458 | | | 459 |=== STUN request ========>| | 460 |<== STUN response ========| | 461 | | | 462 | *** Timeout *** | 463 | | | 464 |=== STUN request ========>| | 465 |<== STUN response ========| | 466 | | | 468 Figure 1: Example call flow 470 7.3. Keep-alive negotiation associated with dialog: UA-proxy 472 Figure 2 shows an example where Alice sends an initial INVITE request 473 for a dialog. She indicates willingness to send keep-alive by 474 inserting a "keep" parameter in her Via header field of the request. 475 The edge proxy (P1) adds itself to the dialog route set by adding 476 itself to a Record-Route header field, before it forwards the request 477 towards Bob. 479 P1 is willing to receive keep-alives from Alice for the duration of 480 the dialog, so When P1 receives the associated response it adds a 481 "keep" parameter value, which indicates a recommended keep-alive 482 frequency of 30 seconds, to Alice's Via header field, before it 483 forwards the response towards Alice. 485 When Alice receives the response, she determines from her Via header 486 field that P1 is willing to receive keep-alives associated with the 487 dialog. For the lifetime of the dialog, Alice then sends periodic 488 keep-alives (in this example using the STUN keep-alive technique) 489 towards P1, using the recommended keep-alive frequency indicated by 490 the "keep" parameter value. 492 Alice P1 Bob 493 | | | 494 |--- INVITE -------------->| | 495 | Via: Alice;keep | | 496 | |--- INVITE --------------->| 497 | | Via: P1 | 498 | | Via: Alice;keep | 499 | | Record-Route: P1 | 500 | | | 501 | |<-- 200 OK ----------------| 502 | | Via: P1 | 503 | | Via: Alice;keep | 504 | | Record-Route: P1 | 505 |<-- 200 OK ---------------| | 506 | Via: Alice;keep=30 | | 507 | Record-Route: P1 | | 508 | | | 509 |--- ACK ----------------->| | 510 | | | 511 | |--- ACK ------------------>| 512 | | | 513 | *** Timeout *** | 514 | | | 515 |=== STUN request ========>| | 516 |<== STUN response ========| | 517 | | | 518 | *** Timeout *** | 519 | | | 520 |=== STUN request ========>| | 521 |<== STUN response ========| | 522 | | | 523 | | | 524 |--- BYE ----------------->| | 525 | | | 526 | |--- BYE ------------------>| 527 | | | 528 | |<-- 200 OK ----------------| 529 | | | 531 Figure 2: Example call flow 533 7.4. Keep-alive negotiation associated with dialog: UA-UA 535 Figure 3 shows an example where Alice sends an initial INVITE request 536 for a dialog. She indicates willingness to send keep-alive by 537 inserting a "keep" parameter in her Via header field of the request. 538 The edge proxy (P1) does not add itself to the dialog route set, by 539 adding itself to a Record-Route header field, before it forwards the 540 request towards Bob. 542 When Alice receives the response, she determines from her Via header 543 field that P1 is not willing to receive keep-alives associated with 544 the dialog from her. When the dialog route set has been established, 545 Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not 546 insert itself in the dialog route set), and she once again indicates 547 willingness to send keep-alives by inserting a "keep" parameter in 548 her Via header field of the request. Bob supports the keep-alive 549 mechanism, and is willing to receive keep-alives associated with the 550 dialog from Alice, so he creates a response and adds a "keep" 551 parameter value, which indicates a recommended keep-alive frequency 552 of 30 seconds, to Alice's Via header field, before he forwards the 553 response towards Alice. 555 When Alice receives the response, she determines from her Via header 556 field that Bob is willing to receive keep-alives associated with the 557 dialog. For the lifetime of the dialog, Alice then sends periodic 558 keep-alives (in this example using the STUN keep-alive technique) 559 towards Bob, using the recommended keep-alive frequency indicated by 560 the "keep" parameter value. 562 Alice P1 Bob 563 | | | 564 |--- INVITE -------------->| | 565 | Via: Alice;keep | | 566 | |--- INVITE --------------->| 567 | | Via: P1 | 568 | | Via: Alice:keep | 569 | | | 570 | |<-- 200 OK ----------------| 571 | | Via: P1 | 572 | | Via: Alice;keep | 573 |<-- 200 OK ---------------| | 574 | Via: Alice;keep | | 575 | | | 576 | | 577 |--- ACK --------------------------------------------->| 578 | | 579 |--- UPDATE ------------------------------------------>| 580 | Via: Alice;keep | 581 | | 582 |<-- 200 OK ------------------------------------------>| 583 | Via: UAC;keep=30 | 584 | | 585 | | 586 | *** Timeout *** | 587 | | 588 |=== STUN request ====================================>| 589 |<== STUN response ====================================| 590 | | 591 | *** Timeout *** | 592 | | 593 |=== STUN request ====================================>| 594 |<== STUN response ====================================| 595 | | 596 | | 597 |--- BYE --------------------------------------------->| 598 | | 599 |<-- 200 OK -------------------------------------------| 600 | | 602 Figure 3: Example call flow 604 8. Grammar 606 This specification defines a new Via header field parameter, "keep". 608 The ABNF [RFC5234] is: 610 via-params =/ keep 612 keep = "keep" [ EQUAL 1*(DIGIT) ] 614 9. IANA Considerations 616 9.1. keep 618 This specification defines a new Via header field parameter called 619 keep in the "Header Field Parameters and Parameter Values" sub- 620 registry as per the registry created by [RFC3968]. The syntax is 621 defined in Section 8. The required information is: 623 Predefined 624 Header Field Parameter Name Values Reference 625 ---------------------- --------------------- ---------- --------- 626 Via keep No [RFCXXXX] 628 10. Security Considerations 630 SIP entities that send or receive keep-alives are often required to 631 use a connection reuse mechanism, in order to ensure that requests 632 sent in the reverse direction, towards the sender of the keep-alives, 633 traverse NATs etc. This specification does not specify a connection 634 reuse mechanism, and it does not address security issues related to 635 connection reuse. SIP entities that wish to reuse connections need 636 to use a dedicated connection reuse mechanism, in conjunction with 637 the keep-alive negotiation mechanism. 639 Unless SIP messages are integrity protected hop-by-hop (e.g. using 640 TLS or DTLS), a man-in-the-middle can modify Via header fields used 641 by two entities to negotiate sending of keep-alives, e.g. by removing 642 the indications used to indicate willingness to send and receive 643 keep-alives, or by decreasing the timer value to a very low value, 644 which might trigger additional resource consumption due to the 645 frequently sent keep-alives. 647 The behavior defined in Sections 4.3 and 4.4 require a SIP entity 648 using the mechanism defined in this specification to place a value in 649 the "keep" parameter in the topmost Via header field value of a 650 response the SIP entity sends. They do not instruct the entity to 651 place a value in a "keep" parameter of any request it forwards. In 652 particular, SIP proxies MUST NOT place a value into the keep 653 parameter of the topmost Via header field value of a request it 654 receives before forwarding it. A SIP proxy implementing this 655 specification SHOULD remove any keep parameter values in any Via 656 header field values below the topmost one in responses it receives 657 before forwarding them. 659 When requests are forwarded across multiple hops, it is possible for 660 a malicious downstream SIP entity to tamper with the accrued values 661 in the Via header field. The malicious SIP entity could place a 662 value, or change an existing value in a "keep" parameter in any of 663 the Via header field values, not just the topmost value. A proxy 664 implementation that simply forwards responses by stripping the 665 topmost Via header field value and not inspecting the resulting new 666 topmost Via header field value risks being adversely affected by such 667 a malicious downstream SIP entity. In particular, such a proxy may 668 start receiving STUN requests if it blindly forwards a response with 669 a keep parameter with a value it did not create in the topmost Via 670 header field. To lower the chances of the malicious SIP entity's 671 actions having adverse affects on such proxies, when a SIP entity 672 sends STUN keep-alives to an adjacent downstream SIP entity and does 673 not receive a response to those STUN messages, it MUST stop sending 674 the keep-alive requests for the remaining duration of the dialog (if 675 the sending of keep-alives were negotiated for a dialog) or until the 676 sending of keep-alives is re-negotiated for the registration (if the 677 sending keep-alives were negotiated for a registration). 679 Apart from the issues described above, this specification does not 680 introduce security considerations in addition to those specified for 681 keep-alives in [RFC5626]. 683 11. Acknowledgements 685 Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer 686 and Milo Orsic for their comments on the initial draft. Thanks to 687 Juha Heinaenen, Jiri Kuthan, Dean Willis, John Elwell, Paul Kyzivat, 688 Peter Musgrave, Dale Worley, Adam Roach and Robert Sparks for their 689 comments on the list. Thanks to Vijay Gurbani for providing text 690 about the relationship with the connect reuse specification. 692 12. Change Log 694 [RFC EDITOR NOTE: Please remove this section when publishing] 696 Changes from draft-ietf-sipcore-keep-10 697 o Editorial fixes based on IESG comments by Juergen Schoenwaelder 698 (Dec 21st) 699 o Editorial fixes based on IESG comments by Roni Even (Dec 28th) 701 Changes from draft-ietf-sipcore-keep-09 702 o Changes based on AD review comments by Robert Sparks 703 o Redundant paragraph removed from security considerations 705 Changes from draft-ietf-sipcore-keep-08 706 o Changes based on AD review comments by Robert Sparks 707 o Additional security considerations text provided by Robert Sparks 708 o http://www.ietf.org/mail-archive/web/sipcore/current/msg03779.html 709 (Nov 23rd) 710 o http://www.ietf.org/mail-archive/web/sipcore/current/msg03780.html 711 (Nov 23rd) 713 Changes from draft-ietf-sipcore-keep-07 714 o Last paragraph of section 4.2.2 removed 715 o Reference correction 717 Changes from draft-ietf-sipcore-keep-06 718 o New text added to the security considerations 720 Changes from draft-ietf-sipcore-keep-05 721 o New section about connection reuse added 722 o Clarify that the specification does not define a mechanism for 723 connection reuse 724 o New text added to the security considerations 725 o CRLF changed to double-CRLF in some places 727 13. References 729 13.1. Normative References 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, March 1997. 734 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 735 A., Peterson, J., Sparks, R., Handley, M., and E. 736 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 737 June 2002. 739 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 740 Specifications: ABNF", STD 68, RFC 5234, January 2008. 742 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 743 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 744 October 2008. 746 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 747 Initiated Connections in the Session Initiation Protocol 748 (SIP)", RFC 5626, October 2009. 750 13.2. Informative References 752 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 753 (IANA) Header Field Parameter Registry for the Session 754 Initiation Protocol (SIP)", BCP 98, RFC 3968, 755 December 2004. 757 [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in 758 the Session Initiation Protocol (SIP)", RFC 5923, 759 June 2010. 761 Author's Address 763 Christer Holmberg 764 Ericsson 765 Hirsalantie 11 766 Jorvas 02420 767 Finland 769 Email: christer.holmberg@ericsson.com