draft-ietf-sipcore-sessiontimer-race-00.txt   draft-ietf-sipcore-sessiontimer-race-01.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 4028 (if approved) October 4, 2017 Updates: 4028 (if approved) March 5, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: April 7, 2018 Expires: September 6, 2018
Session Initiation Protocol (SIP) Session Timer Glare Handling Session Initiation Protocol (SIP) Session Timer Glare Handling
draft-ietf-sipcore-sessiontimer-race-00 draft-ietf-sipcore-sessiontimer-race-01
Abstract Abstract
This document updates RFC 4028, by clarifying the procedures for This document updates RFC 4028, by clarifying the procedures for
negotiating usage of the Session Initiation Protocol (SIP) session negotiating usage of the Session Initiation Protocol (SIP) session
timer mechansim, in order to avoid a race condition where both timer mechansim, in order to avoid a race condition where both
endpoints trigger simultaneous negotiations. endpoints trigger simultaneous negotiations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 7, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 2 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 2
1.2. Solution . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Solution . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Update to RFC 4028 . . . . . . . . . . . . . . . . . . . . . 3 3. Update to RFC 4028 . . . . . . . . . . . . . . . . . . . . . 3
3.1. Update to Section 7.2 . . . . . . . . . . . . . . . . . . 3 3.1. Update to Section 7.2 . . . . . . . . . . . . . . . . . . 3
3.2. Update to Section 7.4 . . . . . . . . . . . . . . . . . . 4 3.2. Update to Section 7.4 . . . . . . . . . . . . . . . . . . 4
3.3. Update to Section 8.1 . . . . . . . . . . . . . . . . . . 5 3.3. Update to Section 8.1 . . . . . . . . . . . . . . . . . . 5
3.4. Update to Section 9 . . . . . . . . . . . . . . . . . . . 6 3.4. Update to Section 9 . . . . . . . . . . . . . . . . . . . 6
4. Security considerations . . . . . . . . . . . . . . . . . . . 7 4. Security considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Normative references . . . . . . . . . . . . . . . . . . . . 7
7. Normative references . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
[RFC4028] defines a mechanism, where periodic SIP requests are sent [RFC4028] defines a mechanism, where periodic SIP requests are sent
in order to allow SIP user agents and proxies to determine whether a in order to allow SIP user agents and proxies to determine whether a
SIP session is still active. SIP session is still active.
The usage of the mechanism is negotiated using two new SIP header 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 fields (Session-Expires and Min-SE), a new option tag ('timer') and a
skipping to change at page 3, line 14 skipping to change at page 3, line 14
1.2. Solution 1.2. Solution
This document updates [RFC4028], by clarifying the procedures for This document updates [RFC4028], by clarifying the procedures for
negotiating usage of the Session Initiation Protocol (SIP) [RFC3261] negotiating usage of the Session Initiation Protocol (SIP) [RFC3261]
session timer mechanism [RFC4028]. The following clarifications are session timer mechanism [RFC4028]. The following clarifications are
provided: provided:
o A Session-Expires header field can only be included in a session 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 refresh request if there is no ongoing negotiation of usage of the
session timer mechansim. session timer mechansim, and if there is no ongoing INVITE
o A user agent shall, if it receives a session request with a transaction.
o A user agent shall, if it receives a session refresh equest with a
Session-Expires header field during an ongoing negotiation of Session-Expires header field during an ongoing negotiation of
usage of the session timer mechanism, send a 491 (Request Pending) usage of the session timer mechanism, or when there is an ongoing
response to the request. INVITE transaction, send a 491 (Request Pending) response to the
request.
o The absence of a Session-Expires header field in a response will o The absence of a Session-Expires header field in a response will
disable usage of the session timer mechanism only if the disable usage of the session timer mechanism only if the
associated requuest contained a Session-Expires header field. associated requuest contained a Session-Expires header field.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 5, line 20 skipping to change at page 5, line 20
field (recall that its default value when not present is 90 seconds) field (recall that its default value when not present is 90 seconds)
and the current session interval. Inclusion of the Session-Expires and the current session interval. Inclusion of the Session-Expires
header field with this value avoids certain denial-of-service header field with this value avoids certain denial-of-service
attacks, as documented in Section 11. As such, a UA should only attacks, as documented in Section 11. As such, a UA should only
ignore the SHOULD in unusual and singular cases where it is ignore the SHOULD in unusual and singular cases where it is
desirable to change the session interval mid-dialog. desirable to change the session interval mid-dialog.
NEW TEXT: NEW TEXT:
In a session refresh request sent within a dialog with an active In a session refresh request sent within a dialog with an active
session timer, and when there is no ongoing negotiation of usage session timer, if there is no ongoing negotiation of usage of the
of the session timer mechanism, the Session-Expires header field session timer mechanism and if there is no ongoing INVITE
SHOULD be present. If there is an ongoing negotiation, the transaction (with or without session timer negotiation), the
Session-Expires header field MUST NOT be present. When present, it Session-Expires header field SHOULD be present. If there is an
SHOULD be equal to the maximum of the Min-SE header field (recall 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 that its default value when not present is 90 seconds) and the
current session interval. Inclusion of the Session-Expires header current session interval. Inclusion of the Session-Expires header
field with this value avoids certain denial-of-service attacks, as field with this value avoids certain denial-of-service attacks, as
documented in Section 11. As such, a UA should only ignore the documented in Section 11. As such, a UA should only ignore the
SHOULD in unusual and singular cases where it is desirable to SHOULD in unusual and singular cases where it is desirable to
change the session interval mid-dialog. change the session interval mid-dialog.
3.3. Update to Section 8.1 3.3. Update to Section 8.1
This section updates the second paragraph section 8.1 of [RFC4028], This section updates the second paragraph section 8.1 of [RFC4028],
by clarifying that a proxy can insert a Session-Expires header field 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 in a request only if there is no ongoing negotiation of usage of the
session timer mechanism. session timer mechanism and if there is no ongoing INVITE
transaction.
OLD TEXT: OLD TEXT:
To request a session timer for a session, a proxy makes sure that a 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 Session-Expires header field is present in a session refresh request
for that session. A proxy MAY insert a Session-Expires header field for that session. A proxy MAY insert a Session-Expires header field
in the request before forwarding it if none was present in the in the request before forwarding it if none was present in the
request. This Session-Expires header field may contain any desired request. This Session-Expires header field may contain any desired
expiration time the proxy would like, but not with a duration lower 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 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 present. The proxy MUST NOT include a refresher parameter in the
header field value. header field value.
NEW TEXT: NEW TEXT:
To request a session timer for a session, a proxy makes sure that a 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 Session-Expires header field is present in a session refresh request
for that session. A proxy MAY insert a Session-Expires header field for that session. A proxy MAY insert a Session-Expires header field
in the request before forwarding it if none was present in the in the request before forwarding it if none was present in the
request, and if there is no ongoing negotiation of usage of the request, if there is no ongoing negotiation of usage of the
session timer mechanism. This Session-Expires header field may session timer mechanism and if there is no ongoing INVITE
contain any desired expiration time the proxy would like, but not transaction (with or without session timer negotiation). This
with a duration lower than the value in the Min-SE header field in Session-Expires header field may contain any desired expiration time
the request, if it is present. The proxy MUST NOT include a refresher the proxy would like, but not with a duration lower than the value
parameter in the header field 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 3.4. Update to Section 9
This section updates section 8.1 of [RFC4028], by clarifying that a This section updates section 8.1 of [RFC4028], by clarifying that a
session refresh request that is received while there is an ongoing session refresh request that is received while there is an ongoing
negotiation of usage of the session timer mechanism shall be rejected negotiation of usage of the session timer mechanism shall be rejected
by a 491 (Request Pending) response. The clarification is done by by a 491 (Request Pending) response. The clarification is done by
adding a new paragraph between the fouth and fifth paragraphs of the adding a new paragraph between the fouth and fifth paragraphs of the
section. section.
NEW TEXT: NEW TEXT:
If an incoming request contains a Session-Expires header field, If an incoming request contains a Session-Expires header field,
and there is on ongoing negotiation of usage of the session timer and there is on ongoing negotiation of usage of the session timer
mechanism, the UAS MUST reject the request with a 491 (Request mechanism, or if there is an ongoing INVITE transaction (with or
Pending) response. without session timer negotiation), the UAS MUST reject the request
with a 491 (Request Pending) response.
4. Security considerations 4. Security considerations
The security considerations associated with the SIP Session-Timer The security considerations associated with the SIP Session-Timer
mechanism are described in [RFC4028]. This specification adds mechanism are described in [RFC4028]. This specification adds
clarification text for avoiding session-timer negotiation race clarification text for avoiding session-timer negotiation race
conditions, and does not introduce new security considerations. conditions, and does not introduce new security considerations.
5. IANA considerations 5. IANA considerations
This specification makes no requests from IANA. This specification makes no requests from IANA.
6. Change log 6. Normative references
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-holmberg-sipcore-sessiontimer-race-00
o Submission of draft-ietf-sipcore-sessiontimer-race-00
7. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
2002, <https://www.rfc-editor.org/info/rfc3311>. 2002, <https://www.rfc-editor.org/info/rfc3311>.
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the
Session Initiation Protocol (SIP)", RFC 4028, Session Initiation Protocol (SIP)", RFC 4028,
DOI 10.17487/RFC4028, April 2005, DOI 10.17487/RFC4028, April 2005, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4028>. editor.org/info/rfc4028>.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
 End of changes. 23 change blocks. 
60 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/