draft-ietf-sipcore-keep-11.txt   draft-ietf-sipcore-keep-12.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track January 10, 2011 Intended status: Standards Track January 20, 2011
Expires: July 14, 2011 Expires: July 24, 2011
Indication of support for keep-alive Indication of support for keep-alive
draft-ietf-sipcore-keep-11.txt draft-ietf-sipcore-keep-12.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 July 14, 2011. This Internet-Draft will expire on July 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 . . . 13 7.4. Keep-alive negotiation associated with dialog: UA-UA . . . 13
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . . 17
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
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.
However, there are SIP Outbound use-cases where usage of keep-alives However, there are SIP Outbound use-cases where usage of keep-alives
is not implicitly negotiated as part of the SIP Outbound negotiation. is not implicitly negotiated as part of the SIP Outbound negotiation.
In addition, there are cases where SIP Outbound is not supported, or In addition, there are cases where SIP Outbound is not supported, or
where it cannot be applied, but where there is still a need to be where it cannot be applied, but where there is still a need to be
able to negotiate usage of keep-alives. Last, [RFC5626] only allows able to negotiate usage of keep-alives. Last, SIP Outbound only
keep-alives to be negotiated between a UA and an edge proxy, and not allows keep-alives to be negotiated between a UA and an edge proxy,
between other SIP entities. and not between other SIP entities.
This specification defines a new Session Initiation Protocol (SIP) This specification defines a new Session Initiation Protocol (SIP)
[RFC3261] Via header field parameter, "keep", which allows adjacent [RFC3261] Via header field parameter, "keep", which allows adjacent
SIP entities to explicitly negotiate usage of the NAT keep-alive SIP entities to explicitly negotiate usage of the NAT keep-alive
mechanisms defined in SIP Outbound. The "keep" parameter allows SIP mechanisms defined in SIP Outbound. The "keep" parameter allows SIP
entities to indicate willingness to send keep-alives, to indicate entities to indicate willingness to send keep-alives, to indicate
willingness to receive keep-alives, and for SIP entities willing to willingness to receive keep-alives, and for SIP entities willing to
receive keep-alives to provide a recommended keep-alive frequency. receive keep-alives to provide a recommended keep-alive frequency.
The following sections describe use-cases where a mechanism to The following sections describe use-cases where a mechanism to
skipping to change at page 3, line 44 skipping to change at page 3, line 44
In some cases a User Agent Client (UAC) does not register itself In some cases a User Agent Client (UAC) does not register itself
before it establishes a dialog, but in order to maintain NAT bindings before it establishes a dialog, but in order to maintain NAT bindings
open during the lifetime of the dialog it still needs to be able to open during the lifetime of the dialog it still needs to be able to
negotiate sending of keep-alives towards its adjacent downstream SIP negotiate sending of keep-alives towards its adjacent downstream SIP
entity. A typical example is an emergency call, where a registration entity. A typical example is an emergency call, where a registration
is not always required in order to make the call. is not always required in order to make the call.
1.2. Use-case: SIP Outbound not supported 1.2. Use-case: SIP Outbound not supported
In some cases all SIP entities that need to be able to negotiate the In some cases some SIP entities that need to be able to negotiate the
usage of keep-alives might not support SIP Outbound. However, they use of keep-alives might not support SIP Outbound. However, they
might still support the keep-alive mechanisms defined in SIP might still support the keep-alive mechanisms defined in SIP
Outbound, and need to be able to negotiate usage of them. Outbound, and need to be able to negotiate usage of them.
1.3. Use-case: SIP dialog initiated Outbound flows 1.3. Use-case: SIP dialog initiated Outbound flows
SIP Outbound allows the establishment of flows using the initial SIP Outbound allows the establishment of flows using the initial
request for a dialog. As specified in [RFC5626], usage of keep- request for a dialog. As specified in RFC 5626 [RFC5626], usage of
alives is not implicitly negotiated for such flows. keep-alives is not implicitly negotiated for such flows.
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 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 RFC 5626, 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 SIP 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 RFC 5626.
[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 the topmost Via header field that it adds to the can insert in the topmost Via header field that it adds to the
request, to explicitly indicate willingness to send keep-alives request, to explicitly indicate willingness to send keep-alives
towards its adjacent downstream SIP entity. A SIP entity can add a towards its adjacent downstream SIP entity. A SIP entity can add a
parameter value to the "keep" parameter in a response to explicitly parameter value to the "keep" parameter in a response to explicitly
indicate willingness to receive keep-alives from its adjacent indicate willingness to receive keep-alives from its adjacent
upstream SIP entity. 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 RFC 3261.
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
4.1. General 4.1. General
skipping to change at page 6, line 31 skipping to change at page 6, line 31
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
associated with the dialog. associated with the dialog.
4.3. Behavior of a SIP entity willing to send keep-alives 4.3. Behavior of a SIP entity willing to send keep-alives
As defined in [RFC5626], a SIP entity that supports sending of keep- As defined in RFC 5626, 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 RFC 5626, and it must support the CRLF keep-alive
mechanism defined in [RFC5626]. [RFC5626] defines when to use STUN, mechanism defined in RFC 5626. RFC 5626 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 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
skipping to change at page 7, line 45 skipping to change at page 7, line 45
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
As defined in [RFC5626], a SIP entity that supports receiving of As defined in RFC 5626, a SIP entity that supports receiving of keep-
keep-alives must act as a STUN server [RFC5389]. The SIP entity must 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 RFC 5626, and it must support
the CRLF keep-alive mechanism defined in [RFC5626]. the CRLF keep-alive mechanism defined in RFC 5626.
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 value, if present and with a forwarding the response. The parameter value, if present and with a
value other than zero, represents a recommended keep-alive frequency, value other than zero, represents a recommended keep-alive frequency,
given in seconds. given in seconds.
skipping to change at page 8, line 40 skipping to change at page 8, line 40
indicates a recommended keep-alive frequency, given in seconds, it indicates a recommended keep-alive frequency, given in seconds, it
MUST use the procedures defined for the Flow-Timer header field MUST use the procedures defined for the Flow-Timer header field
[RFC5626]. According to the procedures, the SIP entity must send [RFC5626]. According to the procedures, the SIP entity must send
keep-alives at least as often as the indicated recommended keep-alive keep-alives at least as often as the indicated recommended keep-alive
frequency, and if the SIP entity uses the recommended keep-alive frequency, and if the SIP entity uses the recommended keep-alive
frequency then it should send its keep-alives so that the interval frequency then it should send its keep-alives so that the interval
between each keep-alive is randomly distributed between 80% and 100% between each keep-alive is randomly distributed between 80% and 100%
of the recommended 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. RFC 5626 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 RFC 5626, 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 adds a parameter value to the "keep" parameter, If a SIP entity that adds a parameter value to the "keep" parameter,
in order to indicate willingness to receive keep-alives, also inserts in order to indicate willingness to receive keep-alives, also inserts
a Flow-Timer header field (that can happen if the SIP entity is using a Flow-Timer header field (that can happen if the SIP entity is using
both the Outbound mechanism and the keep-alive mechanism) in the same both the Outbound mechanism and the keep-alive mechanism) in the same
SIP message, the header field value and the "keep" parameter value SIP message, the header field value and the "keep" parameter value
MUST be identical. 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-
skipping to change at page 9, line 34 skipping to change at page 9, line 34
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 need to use another mechanism to ensure want to reuse connections need to use another mechanism to ensure
that 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 RFC 5923 as well as the "keep" parameter defined
defined in this specification. 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
skipping to change at page 14, line 48 skipping to change at page 15, line 4
| | | |
| | | |
|--- BYE --------------------------------------------->| |--- BYE --------------------------------------------->|
| | | |
|<-- 200 OK -------------------------------------------| |<-- 200 OK -------------------------------------------|
| | | |
Figure 3: Example call flow Figure 3: Example call flow
8. Grammar 8. Grammar
8.1. General
This specification defines a new Via header field parameter, "keep". This section describes the syntax extensions to the ABNF syntax
defined in RFC 3261, by defining a new Via header field parameter,
"keep". The ABNF defined in this specification is conformant to RFC
5234 [RFC5234].
The ABNF [RFC5234] is: 8.2. ABNF
via-params =/ keep via-params =/ keep
keep = "keep" [ EQUAL 1*(DIGIT) ] keep = "keep" [ EQUAL 1*(DIGIT) ]
9. IANA Considerations 9. IANA Considerations
9.1. keep 9.1. keep
This specification defines a new Via header field parameter called This specification defines a new Via header field parameter called
skipping to change at page 15, line 34 skipping to change at page 15, line 42
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 not 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 Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer
by two entities to negotiate sending of keep-alives, e.g. by removing Security (DTLS) [RFC4347], a man-in-the-middle can modify Via header
the indications used to indicate willingness to send and receive fields used by two entities to negotiate sending of keep-alives, e.g.
keep-alives, or by decreasing the timer value to a very low value,
which might trigger additional resource consumption due to the by removing the indications used to indicate willingness to send and
receive keep-alives, or by decreasing the timer value to a very low
value, 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 entity 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
skipping to change at page 16, line 21 skipping to change at page 16, line 33
a malicious downstream SIP entity to tamper with the accrued values a malicious downstream SIP entity to tamper with the accrued values
in the Via header field. The malicious SIP entity could place a 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 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 the Via header field values, not just the topmost value. A proxy
implementation that simply forwards responses by stripping the implementation that simply forwards responses by stripping the
topmost Via header field value and not inspecting the resulting new topmost Via header field value and not inspecting the resulting new
topmost Via header field value risks being adversely affected by such topmost Via header field value risks being adversely affected by such
a malicious downstream SIP entity. In particular, such a proxy may a malicious downstream SIP entity. In particular, such a proxy may
start receiving STUN requests if it blindly forwards a response with 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 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 header field.
actions having adverse affects on such proxies, when a SIP entity
sends STUN keep-alives to an adjacent downstream SIP entity and does To lower the chances of the malicious SIP entity's actions having
not receive a response to those STUN messages, it MUST stop sending adverse affects on such proxies, when a SIP entity sends STUN keep-
the keep-alive requests for the remaining duration of the dialog (if alives to an adjacent downstream SIP entity and does not receive a
the sending of keep-alives were negotiated for a dialog) or until the response to those STUN messages, it MUST, based on the procedure in
sending of keep-alives is re-negotiated for the registration (if the section 4.4.2 of RFC 5626, after 7 retransmissions, or when an error
sending keep-alives were negotiated for a registration). response is received for the STUN request, stop sending keep-alives
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).
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, 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-11
o Editorial fixes based on last call comments by Peter Saint-Andre
(Jan 11th)
o - TLS and DTLS references added
o - Clarification that the sending of keep-alives stops after 7
retranmissions
o Editorial fixes based on last call comments by Alexey Melnikov
(Jan 12th)
o - Additional text added to Grammar section
o Editorial fixes based on last call comments by Adrian Farrel (Jan
16th)
o Editorial fixes based on last call comments by Sean Turner (Jan
20th)
o Reference clean-ups
Changes from draft-ietf-sipcore-keep-10 Changes from draft-ietf-sipcore-keep-10
o Editorial fixes based on IESG comments by Juergen Schoenwaelder o Editorial fixes based on last call comments by Juergen
(Dec 21st) Schoenwaelder (Dec 21st)
o Editorial fixes based on IESG comments by Roni Even (Dec 28th) o Editorial fixes based on last call 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)
skipping to change at page 18, line 17 skipping to change at page 18, line 47
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
13.2. Informative References 13.2. Informative References
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority [RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session (IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968, Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004. December 2004.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)", RFC 5923, the Session Initiation Protocol (SIP)", RFC 5923,
June 2010. June 2010.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
 End of changes. 27 change blocks. 
50 lines changed or deleted 83 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/