draft-ietf-sipcore-keep-06.txt   draft-ietf-sipcore-keep-07.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track September 6, 2010 Intended status: Standards Track October 13, 2010
Expires: March 10, 2011 Expires: April 16, 2011
Indication of support for keep-alive Indication of support for keep-alive
draft-ietf-sipcore-keep-06.txt draft-ietf-sipcore-keep-07.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 March 10, 2011. This Internet-Draft will expire on April 16, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 5, line 17 skipping to change at page 5, line 17
responses are used by SIP entities to indicate willingness to receive responses are used by SIP entities to indicate willingness to receive
keep-alives. SIP entities that indicate willingness to receive keep- keep-alives. SIP entities that indicate willingness to receive keep-
alives can provide a recommended keep-alive frequency. alives can provide a recommended keep-alive frequency.
The procedures to negotiate usage of keep-alives are identical for The procedures to negotiate usage of keep-alives are identical for
SIP UAs and proxies. SIP UAs and proxies.
In general, it can be useful for SIP entities to indicate willingness In general, it can be useful for SIP entities to indicate willingness
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, it can be might have knowledge about the necessity. Similarly, if the adjacent
useful for SIP entities to indicate willingness to receive keep- upstream SIP entity has indicated willingness to send keep-alives, it
alives, even if they are not aware of any necessity for the adjacent can be useful for SIP entities to indicate willingness to receive
upstream SIP entity to send them. keep-alives, even if they are not aware of any necessity for the
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 the same 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
skipping to change at page 10, line 7 skipping to change at page 10, line 7
different SIP entities. different SIP entities.
7.2. Keep-alive negotiation associated with registration: UA-proxy 7.2. Keep-alive negotiation associated with registration: UA-proxy
The figure shows an example where Alice sends an REGISTER request. The figure shows an example where Alice sends an REGISTER request.
She indicates willingness of sending keep-alive by inserting a "keep" She indicates willingness of sending keep-alive by inserting a "keep"
parameter in her Via header field of the request. The edge proxy parameter in her Via header field of the request. The edge proxy
(P1) forwards the request towards the registrar. (P1) forwards the request towards the registrar.
P1 is willing to receive keep-alives from Alice for the duration of P1 is willing to receive keep-alives from Alice for the duration of
the registration, so When P1 receives the associated response it adds the registration, so when P1 receives the associated response it adds
a keep parameter value, which indicates a recommended keep-alive a "keep" parameter value, which indicates a recommended keep-alive
frequency of 30 seconds, to Alice's Via header field, before it frequency of 30 seconds, to Alice's Via header field, before it
forwards the response towards Alice. forwards the 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 P1 is willing to receive keep-alives associated with the
registration. Until the registration expires, or Alice sends a registration. Until the registration expires, or Alice sends a
registration refresh request, Alice then sends periodic keep-alives registration refresh request, Alice then sends periodic keep-alives
(in this example using the STUN keep-alive technique) towards P1, (in this example using the STUN keep-alive technique) towards P1,
using the recommended keep-alive frequency indicated by the keep using the recommended keep-alive frequency indicated by the "keep"
parameter value. parameter value.
Alice P1 REGISTRAR Alice P1 REGISTRAR
| | | | | |
|--- REGISTER------------->| | |--- REGISTER------------->| |
| Via: Alice;keep | | | Via: Alice;keep | |
| |--- REGISTER-------------->| | |--- REGISTER-------------->|
| | Via: P1 | | | Via: P1 |
| | Via: Alice;keep | | | Via: Alice;keep |
| | | | | |
skipping to change at page 11, line 16 skipping to change at page 11, line 16
The figure shows an example where Alice sends an initial INVITE The figure shows an example where Alice sends an initial INVITE
request for a dialog. She indicates willingness to send keep-alive request for a dialog. She indicates willingness to send keep-alive
by inserting a "keep" parameter in her Via header field of the by inserting a "keep" parameter in her Via header field of the
request. The edge proxy (P1) adds itself to the dialog route set by request. The edge proxy (P1) adds itself to the dialog route set by
adding itself to a Record-Route header field, before it forwards the adding itself to a Record-Route header field, before it forwards the
request towards Bob. request towards Bob.
P1 is willing to receive keep-alives from Alice for the duration of P1 is willing to receive keep-alives from Alice for the duration of
the dialog, so When P1 receives the associated response it adds a the dialog, so When P1 receives the associated response it adds a
keep parameter value, which indicates a recommended keep-alive "keep" parameter value, which indicates a recommended keep-alive
frequency of 30 seconds, to Alice's Via header field, before it frequency of 30 seconds, to Alice's Via header field, before it
forwards the response towards Alice. forwards the 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 P1 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 P1, using the recommended keep-alive frequency indicated by towards P1, 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 --------------->|
| | Via: P1 | | | Via: P1 |
| | Via: Alice;keep | | | Via: Alice;keep |
| | Record-Route: P1 | | | Record-Route: P1 |
| | | | | |
skipping to change at page 13, line 14 skipping to change at page 13, line 14
forwards the request towards Bob. . forwards the request towards Bob. .
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 not willing to receive keep-alives associated with field that P1 is not willing to receive keep-alives associated with
the dialog from her. When the dialog route set has been established, the dialog from her. When the dialog route set has been established,
Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not
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 parameter dialog from Alice, so he creates a response and adds a "keep"
value, which indicates a recommended keep-alive frequency of 30 parameter value, which indicates a recommended keep-alive frequency
seconds, to Alice's Via header field, before he forwards the response of 30 seconds, to Alice's Via header field, before he forwards the
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 P1 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 --------------->|
| | Via: P1 | | | Via: P1 |
| | Via: Alice:keep | | | Via: Alice:keep |
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
skipping to change at page 15, line 40 skipping to change at page 15, line 40
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 it address security issues related to
connection reuse. SIP entities that wish to reuse connections are connection reuse. SIP entities that wish to reuse connections are
required to use a dedicated connection reuse mechanism, in required to use a dedicated connection reuse mechanism, in
conjunction with the keep-alive negotiation mechanism. conjunction with the keep-alive negotiation mechanism.
Unless SIP messages are integrity protected, a man-in-the-middle can Unless SIP messages are integrity protected, a man-in-the-middle can
modify Via header fields used by two entities to negotiate sending of modify Via header fields used by two entities to negotiate sending of
keep-alives, e.g. by removing the indications used to indicate keep-alives, e.g. by removing the indications used to indicate
willingness to send and receive keep-alives, or by decreasing the willingness to send and receive keep-alives, or by decreasing the
timer value to a verly low value, which might trigger additional timer value to a very low value, which might trigger additional
resource consumption due to the frequently sent keep-alives. resource consumption due to the frequently sent keep-alives.
Downstream SIP entities can modify Via header fields identifying
other SIP entities, and cause keep-alives to be sent (at high rates)
to entities that do not support the keep-alive mechanism. SIP
entities can prevent this, when a SIP response is received, by
examining their own Via header field to determine that downstream
entities have not added a "keep" parameter or set an existing "keep"
parameter to a value not supported by the implementation.
Apart from the issues described above, this specification does not Apart from the issues described above, this specification does not
introduce security considerations in addition to those specified for introduce security considerations in addition to those specified for
keep-alives in [RFC5626]. keep-alives in [RFC5626].
11. Acknowledgements 11. Acknowledgements
Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer
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 and Dale Worley for their comments on the list. Peter Musgrave, Dale Worley and Adam Roach for their comments on the
Thanks to Vijay Gurbani for providing text about the relationship list. Thanks to Vijay Gurbani for providing text about the
with the connect-reuse specification. 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-06
o New text added to the security considerations
Changes from draft-ietf-sipcore-keep-05 Changes from draft-ietf-sipcore-keep-05
o New section about connection reuse added o New section about connection reuse added
o Clarify that the specification does not define a mechanism for o Clarify that the specification does not define a mechanism for
connection reuse connection reuse
o New text added to the security considerations o New text added to the security considerations
o CRLF changed to double-CRLF in some places o CRLF changed to double-CRLF in some places
13. References 13. References
13.1. Normative References 13.1. Normative References
 End of changes. 14 change blocks. 
22 lines changed or deleted 34 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/