draft-ietf-sipcore-keep-10.txt   draft-ietf-sipcore-keep-11.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track December 15, 2010 Intended status: Standards Track January 10, 2011
Expires: June 18, 2011 Expires: July 14, 2011
Indication of support for keep-alive Indication of support for keep-alive
draft-ietf-sipcore-keep-10.txt draft-ietf-sipcore-keep-11.txt
Abstract Abstract
This specification defines a new Session Initiation Protocol (SIP) This specification defines a new Session Initiation Protocol (SIP)
Via header field parameter, "keep", which allows adjacent SIP Via header field parameter, "keep", which allows adjacent SIP
entities to explicitly negotiate usage of the Network Address entities to explicitly negotiate usage of the Network Address
Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in
cases where SIP Outbound is not supported, cannot be applied, or cases where SIP Outbound is not supported, cannot be applied, or
where usage of keep-alives is not implicitly negotiated as part of where usage of keep-alives is not implicitly negotiated as part of
the SIP Outbound negotiation. the SIP Outbound negotiation.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 http://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 June 18, 2011. This Internet-Draft will expire on July 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
(http://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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.2.3. Keep-alives associated with dialog . . . . . . . . . . 6 4.2.3. Keep-alives associated with dialog . . . . . . . . . . 6
4.3. Behavior of a SIP entity willing to send keep-alives . . . 6 4.3. Behavior of a SIP entity willing to send keep-alives . . . 6
4.4. Behavior of a SIP entity willing to receive keep-alives . 7 4.4. Behavior of a SIP entity willing to receive keep-alives . 7
5. Keep-alive frequency . . . . . . . . . . . . . . . . . . . . . 8 5. Keep-alive frequency . . . . . . . . . . . . . . . . . . . . . 8
6. Connection reuse . . . . . . . . . . . . . . . . . . . . . . . 9 6. Connection reuse . . . . . . . . . . . . . . . . . . . . . . . 9
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Keep-alive negotiation associated with registration: 7.2. Keep-alive negotiation associated with registration:
UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 10 UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. Keep-alive negotiation associated with dialog: UA-proxy . 11 7.3. Keep-alive negotiation associated with dialog: UA-proxy . 11
7.4. Keep-alive negotiation associated with dialog: UA-UA . . . 12 7.4. Keep-alive negotiation associated with dialog: UA-UA . . . 13
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. keep . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 5, line 25 skipping to change at page 5, line 25
to send keep-alives, even if they are not aware of any necessity for to send keep-alives, even if they are not aware of any necessity for
them to send keep-alives, since the adjacent downstream SIP entity them to send keep-alives, since the adjacent downstream SIP entity
might have knowledge about the necessity. Similarly, if the adjacent might have knowledge about the necessity. Similarly, if the adjacent
upstream SIP entity has indicated willingness to send keep-alives, it upstream SIP entity has indicated willingness to send keep-alives, it
can be useful for SIP entities to indicate willingness to receive can be useful for SIP entities to indicate willingness to receive
keep-alives, even if they are not aware of any necessity for the keep-alives, even if they are not aware of any necessity for the
adjacent upstream SIP entity to send them. adjacent upstream SIP entity to send them.
NOTE: Usage of keep-alives is negotiated per direction. If a SIP NOTE: Usage of keep-alives is negotiated per direction. If a SIP
entity has indicated willingness to receive keep-alives from an entity has indicated willingness to receive keep-alives from an
adjacent SIP entity, sending of keep-alives towards the same SIP adjacent SIP entity, sending of keep-alives towards that adjacent SIP
entity needs to be separately negotiated. entity needs to be separately negotiated.
NOTE: Since there are SIP entities that already use a combination of NOTE: Since there are SIP entities that already use a combination of
Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP
entities are expected to be able to receive those, this specification entities are expected to be able to receive those, this specification
does not forbid the sending of double-CRLF keep-alive messages does not forbid the sending of double-CRLF keep-alive messages
towards an adjacent SIP entity even if usage of keep-alives with that towards an adjacent SIP entity even if usage of keep-alives with that
SIP entity has not been negotiated. However, the "keep" parameter is SIP entity has not been negotiated. However, the "keep" parameter is
still important in order for a SIP entity to indicate that it still important in order for a SIP entity to indicate that it
supports sending of double-CRLF keep-alive messages, so that the supports sending of double-CRLF keep-alive messages, so that the
skipping to change at page 6, line 13 skipping to change at page 6, line 13
can be negotiated when the registration is established, or later can be negotiated when the registration is established, or later
during the registration. Once negotiated, keep-alives are sent until during the registration. Once negotiated, keep-alives are sent until
the registration is terminated, or until a subsequent registration the registration is terminated, or until a subsequent registration
refresh request is sent or forwarded. When a subsequent registration refresh request is sent or forwarded. When a subsequent registration
refresh request is sent or forwarded, if a SIP entity is willing to refresh request is sent or forwarded, if a SIP entity is willing to
continue sending keep-alives associated with the registration, usage continue sending keep-alives associated with the registration, usage
of keep-alives MUST be re-negotiated. If usage is not successfully of keep-alives MUST be re-negotiated. If usage is not successfully
re-negotiated, the SIP entity MUST cease sending of keep-alives re-negotiated, the SIP entity MUST cease sending of keep-alives
associated with the registration. associated with the registration.
NOTE: Sending of keep-alives associated with a registration can only
be negotiated in the direction from the registering SIP entity
towards the registrar.
4.2.3. Keep-alives associated with dialog 4.2.3. Keep-alives associated with dialog
SIP entities use an initial request for a dialog, or a mid-dialog SIP entities use an initial request for a dialog, or a mid-dialog
target refresh request [RFC3261], in order to negotiate sending and target refresh request [RFC3261], in order to negotiate sending and
receiving of keep-alives associated with a dialog. Usage of keep- receiving of keep-alives associated with a dialog. Usage of keep-
alives can be negotiated when the dialog is established, or later alives can be negotiated when the dialog is established, or later
during the lifetime of the dialog. Once negotiated, keep-alives MUST during the lifetime of the dialog. Once negotiated, keep-alives MUST
be sent for the lifetime of the dialog, until the dialog is be sent for the lifetime of the dialog, until the dialog is
terminated. Once usage of keep-alives associated with a dialog has terminated. Once usage of keep-alives associated with a dialog has
been negotiated, it is not possible to re-negotiate the usage been negotiated, it is not possible to re-negotiate the usage
skipping to change at page 6, line 43 skipping to change at page 6, line 47
respectively double-CRLF, for keep-alives. respectively double-CRLF, for keep-alives.
When a SIP entity sends or forwards a request, if it wants to When a SIP entity sends or forwards a request, if it wants to
negotiate the sending of keep-alives associated with a registration, negotiate the sending of keep-alives associated with a registration,
or a dialog, it MUST insert a "keep" parameter in the topmost Via or a dialog, it MUST insert a "keep" parameter in the topmost Via
header field that it adds to the request, to indicate willingness to header field that it adds to the request, to indicate willingness to
send keep-alives. send keep-alives.
When the SIP entity receives the associated response, if the "keep" When the SIP entity receives the associated response, if the "keep"
parameter in the topmost Via header field of the response contains a parameter in the topmost Via header field of the response contains a
"keep" parameter value, it MUST start to send keep-alives towards the "keep" parameter value, it MUST start sending keep-alives towards the
same destination where it would send a subsequent request (e.g. same destination where it would send a subsequent request (e.g.
REGISTER requests and initial requests for dialog) associated with REGISTER requests and initial requests for dialog) associated with
the registration (if the keep-alive negotiation is for a the registration (if the keep-alive negotiation is for a
registration), or where it would send subsequent mid-dialog requests registration), or where it would send subsequent mid-dialog requests
(if the keep-alive negotiation is for a dialog). Subsequent mid- (if the keep-alive negotiation is for a dialog). Subsequent mid-
dialog requests are addressed based on the dialog route set. dialog requests are addressed based on the dialog route set.
Once a SIP entity has negotiated sending of keep-alives associated Once a SIP entity has negotiated sending of keep-alives associated
with a dialog towards an adjacent SIP entity, it MUST NOT insert a with a dialog towards an adjacent SIP entity, it MUST NOT insert a
"keep" parameter in any subsequent SIP requests, associated with the "keep" parameter in any subsequent SIP requests, associated with the
skipping to change at page 12, line 19 skipping to change at page 12, line 22
| |--- INVITE --------------->| | |--- INVITE --------------->|
| | Via: P1 | | | Via: P1 |
| | Via: Alice;keep | | | Via: Alice;keep |
| | Record-Route: P1 | | | Record-Route: P1 |
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | Via: P1 | | | Via: P1 |
| | Via: Alice;keep | | | Via: Alice;keep |
| | Record-Route: P1 | | | Record-Route: P1 |
|<-- 200 OK ---------------| | |<-- 200 OK ---------------| |
| Alice: UAC;keep=30 | | | Via: Alice;keep=30 | |
| Record-Route: P1 | | | Record-Route: P1 | |
| | | | | |
|--- ACK ----------------->| | |--- ACK ----------------->| |
| | | | | |
| |--- ACK ------------------>| | |--- ACK ------------------>|
| | | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | | |
|=== STUN request ========>| | |=== STUN request ========>| |
|<== STUN response ========| | |<== STUN response ========| |
skipping to change at page 13, line 20 skipping to change at page 13, line 28
insert itself in the dialog route set), and she once again indicates insert itself in the dialog route set), and she once again indicates
willingness to send keep-alives by inserting a "keep" parameter in willingness to send keep-alives by inserting a "keep" parameter in
her Via header field of the request. Bob supports the keep-alive her Via header field of the request. Bob supports the keep-alive
mechanism, and is willing to receive keep-alives associated with the mechanism, and is willing to receive keep-alives associated with the
dialog from Alice, so he creates a response and adds a "keep" dialog from Alice, so he creates a response and adds a "keep"
parameter value, which indicates a recommended keep-alive frequency parameter value, which indicates a recommended keep-alive frequency
of 30 seconds, to Alice's Via header field, before he forwards the of 30 seconds, to Alice's Via header field, before he forwards the
response towards Alice. response towards Alice.
When Alice receives the response, she determines from her Via header When Alice receives the response, she determines from her Via header
field that P1 is willing to receive keep-alives associated with the field that Bob is willing to receive keep-alives associated with the
dialog. For the lifetime of the dialog, Alice then sends periodic dialog. For the lifetime of the dialog, Alice then sends periodic
keep-alives (in this example using the STUN keep-alive technique) keep-alives (in this example using the STUN keep-alive technique)
towards Bob, using the recommended keep-alive frequency indicated by towards Bob, using the recommended keep-alive frequency indicated by
the "keep" parameter value. the "keep" parameter value.
Alice P1 Bob Alice P1 Bob
| | | | | |
|--- INVITE -------------->| | |--- INVITE -------------->| |
| Via: Alice;keep | | | Via: Alice;keep | |
| |--- INVITE --------------->| | |--- INVITE --------------->|
skipping to change at page 15, line 29 skipping to change at page 15, line 29
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- --------- ---------------------- --------------------- ---------- ---------
Via keep No [RFCXXXX] Via keep No [RFCXXXX]
10. Security Considerations 10. Security Considerations
SIP entities that send or receive keep-alives are often required to SIP entities that send or receive keep-alives are often required to
use a connection reuse mechanism, in order to ensure that requests use a connection reuse mechanism, in order to ensure that requests
sent in the reverse direction, towards the sender of the keep-alives, sent in the reverse direction, towards the sender of the keep-alives,
traverse NATs etc. This specification does not specify a connection traverse NATs etc. This specification does not specify a connection
reuse mechanism, and it does it address security issues related to reuse mechanism, and it does not address security issues related to
connection reuse. SIP entities that wish to reuse connections need connection reuse. SIP entities that wish to reuse connections need
to use a dedicated connection reuse mechanism, in conjunction with to use a dedicated connection reuse mechanism, in conjunction with
the keep-alive negotiation mechanism. the keep-alive negotiation mechanism.
Unless SIP messages are integrity protected hop-by-hop (e.g. using Unless SIP messages are integrity protected hop-by-hop (e.g. using
TLS or DTLS), a man-in-the-middle can modify Via header fields used TLS or DTLS), a man-in-the-middle can modify Via header fields used
by two entities to negotiate sending of keep-alives, e.g. by removing by two entities to negotiate sending of keep-alives, e.g. by removing
the indications used to indicate willingness to send and receive the indications used to indicate willingness to send and receive
keep-alives, or by decreasing the timer value to a very low value, keep-alives, or by decreasing the timer value to a very low value,
which might trigger additional resource consumption due to the which might trigger additional resource consumption due to the
frequently sent keep-alives. frequently sent keep-alives.
The behavior defined in Sections 4.3 and 4.4 require a SIP entity The behavior defined in Sections 4.3 and 4.4 require a SIP entity
using the mechanism defined in this specification to place a value in using the mechanism defined in this specification to place a value in
the "keep" parameter in the topmost Via header field value of a the "keep" parameter in the topmost Via header field value of a
response the SIP entity sends. They do not instruct the enity to response the SIP entity sends. They do not instruct the entity to
place a value in a "keep" parameter of any request it forwards. In place a value in a "keep" parameter of any request it forwards. In
particular, SIP proxies MUST NOT place a value into the keep particular, SIP proxies MUST NOT place a value into the keep
parameter of the topmost Via header field value of a request it parameter of the topmost Via header field value of a request it
receives before forwarding it. A SIP proxy implementing this receives before forwarding it. A SIP proxy implementing this
specification SHOULD remove any keep parameter values in any Via specification SHOULD remove any keep parameter values in any Via
header field values below the topmost one in responses it receives header field values below the topmost one in responses it receives
before forwarding them. before forwarding them.
When requests are forwarded across multiple hops, it is possible for When requests are forwarded across multiple hops, it is possible for
a malicious downstream SIP entity to tamper with the accrued values a malicious downstream SIP entity to tamper with the accrued values
skipping to change at page 16, line 47 skipping to change at page 16, line 47
and Milo Orsic for their comments on the initial draft. Thanks to and Milo Orsic for their comments on the initial draft. Thanks to
Juha Heinaenen, Jiri Kuthan, Dean Willis, John Elwell, Paul Kyzivat, Juha Heinaenen, Jiri Kuthan, Dean Willis, John Elwell, Paul Kyzivat,
Peter Musgrave, Dale Worley, Adam Roach and Robert Sparks for their Peter Musgrave, Dale Worley, Adam Roach and Robert Sparks for their
comments on the list. Thanks to Vijay Gurbani for providing text comments on the list. Thanks to Vijay Gurbani for providing text
about the relationship with the connect reuse specification. about the relationship with the connect reuse specification.
12. Change Log 12. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-sipcore-keep-10
o Editorial fixes based on IESG comments by Juergen Schoenwaelder
(Dec 21st)
o Editorial fixes based on IESG comments by Roni Even (Dec 28th)
Changes from draft-ietf-sipcore-keep-09 Changes from draft-ietf-sipcore-keep-09
o Changes based on AD review comments by Robert Sparks o Changes based on AD review comments by Robert Sparks
o Redundant paragraph removed from security considerations o Redundant paragraph removed from security considerations
Changes from draft-ietf-sipcore-keep-08 Changes from draft-ietf-sipcore-keep-08
o Changes based on AD review comments by Robert Sparks o Changes based on AD review comments by Robert Sparks
o Additional security considerations text provided by Robert Sparks o Additional security considerations text provided by Robert Sparks
o http://www.ietf.org/mail-archive/web/sipcore/current/msg03779.html o http://www.ietf.org/mail-archive/web/sipcore/current/msg03779.html
(Nov 23rd) (Nov 23rd)
o http://www.ietf.org/mail-archive/web/sipcore/current/msg03780.html o http://www.ietf.org/mail-archive/web/sipcore/current/msg03780.html
 End of changes. 13 change blocks. 
12 lines changed or deleted 21 lines changed or added

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