Protocol Action: 'Indication of support for keep-alive' to Proposed Standard (draft-ietf-sipcore-keep-12.txt)

The IESG <iesg-secretary@ietf.org> Mon, 24 January 2011 17:49 UTC

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'Indication of support for keep-alive' to Proposed Standard (draft-ietf-sipcore-keep-12.txt)
Message-ID: <20110124174935.31524.26653.idtracker@localhost>
Date: Mon, 24 Jan 2011 09:49:35 -0800
Cc: sipcore chair <sipcore-chairs@tools.ietf.org>, Internet Architecture Board <iab@iab.org>, sipcore mailing list <sipcore@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Precedence: list

The IESG has approved the following document:
- 'Indication of support for keep-alive'
  (draft-ietf-sipcore-keep-12.txt) as a Proposed Standard

This document is the product of the Session Initiation Protocol Core
Working Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-sipcore-keep/




Technical Summary

This document defines a mechanism by which adjacent
SIP entities can negotiate the use of the NAT keep-alive
mechanism defined in RFC 5626, even if the other
mechanisms described in RFC 5626 are not being applied.

Working Group Summary

The document was largely without controversy during its
lifetime. Early in the discussion of the mechanism
(in the SIP working group), several people challenged
the utility of a mechanism for negotiating this kind of
behavior (as opposed to simply sending keep-alives
unilaterally). Ultimately, the working group decided
that the chances for things "going wrong" under those
circumstances were too great, and elected to define
an explicit negotiation mechanism.

Document Quality

Several implementors and network operators have indicated that
the have need of and plan to implement the mechanism described
in this document. It is not known whether any implementations
of the mechanism exist. 

RFC Editor Note:

(This note applies to -12 of the document)

In section 10,

OLD: 

  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, based on the procedure in
  section 4.4.2 of RFC 5626, after 7 retransmissions, or when an error
  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).

NEW:

  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 (as described in section 7.2.1 of 
  RFC 5389, [RFC5389] it MUST 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).


In Section 8.1,

OLD:

 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].


NEW:

  This section extends the ABNF definition of via-params from RFC3261 by
  adding a new Via header field parameter, "keep".  The ABNF defined in this 
  specification is conformant to RFC 5234 [RFC5234]. EQUAL is defined in
  RFC 3261. DIGIT is defined in RFC 5234.

Protocol Action: 'Indication of support for keep-… The IESG