idnits 2.17.1 draft-ietf-sipcore-sessiontimer-race-02.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 (Using the creation date from RFC4028, updated by this document, for RFC5378 checks: 1999-10-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 30, 2018) is 2064 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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 Updates: 4028 (if approved) August 30, 2018 5 Intended status: Standards Track 6 Expires: March 3, 2019 8 Session Initiation Protocol (SIP) Session Timer Glare Handling 9 draft-ietf-sipcore-sessiontimer-race-02 11 Abstract 13 This document updates RFC 4028, by clarifying the procedures for 14 negotiating usage of the Session Initiation Protocol (SIP) session 15 timer mechansim, in order to avoid a race condition where both 16 endpoints trigger simultaneous negotiations. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 3, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 2 54 1.2. Solution . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Update to RFC 4028 . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Update to Section 7.2 . . . . . . . . . . . . . . . . . . 3 58 3.2. Update to Section 7.4 . . . . . . . . . . . . . . . . . . 4 59 3.3. Update to Section 8.1 . . . . . . . . . . . . . . . . . . 5 60 3.4. Update to Section 9 . . . . . . . . . . . . . . . . . . . 6 61 4. Security considerations . . . . . . . . . . . . . . . . . . . 7 62 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 63 6. Normative references . . . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 [RFC4028] defines a mechanism, where periodic SIP requests are sent 69 in order to allow SIP user agents and proxies to determine whether a 70 SIP session is still active. 72 The usage of the mechanism is negotiated using two new SIP header 73 fields (Session-Expires and Min-SE), a new option tag ('timer') and a 74 new SIP response code (422). 76 1.1. Problem Statement 78 1. Section 7.4 of [RFC4028] says that, in a session refresh request 79 sent within a dialog with an active session timer, the Session- 80 Expires header field should be included in the request. However, the 81 text is unclear regarding including the Session-Expires header field 82 in a session refresh request when a negotiation of session timer 83 usage is still ongoing, e.g., if one user agent is sending a request 84 that contains a Session-Expires header field and, before it receives 85 the associated 2xx response, receives a request from the peer user 86 agent that also contains a Session-Expires header field. Such 87 scenario might cause a glare situation, with conflicting negotiation 88 parameters. 90 2. The absence of the Session-Expires header field in a 2xx response 91 to an (re-)INVITE request [RFC3261] or UPDATE request [RFC3311] means 92 that the mechanism isn't used. This can be used to reject the usage 93 of the mechanism when sending a response. However, the text is 94 unclear that this only applies to cases where the associated SIP 95 request contained a Session-Expires header field. 97 1.2. Solution 99 This document updates [RFC4028], by clarifying the procedures for 100 negotiating usage of the Session Initiation Protocol (SIP) [RFC3261] 101 session timer mechanism [RFC4028]. The following clarifications are 102 provided: 104 o A Session-Expires header field can only be included in a session 105 refresh request if there is no ongoing negotiation of usage of the 106 session timer mechansim, and if there is no ongoing INVITE 107 transaction. 108 o A user agent shall, if it receives a session refresh equest with a 109 Session-Expires header field during an ongoing negotiation of 110 usage of the session timer mechanism, or when there is an ongoing 111 INVITE transaction, send a 491 (Request Pending) response to the 112 request. 113 o The absence of a Session-Expires header field in a response will 114 disable usage of the session timer mechanism only if the 115 associated requuest contained a Session-Expires header field. 117 2. Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. Update to RFC 4028 125 3.1. Update to Section 7.2 127 This section updates the third paragraph in section 7.2 of [RFC4028], 128 by clarifying that the absence of a Session-Expires header field in a 129 response will disable usage of the session timer mechanism only if 130 the associated request contained a Session-Expires header field. 132 OLD TEXT: 134 If the 2xx response did not contain a Session-Expires header field, 135 there is no session expiration. In this case, no refreshes need to 136 be sent. A 2xx without a Session-Expires can come for both initial 137 and subsequent session refresh requests. This means that the session 138 timer can be 'turned-off' in mid dialog by receiving a response 139 without a Session-Expires header field. 141 NEW TEXT: 143 If the request contained a Session-Expires header field, and the 144 associated 2xx response did not contain a Session-Expires header 145 field, there is no session expiration. In this case, no refreshes 146 need to be sent. A 2xx without a Session-Expires can come for both 147 initial and subsequent session refresh requests. This means that 148 the session timer can be 'turned-off' in mid dialog by receiving a 149 response without a Session-Expires header field. 151 3.2. Update to Section 7.4 153 This section updates the fifth paragraph in section 7.4 of [RFC4028], 154 by clarifying that the Session-Expires header field can only be 155 included in a refresh request if there is no ongoing negotiation of 156 usage of the session timer mechanism. 158 OLD TEXT: 160 In a session refresh request sent within a dialog with an active 161 session timer, the Session-Expires header field SHOULD be present. 162 When present, it SHOULD be equal to the maximum of the Min-SE header 163 field (recall that its default value when not present is 90 seconds) 164 and the current session interval. Inclusion of the Session-Expires 165 header field with this value avoids certain denial-of-service 166 attacks, as documented in Section 11. As such, a UA should only 167 ignore the SHOULD in unusual and singular cases where it is 168 desirable to change the session interval mid-dialog. 170 NEW TEXT: 172 In a session refresh request sent within a dialog with an active 173 session timer, if there is no ongoing negotiation of usage of the 174 session timer mechanism and if there is no ongoing INVITE 175 transaction (with or without session timer negotiation), the 176 Session-Expires header field SHOULD be present. If there is an 177 ongoing negotiation, or if there is an ongoing INVIET transaction, 178 the Session-Expires header field MUST NOT be present. When present, 179 it SHOULD be equal to the maximum of the Min-SE header field (recall 180 that its default value when not present is 90 seconds) and the 181 current session interval. Inclusion of the Session-Expires header 182 field with this value avoids certain denial-of-service attacks, as 183 documented in Section 11. As such, a UA should only ignore the 184 SHOULD in unusual and singular cases where it is desirable to 185 change the session interval mid-dialog. 187 3.3. Update to Section 8.1 189 This section updates the second paragraph section 8.1 of [RFC4028], 190 by clarifying that a proxy can insert a Session-Expires header field 191 in a request only if there is no ongoing negotiation of usage of the 192 session timer mechanism and if there is no ongoing INVITE 193 transaction. 195 OLD TEXT: 197 To request a session timer for a session, a proxy makes sure that a 198 Session-Expires header field is present in a session refresh request 199 for that session. A proxy MAY insert a Session-Expires header field 200 in the request before forwarding it if none was present in the 201 request. This Session-Expires header field may contain any desired 202 expiration time the proxy would like, but not with a duration lower 203 than the value in the Min-SE header field in the request, if it is 204 present. The proxy MUST NOT include a refresher parameter in the 205 header field value. 207 NEW TEXT: 209 To request a session timer for a session, a proxy makes sure that a 210 Session-Expires header field is present in a session refresh request 211 for that session. A proxy MAY insert a Session-Expires header field 212 in the request before forwarding it if none was present in the 213 request, if there is no ongoing negotiation of usage of the 214 session timer mechanism and if there is no ongoing INVITE 215 transaction (with or without session timer negotiation). This 216 Session-Expires header field may contain any desired expiration time 217 the proxy would like, but not with a duration lower than the value 218 in the Min-SE header field in the request, if it is present. The 219 proxy MUST NOT include a refresher parameter in the header field 220 value. 222 3.4. Update to Section 9 224 This section updates section 8.1 of [RFC4028], by clarifying that a 225 session refresh request that is received while there is an ongoing 226 negotiation of usage of the session timer mechanism shall be rejected 227 by a 491 (Request Pending) response. The clarification is done by 228 adding a new paragraph between the fouth and fifth paragraphs of the 229 section. 231 NEW TEXT: 233 If an incoming request contains a Session-Expires header field, 234 and there is on ongoing negotiation of usage of the session timer 235 mechanism, or if there is an ongoing INVITE transaction (with or 236 without session timer negotiation), the UAS MUST reject the request 237 with a 491 (Request Pending) response. 239 4. Security considerations 241 The security considerations associated with the SIP Session-Timer 242 mechanism are described in [RFC4028]. This specification adds 243 clarification text for avoiding session-timer negotiation race 244 conditions, and does not introduce new security considerations. 246 5. IANA considerations 248 This specification makes no requests from IANA. 250 6. Normative references 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, 254 DOI 10.17487/RFC2119, March 1997, . 257 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 258 A., Peterson, J., Sparks, R., Handley, M., and E. 259 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 260 DOI 10.17487/RFC3261, June 2002, . 263 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 264 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 265 2002, . 267 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the 268 Session Initiation Protocol (SIP)", RFC 4028, 269 DOI 10.17487/RFC4028, April 2005, . 272 Author's Address 274 Christer Holmberg 275 Ericsson 276 Hirsalantie 11 277 Jorvas 02420 278 Finland 280 Email: christer.holmberg@ericsson.com