draft-ietf-sipcore-keep-08.txt   draft-ietf-sipcore-keep-09.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track October 19, 2010 Intended status: Standards Track December 9, 2010
Expires: April 22, 2011 Expires: June 12, 2011
Indication of support for keep-alive Indication of support for keep-alive
draft-ietf-sipcore-keep-08.txt draft-ietf-sipcore-keep-09.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 April 22, 2011. This Internet-Draft will expire on June 12, 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 2, line 28 skipping to change at page 2, line 28
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. Keep-alives associated with registration . . . . . . . 5 4.2.2. Keep-alives associated with registration . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 UA-proxy . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. Keep-alive negotiation associated with dialog: UA-proxy . 10 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 . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive
mechanisms. Even though the keep-alive mechanisms are separated from mechanisms. Even though the keep-alive mechanisms are separated from
the rest of the SIP Outbound mechanism, SIP Outbound does not define the rest of the SIP Outbound mechanism, SIP Outbound does not define
a mechanism to explicitly negotiate usage of the keep-alive a mechanism to explicitly negotiate usage of the keep-alive
mechanisms. In some cases usage of keep-alives can be implicitly mechanisms. In some cases usage of keep-alives can be implicitly
negotiated as part of the SIP Outbound negotiation. negotiated as part of the SIP Outbound negotiation.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
3. Definitions 3. Definitions
Edge proxy: As defined in [RFC5626], a SIP proxy that is located Edge proxy: As defined in [RFC5626], a SIP proxy that is located
topologically between the registering User Agent (UA) and the topologically between the registering User Agent (UA) and the
Authoritative Proxy. Authoritative Proxy.
NOTE: In some deployments the edge proxy might physically be located NOTE: In some deployments the edge proxy might physically be located
in the same entity as the Authoritative Proxy. in the same SIP entity as the Authoritative Proxy.
Keep-alives: The keep-alive messages defined in SIP Outbound Keep-alives: The keep-alive messages defined in SIP Outbound
[RFC5626]. [RFC5626].
"keep" parameter: A SIP Via header field parameter that a SIP entity "keep" parameter: A SIP Via header field parameter that a SIP entity
can insert in its Via header field of a request to explicitly can insert in the topmost Via header field that it adds to the
indicate willingness to send keep-alives towards its adjacent request, to explicitly indicate willingness to send keep-alives
downstream SIP entity. A SIP entity can also insert the header field towards its adjacent downstream SIP entity. A SIP entity can add a
in a response to explicitly indicate willingness to receive keep- parameter value to the "keep" parameter in a response to explicitly
alives from its adjacent upstream SIP entity. indicate willingness to receive keep-alives from its adjacent
upstream SIP entity.
SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261]. SIP entity: SIP User Agent (UA), or proxy, as defined in [RFC3261].
Adjacent downstream SIP entity: The adjacent SIP entity in the Adjacent downstream SIP entity: The adjacent SIP entity in the
direction towards which a SIP request is sent. direction towards which a SIP request is sent.
Adjacent upstream SIP entity: The adjacent SIP entity in the Adjacent upstream SIP entity: The adjacent SIP entity in the
direction from which a SIP request is received. direction from which a SIP request is received.
4. User Agent and Proxy behavior 4. User Agent and Proxy behavior
skipping to change at page 6, line 37 skipping to change at page 6, line 37
As defined in [RFC5626], a SIP entity that supports sending of keep- As defined in [RFC5626], a SIP entity that supports sending of keep-
alives must act as a Session Traversal Utilities for NAT (STUN) alives must act as a Session Traversal Utilities for NAT (STUN)
client [RFC5389]. The SIP entity must support those aspects of STUN client [RFC5389]. The SIP entity must support those aspects of STUN
that are required in order to apply the STUN keep-alive mechanism that are required in order to apply the STUN keep-alive mechanism
defined in [RFC5626], and it must support the CRLF keep-alive defined in [RFC5626], and it must support the CRLF keep-alive
mechanism defined in [RFC5626]. [RFC5626] defines when to use STUN, mechanism defined in [RFC5626]. [RFC5626] defines when to use STUN,
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 its Via header or a dialog, it MUST insert a "keep" parameter in the topmost Via
field of the request to indicate willingness to send keep-alives. header field that it adds to the request, to indicate willingness to
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 its Via header field of the response contains a "keep" parameter in the topmost Via header field of the response contains a
parameter value, it MUST start to send keep-alives towards the same "keep" parameter value, it MUST start to send keep-alives towards the
destination where it would send a subsequent request (e.g. REGISTER same destination where it would send a subsequent request (e.g.
requests and initial requests for dialog) associated with the REGISTER requests and initial requests for dialog) associated with
registration (if the keep-alive negotiation is for a registration), the registration (if the keep-alive negotiation is for a
or where it would send subsequent mid-dialog requests (if the keep- registration), or where it would send subsequent mid-dialog requests
alive negotiation is for a dialog). Subsequent mid-dialog requests (if the keep-alive negotiation is for a dialog). Subsequent mid-
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
dialog, towards that adjacent SIP entity. Such "keep" parameter MUST dialog, towards that adjacent SIP entity. Such "keep" parameter MUST
be ignored, if received. be ignored, if received.
Since an ACK request does not have an associated response, it can not Since an ACK request does not have an associated response, it can not
be used to negotiate usage of keep-alives. Therefore, a SIP entity be used to negotiate usage of keep-alives. Therefore, a SIP entity
MUST NOT insert a "keep" parameter in its Via header field of an ACK MUST NOT insert a "keep" parameter in the topmost Via header field of
request. Such "keep" parameter MUST be ignored, if received. an ACK request. Such "keep" parameter MUST be ignored, if received.
A SIP entity MUST NOT indicates willingness to send keep-alives A SIP entity MUST NOT indicates willingness to send keep-alives
associated with a dialog, unless it has also inserted itself in the associated with a dialog, unless it has also inserted itself in the
dialog route set [RFC3261]. dialog route set [RFC3261].
NOTE: When a SIP entity sends an initial request for a dialog, if the NOTE: When a SIP entity sends an initial request for a dialog, if the
adjacent downstream SIP entity does not insert itself in the dialog adjacent downstream SIP entity does not insert itself in the dialog
route set using a Record-Route header field [RFC3261], the adjacent route set using a Record-Route header field [RFC3261], the adjacent
downstream SIP entity will change once the dialog route set has been downstream SIP entity will change once the dialog route set has been
established. If a SIP entity inserts a "keep" parameter in its Via established. If a SIP entity inserts a "keep" parameter in the
header field of an initial request for a dialog, and the "keep" topmost Via header field of an initial request for a dialog, and the
parameter in the associated response does not contain a parameter "keep" parameter in the associated response does not contain a
value, the SIP entity might choose to insert a "keep" parameter in parameter value, the SIP entity might choose to insert a "keep"
its Via header field of a subsequent SIP request associated with the parameter in the topmost Via header field of a subsequent SIP request
dialog, in case the new adjacent SIP downstream entity (based on the associated with the dialog, in case the new adjacent downstream SIP
dialog route set) is willing to receive keep-alives (in which case it entity (based on the dialog route set) is willing to receive keep-
will add a parameter value to the "keep" parameter). alives (in which case it will add a parameter value to the "keep"
parameter).
If an INVITE request is used to indicate willingness to send keep- If an INVITE request is used to indicate willingness to send keep-
alives, as long as at least one response (provisional or final) to alives, as long as at least one response (provisional or final) to
the INVITE request contains a "keep" parameter with a parameter the INVITE request contains a "keep" parameter with a parameter
value, it is seen as an indication that the adjacent downstream SIP value, it is seen as an indication that the adjacent downstream SIP
entity is willing to receive keep-alives associated with the dialog entity is willing to receive keep-alives associated with the dialog
on which the response is received. on which the response is received.
4.4. Behavior of a SIP entity willing to receive keep-alives 4.4. Behavior of a SIP entity willing to receive keep-alives
skipping to change at page 7, line 50 skipping to change at page 8, line 4
keep-alives must act as a STUN server [RFC5389]. The SIP entity must keep-alives must act as a STUN server [RFC5389]. The SIP entity must
support those aspects of STUN that are required in order to apply the support those aspects of STUN that are required in order to apply the
STUN keep-alive mechanism defined in [RFC5626], and it must support STUN keep-alive mechanism defined in [RFC5626], and it must support
the CRLF keep-alive mechanism defined in [RFC5626]. the CRLF keep-alive mechanism defined in [RFC5626].
When a SIP entity sends or forwards a response, and the adjacent When a SIP entity sends or forwards a response, and the adjacent
upstream SIP entity indicated willingness to send keep-alives, if the upstream SIP entity indicated willingness to send keep-alives, if the
SIP entity is willing to receive keep-alives associated with the SIP entity is willing to receive keep-alives associated with the
registration, or the dialog, from the adjacent upstream SIP entity it registration, or the dialog, from the adjacent upstream SIP entity it
MUST add a parameter value to the "keep" parameter, before sending or MUST add a parameter value to the "keep" parameter, before sending or
forwarding the response. The parameter can contain a recommended forwarding the response. The parameter value, if present and with a
keep-alive frequency, given in seconds, or a zero value. value other than zero, represents a recommended keep-alive frequency,
given in seconds.
When a SIP entity indicates willingness to receive keep-alives in a There might be multiple responses to an INVITE request. When a SIP
response to an INVITE request, it MUST insert a "keep" parameter in entity indicates willingness to receive keep-alives in a response to
at least one reliable response to the request. The SIP entity MAY an INVITE request, it MUST add a parameter value to the "keep"
insert an identical "keep" parameter value in other responses to the parameter in at least one reliable response to the request. The SIP
same request. The SIP entity MUST NOT insert "keep" parameters with entity MAY add identical parameter values to the "keep" parameters in
differing values in responses to a single INVITE request. The SIP other responses to the same request. The SIP entity MUST NOT add
entity SHOULD indicate the willingness to receive keep-alives as soon different parameter value to the "keep" parameters in responses to
as possible. the same request. The SIP entity SHOULD indicate the willingness to
receive keep-alives as soon as possible.
A SIP entity MUST NOT indicates willingness to receive keep-alives A SIP entity MUST NOT indicates willingness to receive keep-alives
associated with a dialog, unless it has also inserted itself in the associated with a dialog, unless it has also inserted itself in the
dialog route set [RFC3261]. dialog route set [RFC3261].
5. Keep-alive frequency 5. Keep-alive frequency
If a SIP entity receives a SIP response, where its Via header field If a SIP entity receives a SIP response, where the topmost Via header
contains a "keep" parameter with a non-zero value that indicates a field contains a "keep" parameter with a non-zero value that
recommended keep-alive frequency, given in seconds, it MUST use the indicates a recommended keep-alive frequency, given in seconds, it
procedures defined for the Flow-Timer header field [RFC5626]. MUST use the procedures defined for the Flow-Timer header field
According to the procedures, the SIP entity must send keep-alives at [RFC5626]. According to the procedures, the SIP entity must send
least as often as the indicated recommended keep-alive frequency, and keep-alives at least as often as the indicated recommended keep-alive
if the SIP entity uses the recommended keep-alive frequency then it frequency, and if the SIP entity uses the recommended keep-alive
should send its keep-alives so that the interval between each keep- frequency then it should send its keep-alives so that the interval
alive is randomly distributed between 80% and 100% of the recommended between each keep-alive is randomly distributed between 80% and 100%
keep-alive frequency. of the recommended keep-alive frequency.
If the received "keep" parameter value is zero, the SIP entity can If the received "keep" parameter value is zero, the SIP entity can
send keep-alives at its discretion. [RFC5626] provides additional send keep-alives at its discretion. [RFC5626] provides additional
guidance on selecting the keep-alive frequency in case a recommended guidance on selecting the keep-alive frequency in case a recommended
keep-alive frequency is not provided. keep-alive frequency is not provided.
This specification does not specify actions to take if negotiated This specification does not specify actions to take if negotiated
keep-alives are not received. As defined in [RFC5626], the receiving keep-alives are not received. As defined in [RFC5626], the receiving
SIP entity may consider a connection to be dead in such situations. SIP entity may consider a connection to be dead in such situations.
If a SIP entity that uses the "keep" parameter to indicate If a SIP entity that adds a parameter value to the "keep" parameter,
willingness to receive keep-alives also inserts a Flow-Timer header in order to indicate willingness to receive keep-alives, also inserts
field (that can happen if the SIP entity is using both the Outbound a Flow-Timer header field (that can happen if the SIP entity is using
mechanism and the keep-alive mechanism) in the same SIP message, the both the Outbound mechanism and the keep-alive mechanism) in the same
header field value and the "keep" parameter value MUST be identical. SIP message, the header field value and the "keep" parameter value
MUST be identical.
SIP Outbound uses the Flow-Timer header field to indicate the server- SIP Outbound uses the Flow-Timer header field to indicate the server-
recommended keep-alive frequency. However, it will only be sent recommended keep-alive frequency. However, it will only be sent
between a UA and an edge proxy. Using the "keep" parameter, however, between a UA and an edge proxy. Using the "keep" parameter, however,
the sending and receiving of keep-alives might be negotiated between the sending and receiving of keep-alives might be negotiated between
multiple entities on the signalling path. In addition, since the multiple entities on the signalling path. In addition, since the
server-recommended keep-alive frequency might vary between different server-recommended keep-alive frequency might vary between different
SIP entities, a single Flow-Timer header field can not be used to SIP entities, a single Flow-Timer header field can not be used to
indicate all the different frequency values, without forcing entities indicate all the different frequency values.
to re-write the value of the Flow-Timer header field.
6. Connection reuse 6. Connection reuse
Keep-alives are often sent in order to keep NAT bindings open, so Keep-alives are often sent in order to keep NAT bindings open, so
that the NAT may be passed by SIP requests sent in the reverse that the NAT may be passed by SIP requests sent in the reverse
direction, reusing the same connection, or for non-connection- direction, reusing the same connection, or for non-connection-
oriented transport protocols, reusing the same path. This oriented transport protocols, reusing the same path. This
specification does not define such connection reuse mechanism. The specification does not define such connection reuse mechanism. The
keep-alive mechanism defined in this specification is only used to keep-alive mechanism defined in this specification is only used to
negotiate the sending and receiving of keep-alives. Entities that negotiate the sending and receiving of keep-alives. Entities that
want to reuse connections MUST use a another mechanism to ensure that want to reuse connections need to use another mechanism to ensure
security aspects associated with connection reuse are taken into that security aspects associated with connection reuse are taken into
consideration. consideration.
RFC 5923 [RFC5923] specifies a mechanism for using connection- RFC 5923 [RFC5923] specifies a mechanism for using connection-
oriented transports to send requests in the reverse direction, and an oriented transports to send requests in the reverse direction, and an
entity that wants to use connection-reuse as well as indicate support entity that wants to use connection-reuse as well as indicate support
of keep-alives on that connection will insert both the "alias" of keep-alives on that connection will insert both the "alias"
parameter defined in [RFC5923] as well as the "keep" parameter parameter defined in [RFC5923] as well as the "keep" parameter
defined in this specification. defined in this specification.
SIP Outbound specifies how registration flows are used to send SIP Outbound specifies how registration flows are used to send
requests in the reverse direction. requests in the reverse direction.
7. Examples 7. Examples
7.1. General 7.1. General
This section shows example flows where usage of keep-alives, This section shows example flows where usage of keep-alives,
associated with a registration and a dialog, is negotiated between associated with a registration and a dialog, is negotiated between
different SIP entities. different SIP entities.
NOTE: The examples do not show the actual syntactical encoding of the
request lines, response lines and the Via header fields, but rather a
pseudo code in order to identity the message type and to which SIP
entity a Via header field is associated.
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. Figure 1 shows an example where Alice sends an REGISTER request. She
She indicates willingness of sending keep-alive by inserting a "keep" 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
skipping to change at page 10, line 39 skipping to change at page 11, line 4
| *** Timeout *** | | *** Timeout *** |
| | | | | |
|=== STUN request ========>| | |=== STUN request ========>| |
|<== STUN response ========| | |<== STUN response ========| |
| | | | | |
| *** Timeout *** | | *** Timeout *** |
| | | | | |
|=== STUN request ========>| | |=== STUN request ========>| |
|<== STUN response ========| | |<== STUN response ========| |
| | | | | |
Figure 1: Example call flow Figure 1: Example call flow
7.3. Keep-alive negotiation associated with dialog: UA-proxy 7.3. Keep-alive negotiation associated with dialog: UA-proxy
The figure shows an example where Alice sends an initial INVITE Figure 2 shows an example where Alice sends an initial INVITE request
request for a dialog. She indicates willingness to send keep-alive for a dialog. She indicates willingness to send keep-alive by
by inserting a "keep" parameter in her Via header field of the inserting a "keep" parameter in her Via header field of the request.
request. The edge proxy (P1) adds itself to the dialog route set by The edge proxy (P1) adds itself to the dialog route set by adding
adding itself to a Record-Route header field, before it forwards the itself to a Record-Route header field, before it forwards the request
request towards Bob. 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
skipping to change at page 12, line 48 skipping to change at page 12, line 48
| | | | | |
| |--- BYE ------------------>| | |--- BYE ------------------>|
| | | | | |
| |<-- 200 OK ----------------| | |<-- 200 OK ----------------|
| | | | | |
Figure 2: Example call flow Figure 2: Example call flow
7.4. Keep-alive negotiation associated with dialog: UA-UA 7.4. Keep-alive negotiation associated with dialog: UA-UA
The figure shows an example where Alice sends an initial INVITE Figure 3 shows an example where Alice sends an initial INVITE request
request for a dialog. She indicates willingness to send keep-alive for a dialog. She indicates willingness to send keep-alive by
by inserting a "keep" parameter in her Via header field of the inserting a "keep" parameter in her Via header field of the request.
request. The edge proxy (P1) does not add itself to the dialog route The edge proxy (P1) does not add itself to the dialog route set, by
set, by adding itself to a Record-Route header field, before it adding itself to a Record-Route header field, before it forwards the
forwards the request towards Bob. . 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" dialog from Alice, so he creates a response and adds a "keep"
skipping to change at page 15, line 30 skipping to change at page 15, line 30
---------------------- --------------------- ---------- --------- ---------------------- --------------------- ---------- ---------
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 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 need
required to use a dedicated connection reuse mechanism, in to use a dedicated connection reuse mechanism, in conjunction with
conjunction with the keep-alive negotiation mechanism. the keep-alive negotiation mechanism.
Unless SIP messages are integrity protected, a man-in-the-middle can Unless SIP messages are integrity protected hop-by-hop (e.g. using
modify Via header fields used by two entities to negotiate sending of TLS or DTLS), a man-in-the-middle can modify Via header fields used
keep-alives, e.g. by removing the indications used to indicate by two entities to negotiate sending of keep-alives, e.g. by removing
willingness to send and receive keep-alives, or by decreasing the the indications used to indicate willingness to send and receive
timer value to a very low value, which might trigger additional keep-alives, or by decreasing the timer value to a very low value,
resource consumption due to the frequently sent keep-alives. which might trigger additional resource consumption due to the
frequently sent keep-alives.
Downstream SIP entities can modify Via header fields identifying The behavior defined in Sections 4.3 and 4.4 require a SIP entity
other SIP entities, and cause keep-alives to be sent (at high rates) using the mechanism defined in this specification to place a value in
to entities that do not support the keep-alive mechanism. SIP the "keep" parameter in the topmost Via header field value of a
entities can prevent this, when a SIP response is received, by response the SIP entity sends. They do not instruct the enity to
examining their own Via header field to determine that downstream place a value in a "keep" parameter of any request it forwards. In
entities have not added a "keep" parameter or set an existing "keep" particular, SIP proxies MUST NOT place a value into the keep
parameter to a value not supported by the implementation. parameter of the topmost Via header field value of a request it
receives before forwarding it. A SIP proxy implementing this
specification SHOULD remove any keep parameter values in any Via
header field values below the topmost one in responses it receives
before forwarding them.
When requests are forwarded across multiple hops, it is possible for
a malicious downstream SIP entity to tamper with the accrued values
in the Via header field. The malicious SIP entity could place a
value, or change an existing value in a "keep" parameter in any of
the Via header field values, not just the topmost value. A proxy
implementation that simply forwards responses by stripping the
topmost Via header field value and not inspecting the resulting new
topmost Via header field value risks being adversely affected by such
a malicious downstream SIP entity. In particular, such a proxy may
start receiving STUN requests if it blindly forwards a response with
a keep parameter with a value it did not create in the topmost Via
header field. To lower the chances of the malicious SIP entity's
actions having adverse affects on such proxies, when a SIP entity
sends STUN keep-alives to an adjacent downstream SIP entity and does
not receive a response to those STUN messages, it MUST stop sending
the keep-alive requests for the remaining duration of the dialog (if
the sending of keep-alives were negotiated for a dialog) or until the
sending of keep-alives is re-negotiated for the registration (if the
sending keep-alives were negotiated for a registration).
In order to prevent attacks, when a SIP entity sends STUN keep-alives
to an adjacent downstream SIP entity that is not willing to receive
keep-alives (or does not support STUN), but for which willingness to
receive keep-alives has been inidicated by some other downstream SIP
entity, if the sending SIP entity does not receive a response to any
of the STUN keep-alive requests, it MUST stop sending the keep-alive
requests for the remaining duration of the dialog (if the sending of
keep-alives were negotiated for a dialog) or until the sending of
keep-alives is re-negotiated for the registration (if the sending
keep-alives were negotiated for a registration). Further actions
taken by the sending SIP entity is outside the scope of this
specification.
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, Dale Worley and Adam Roach for their comments on the Peter Musgrave, Dale Worley, Adam Roach and Robert Sparks for their
list. Thanks to Vijay Gurbani for providing text about the comments on the list. Thanks to Vijay Gurbani for providing text
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-08
o Changes based on AD review comments by Robert Sparks
o Additional security considerations text provided by Robert Sparks
o http://www.ietf.org/mail-archive/web/sipcore/current/msg03779.html
(Nov 23rd)
o http://www.ietf.org/mail-archive/web/sipcore/current/msg03780.html
(Nov 23rd)
Changes from draft-ietf-sipcore-keep-07 Changes from draft-ietf-sipcore-keep-07
o Last paragraph of section 4.2.2 removed o Last paragraph of section 4.2.2 removed
o Reference correction o Reference correction
Changes from draft-ietf-sipcore-keep-06 Changes from draft-ietf-sipcore-keep-06
o New text added to the security considerations 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
 End of changes. 27 change blocks. 
100 lines changed or deleted 155 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/