SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson
Updates: 4028 (if approved) October 4, 2017
Intended status: Standards Track
Expires: April 7, 2018

Session Initiation Protocol (SIP) Session Timer Glare Handling
draft-ietf-sipcore-sessiontimer-race-00

Abstract

This document updates RFC 4028, by clarifying the procedures for negotiating usage of the Session Initiation Protocol (SIP) session timer mechansim, in order to avoid a race condition where both endpoints trigger simultaneous negotiations.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 7, 2018.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

[RFC4028] defines a mechanism, where periodic SIP requests are sent in order to allow SIP user agents and proxies to determine whether a SIP session is still active.

The usage of the mechanism is negotiated using two new SIP header fields (Session-Expires and Min-SE), a new option tag ('timer') and a new SIP response code (422).

1.1. Problem Statement

1. Section 7.4 of [RFC4028] says that, in a session refresh request sent within a dialog with an active session timer, the Session-Expires header field should be included in the request. However, the text is unclear regarding including the Session-Expires header field in a session refresh request when a negotiation of session timer usage is still ongoing, e.g., if one user agent is sending a request that contains a Session-Expires header field and, before it receives the associated 2xx response, receives a request from the peer user agent that also contains a Session-Expires header field. Such scenario might cause a glare situation, with conflicting negotiation parameters.

2. The absence of the Session-Expires header field in a 2xx response to an (re-)INVITE request [RFC3261] or UPDATE request [RFC3311] means that the mechanism isn't used. This can be used to reject the usage of the mechanism when sending a response. However, the text is unclear that this only applies to cases where the associated SIP request contained a Session-Expires header field.

1.2. Solution

This document updates [RFC4028], by clarifying the procedures for negotiating usage of the Session Initiation Protocol (SIP) [RFC3261] session timer mechanism [RFC4028]. The following clarifications are provided:

2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Update to RFC 4028

3.1. Update to Section 7.2

This section updates the third paragraph in section 7.2 of [RFC4028], by clarifying that the absence of a Session-Expires header field in a response will disable usage of the session timer mechanism only if the associated request contained a Session-Expires header field.


OLD TEXT:

   If the 2xx response did not contain a Session-Expires header field,
   there is no session expiration. In this case, no refreshes need to
   be sent. A 2xx without a Session-Expires can come for both initial
   and subsequent session refresh requests. This means that the session
   timer can be 'turned-off' in mid dialog by receiving a response
   without a Session-Expires header field.


NEW TEXT:

   If the request contained a Session-Expires header field, and the
   associated 2xx response did not contain a Session-Expires header
   field, there is no session expiration. In this case, no refreshes
   need to be sent. A 2xx without a Session-Expires can come for both
   initial and subsequent session refresh requests. This means that
   the session timer can be 'turned-off' in mid dialog by receiving a
   response without a Session-Expires header field.

       

3.2. Update to Section 7.4

This section updates the fifth paragraph in section 7.4 of [RFC4028], by clarifying that the Session-Expires header field can only be included in a refresh request if there is no ongoing negotiation of usage of the session timer mechanism.


OLD TEXT:

   In a session refresh request sent within a dialog with an active
   session timer, the Session-Expires header field SHOULD be present.
   When present, it SHOULD be equal to the maximum of the Min-SE header
   field (recall that its default value when not present is 90 seconds)
   and the current session interval. Inclusion of the Session-Expires
   header field with this value avoids certain denial-of-service
   attacks, as documented in Section 11. As such, a UA should only
   ignore the SHOULD in unusual and singular cases where it is 
   desirable to change the session interval mid-dialog.


NEW TEXT:

   In a session refresh request sent within a dialog with an active
   session timer, and when there is no ongoing negotiation of usage
   of the session timer mechanism, the Session-Expires header field 
   SHOULD be present. If there is an ongoing negotiation, the
   Session-Expires header field MUST NOT be present. When present, it
   SHOULD be equal to the maximum of the Min-SE header field (recall
   that its default value when not present is 90 seconds) and the 
   current session interval. Inclusion of the Session-Expires header
   field with this value avoids certain denial-of-service attacks, as
   documented in Section 11. As such, a UA should only ignore the 
   SHOULD in unusual and singular cases where it is desirable to 
   change the session interval mid-dialog.

       

3.3. Update to Section 8.1

This section updates the second paragraph section 8.1 of [RFC4028], by clarifying that a proxy can insert a Session-Expires header field in a request only if there is no ongoing negotiation of usage of the session timer mechanism.


OLD TEXT:

   To request a session timer for a session, a proxy makes sure that a
   Session-Expires header field is present in a session refresh request
   for that session. A proxy MAY insert a Session-Expires header field
   in the request before forwarding it if none was present in the
   request. This Session-Expires header field may contain any desired
   expiration time the proxy would like, but not with a duration lower
   than the value in the Min-SE header field in the request, if it is
   present. The proxy MUST NOT include a refresher parameter in the
   header field value.

NEW TEXT:

   To request a session timer for a session, a proxy makes sure that a
   Session-Expires header field is present in a session refresh request
   for that session. A proxy MAY insert a Session-Expires header field
   in the request before forwarding it if none was present in the
   request, and if there is no ongoing negotiation of usage of the
   session timer mechanism. This Session-Expires header field may 
   contain any desired expiration time the proxy would like, but not 
   with a duration lower than the value in the Min-SE header field in 
   the request, if it is present. The proxy MUST NOT include a refresher 
   parameter in the header field value.

       

3.4. Update to Section 9

This section updates section 8.1 of [RFC4028], by clarifying that a session refresh request that is received while there is an ongoing negotiation of usage of the session timer mechanism shall be rejected by a 491 (Request Pending) response. The clarification is done by adding a new paragraph between the fouth and fifth paragraphs of the section.


NEW TEXT:

   If an incoming request contains a Session-Expires header field,
   and there is on ongoing negotiation of usage of the session timer
   mechanism, the UAS MUST reject the request with a 491 (Request 
   Pending) response.

       

4. Security considerations

The security considerations associated with the SIP Session-Timer mechanism are described in [RFC4028]. This specification adds clarification text for avoiding session-timer negotiation race conditions, and does not introduce new security considerations.

5. IANA considerations

This specification makes no requests from IANA.

6. Change log

[RFC EDITOR NOTE: Please remove this section when publishing]

Changes from draft-holmberg-sipcore-sessiontimer-race-00

7. Normative references

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 2002.
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, DOI 10.17487/RFC4028, April 2005.

Author's Address

Christer Holmberg Ericsson Hirsalantie 11 Jorvas, 02420 Finland EMail: christer.holmberg@ericsson.com