idnits 2.17.1 draft-ietf-sipcore-sessiontimer-race-00.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 (October 4, 2017) is 2396 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) October 4, 2017 5 Intended status: Standards Track 6 Expires: April 7, 2018 8 Session Initiation Protocol (SIP) Session Timer Glare Handling 9 draft-ietf-sipcore-sessiontimer-race-00 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 https://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 April 7, 2018. 35 Copyright Notice 37 Copyright (c) 2017 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 (https://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. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. Normative references . . . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 [RFC4028] defines a mechanism, where periodic SIP requests are sent 70 in order to allow SIP user agents and proxies to determine whether a 71 SIP session is still active. 73 The usage of the mechanism is negotiated using two new SIP header 74 fields (Session-Expires and Min-SE), a new option tag ('timer') and a 75 new SIP response code (422). 77 1.1. Problem Statement 79 1. Section 7.4 of [RFC4028] says that, in a session refresh request 80 sent within a dialog with an active session timer, the Session- 81 Expires header field should be included in the request. However, the 82 text is unclear regarding including the Session-Expires header field 83 in a session refresh request when a negotiation of session timer 84 usage is still ongoing, e.g., if one user agent is sending a request 85 that contains a Session-Expires header field and, before it receives 86 the associated 2xx response, receives a request from the peer user 87 agent that also contains a Session-Expires header field. Such 88 scenario might cause a glare situation, with conflicting negotiation 89 parameters. 91 2. The absence of the Session-Expires header field in a 2xx response 92 to an (re-)INVITE request [RFC3261] or UPDATE request [RFC3311] means 93 that the mechanism isn't used. This can be used to reject the usage 94 of the mechanism when sending a response. However, the text is 95 unclear that this only applies to cases where the associated SIP 96 request contained a Session-Expires header field. 98 1.2. Solution 100 This document updates [RFC4028], by clarifying the procedures for 101 negotiating usage of the Session Initiation Protocol (SIP) [RFC3261] 102 session timer mechanism [RFC4028]. The following clarifications are 103 provided: 105 o A Session-Expires header field can only be included in a session 106 refresh request if there is no ongoing negotiation of usage of the 107 session timer mechansim. 108 o A user agent shall, if it receives a session request with a 109 Session-Expires header field during an ongoing negotiation of 110 usage of the session timer mechanism, send a 491 (Request Pending) 111 response to the request. 112 o The absence of a Session-Expires header field in a response will 113 disable usage of the session timer mechanism only if the 114 associated requuest contained a Session-Expires header field. 116 2. Conventions 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. Update to RFC 4028 124 3.1. Update to Section 7.2 126 This section updates the third paragraph in section 7.2 of [RFC4028], 127 by clarifying that the absence of a Session-Expires header field in a 128 response will disable usage of the session timer mechanism only if 129 the associated request contained a Session-Expires header field. 131 OLD TEXT: 133 If the 2xx response did not contain a Session-Expires header field, 134 there is no session expiration. In this case, no refreshes need to 135 be sent. A 2xx without a Session-Expires can come for both initial 136 and subsequent session refresh requests. This means that the session 137 timer can be 'turned-off' in mid dialog by receiving a response 138 without a Session-Expires header field. 140 NEW TEXT: 142 If the request contained a Session-Expires header field, and the 143 associated 2xx response did not contain a Session-Expires header 144 field, there is no session expiration. In this case, no refreshes 145 need to be sent. A 2xx without a Session-Expires can come for both 146 initial and subsequent session refresh requests. This means that 147 the session timer can be 'turned-off' in mid dialog by receiving a 148 response without a Session-Expires header field. 150 3.2. Update to Section 7.4 152 This section updates the fifth paragraph in section 7.4 of [RFC4028], 153 by clarifying that the Session-Expires header field can only be 154 included in a refresh request if there is no ongoing negotiation of 155 usage of the session timer mechanism. 157 OLD TEXT: 159 In a session refresh request sent within a dialog with an active 160 session timer, the Session-Expires header field SHOULD be present. 161 When present, it SHOULD be equal to the maximum of the Min-SE header 162 field (recall that its default value when not present is 90 seconds) 163 and the current session interval. Inclusion of the Session-Expires 164 header field with this value avoids certain denial-of-service 165 attacks, as documented in Section 11. As such, a UA should only 166 ignore the SHOULD in unusual and singular cases where it is 167 desirable to change the session interval mid-dialog. 169 NEW TEXT: 171 In a session refresh request sent within a dialog with an active 172 session timer, and when there is no ongoing negotiation of usage 173 of the session timer mechanism, the Session-Expires header field 174 SHOULD be present. If there is an ongoing negotiation, the 175 Session-Expires header field MUST NOT be present. When present, it 176 SHOULD be equal to the maximum of the Min-SE header field (recall 177 that its default value when not present is 90 seconds) and the 178 current session interval. Inclusion of the Session-Expires header 179 field with this value avoids certain denial-of-service attacks, as 180 documented in Section 11. As such, a UA should only ignore the 181 SHOULD in unusual and singular cases where it is desirable to 182 change the session interval mid-dialog. 184 3.3. Update to Section 8.1 186 This section updates the second paragraph section 8.1 of [RFC4028], 187 by clarifying that a proxy can insert a Session-Expires header field 188 in a request only if there is no ongoing negotiation of usage of the 189 session timer mechanism. 191 OLD TEXT: 193 To request a session timer for a session, a proxy makes sure that a 194 Session-Expires header field is present in a session refresh request 195 for that session. A proxy MAY insert a Session-Expires header field 196 in the request before forwarding it if none was present in the 197 request. This Session-Expires header field may contain any desired 198 expiration time the proxy would like, but not with a duration lower 199 than the value in the Min-SE header field in the request, if it is 200 present. The proxy MUST NOT include a refresher parameter in the 201 header field value. 203 NEW TEXT: 205 To request a session timer for a session, a proxy makes sure that a 206 Session-Expires header field is present in a session refresh request 207 for that session. A proxy MAY insert a Session-Expires header field 208 in the request before forwarding it if none was present in the 209 request, and if there is no ongoing negotiation of usage of the 210 session timer mechanism. This Session-Expires header field may 211 contain any desired expiration time the proxy would like, but not 212 with a duration lower than the value in the Min-SE header field in 213 the request, if it is present. The proxy MUST NOT include a refresher 214 parameter in the header field value. 216 3.4. Update to Section 9 218 This section updates section 8.1 of [RFC4028], by clarifying that a 219 session refresh request that is received while there is an ongoing 220 negotiation of usage of the session timer mechanism shall be rejected 221 by a 491 (Request Pending) response. The clarification is done by 222 adding a new paragraph between the fouth and fifth paragraphs of the 223 section. 225 NEW TEXT: 227 If an incoming request contains a Session-Expires header field, 228 and there is on ongoing negotiation of usage of the session timer 229 mechanism, the UAS MUST reject the request with a 491 (Request 230 Pending) response. 232 4. Security considerations 234 The security considerations associated with the SIP Session-Timer 235 mechanism are described in [RFC4028]. This specification adds 236 clarification text for avoiding session-timer negotiation race 237 conditions, and does not introduce new security considerations. 239 5. IANA considerations 241 This specification makes no requests from IANA. 243 6. Change log 245 [RFC EDITOR NOTE: Please remove this section when publishing] 247 Changes from draft-holmberg-sipcore-sessiontimer-race-00 249 o Submission of draft-ietf-sipcore-sessiontimer-race-00 251 7. Normative references 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, 255 DOI 10.17487/RFC2119, March 1997, 256 . 258 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 259 A., Peterson, J., Sparks, R., Handley, M., and E. 260 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 261 DOI 10.17487/RFC3261, June 2002, 262 . 264 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 265 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 266 2002, . 268 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the 269 Session Initiation Protocol (SIP)", RFC 4028, 270 DOI 10.17487/RFC4028, April 2005, 271 . 273 Author's Address 274 Christer Holmberg 275 Ericsson 276 Hirsalantie 11 277 Jorvas 02420 278 Finland 280 Email: christer.holmberg@ericsson.com