[sipcore] Protocol Action: 'Correct transaction handling for 2xx responses to Session Initiation Protocol (SIP) INVITE requests' to Proposed Standard

The IESG <iesg-secretary@ietf.org> Tue, 06 July 2010 19:35 UTC

Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 47B8E3A69DE; Tue, 6 Jul 2010 12:35:55 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <20100706193555.47B8E3A69DE@core3.amsl.com>
Date: Tue, 06 Jul 2010 12:35:55 -0700
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>
Subject: [sipcore] Protocol Action: 'Correct transaction handling for 2xx responses to Session Initiation Protocol (SIP) INVITE requests' to Proposed Standard
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2010 19:35:55 -0000

The IESG has approved the following document:

- 'Correct transaction handling for 2xx responses to Session Initiation 
   Protocol (SIP) INVITE requests '
   <draft-ietf-sipcore-invfix-01.txt> as a Proposed Standard


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

The IESG contact persons are Gonzalo Camarillo and Robert Sparks.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-invfix-01.txt

      Technical Summary
        This document normatively updates RFC 3261, the Session
        Initiation Protocol (SIP), to address an error in the specified
        handling of certain types of transactions. It also modifies
        response processing under certain circumstances to address
        an identified security risk.

      Working Group Summary
         The mechanism in this document has good support from those
         working group members who participated in its discussion.

      Document Quality
        The document received significant review and comment in 2007
        and 2008, when it was part of the SIP working group. By May
        of 2009, almost a quarter of the SIP implementations at the
        SIPit 24 interoperability testing event had incorporated the
        changes documented by this draft.

        The issue fixed by this document was first reported by Pekka
        Pessi.  Early in the development of the correction documented
        in this work, Brett Tate identified an important and necessary
        modification to the proposed correction, which had significant
        impact on the resulting state maching.

Personnel

The document shepherd is Adam Roach. The responsible AD is Gonzalo
Camarillo.


RFC Editor Note:

Section 3 paragraph 2:
OLD:
   This requirement applies to both proxies and user agents (proxies
   forward the response upstream, the transaction layer at user agents
   forward the response to its "UA (User-Agent) core").  
NEW:
   This requirement applies to both UAs (User Agents) and proxies (proxies



   forward the response upstream, the transaction layer at user agents
   forward the response to its "UA core").  


In the IANA Considerations section add:

 IANA is requested to update the SIP Parameters: Method and Response
Codes 
 registry as follows:

 OLD:

 Methods Reference
 ------- ---------
 INVITE  [RFC3261]

 NEW:

 Methods Reference
 ------- ---------
 INVITE  [RFC3261][RFC-ietf-sipcore-invfix-01]


In the Security Considerations section:

OLD:
   However, this additional state is necessary to
   achieve correct operation.
NEW:
   However, this additional state is necessary to
   achieve correct operation. There is some discussion
   of avoiding state exhaustion and other Denial-of-Service
   attacks in RFC 3261 section 26.3.2.4.

Last paragraph of section 10 first sentence: s/possible/possibly/

Please replace "invfix" in header on pages 2 and forward with "Correct
Handling for SIP 2xx responses"