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

SIPCORE Working Group                                        C. Holmberg
Internet-Draft                                                  Ericsson
Updates: 4028 (if approved)                                March 5, 2018
Intended status: Standards Track
Expires: September 6, 2018

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

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 http://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 September 6, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (http://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.

Holmberg                Expires September 6, 2018               [Page 1]
Internet-Draft             Session timer glare                March 2018

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Solution  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Update to RFC 4028  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Update to Section 7.2 . . . . . . . . . . . . . . . . . .   3
     3.2.  Update to Section 7.4 . . . . . . . . . . . . . . . . . .   4
     3.3.  Update to Section 8.1 . . . . . . . . . . . . . . . . . .   5
     3.4.  Update to Section 9 . . . . . . . . . . . . . . . . . . .   6
   4.  Security considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Normative references  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

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.

Holmberg                Expires September 6, 2018               [Page 2]
Internet-Draft             Session timer glare                March 2018

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:

   o  A Session-Expires header field can only be included in a session
      refresh request if there is no ongoing negotiation of usage of the
      session timer mechansim, and if there is no ongoing INVITE
      transaction.
   o  A user agent shall, if it receives a session refresh equest with a
      Session-Expires header field during an ongoing negotiation of
      usage of the session timer mechanism, or when there is an ongoing
      INVITE transaction, send a 491 (Request Pending) response to the
      request.
   o  The absence of a Session-Expires header field in a response will
      disable usage of the session timer mechanism only if the
      associated requuest contained a Session-Expires header field.

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.

Holmberg                Expires September 6, 2018               [Page 3]
Internet-Draft             Session timer glare                March 2018

 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.

Holmberg                Expires September 6, 2018               [Page 4]
Internet-Draft             Session timer glare                March 2018

 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, if there is no ongoing negotiation of usage of the
    session timer mechanism and if there is no ongoing INVITE
    transaction (with or without session timer negotiation), the
    Session-Expires header field SHOULD be present. If there is an
    ongoing negotiation, or if there is an ongoing INVIET transaction,
    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 and if there is no ongoing INVITE
   transaction.

Holmberg                Expires September 6, 2018               [Page 5]
Internet-Draft             Session timer glare                March 2018

 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, if there is no ongoing negotiation of usage of the
    session timer mechanism and if there is no ongoing INVITE
    transaction (with or without session timer negotiation). 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, or if there is an ongoing INVITE transaction (with or
     without session timer negotiation), the UAS MUST reject the request
     with a 491 (Request Pending) response.

Holmberg                Expires September 6, 2018               [Page 6]
Internet-Draft             Session timer glare                March 2018

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.  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, <https://www.rfc-
              editor.org/info/rfc2119>.

   [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, <https://www.rfc-
              editor.org/info/rfc3261>.

   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
              UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
              2002, <https://www.rfc-editor.org/info/rfc3311>.

   [RFC4028]  Donovan, S. and J. Rosenberg, "Session Timers in the
              Session Initiation Protocol (SIP)", RFC 4028,
              DOI 10.17487/RFC4028, April 2005, <https://www.rfc-
              editor.org/info/rfc4028>.

Author's Address

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com

Holmberg                Expires September 6, 2018               [Page 7]