Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction
RFC 4321

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    sip mailing list <sip@ietf.org>, 
    sip chair <sip-chairs@tools.ietf.org>
Subject: Protocol Action: 'Actions addressing identified issues 
         with the Session Initiation Protocol's non-INVITE Transaction' 
         to Proposed Standard 

The IESG has approved the following documents:

- 'Actions addressing identified issues with the Session Initiation 
   Protocol's non-INVITE Transaction '
   <draft-sparks-sip-nit-actions-04.txt> as a Proposed Standard
- 'Problems identified associated with the Session Initiation Protocol's 
   non-INVITE Transaction '
   <draft-sparks-sip-nit-problems-03.txt> as an Informational RFC

These documents are products of the Session Initiation Protocol Working 
Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-actions-04.txt

Technical Summary

   draft-sparks-sip-nit-problems is an informational description of
   the problems that arise in SIP because the protocol design for
   non-INVITE transactions (message exchanges other than the
   initiation handshake that begins with INVITE) were designed with 
   timing rules which have turned out to cause race conditions, 
   useless traffic and potential storms.  A security issue is
   identified in that these problems could even be exploited by
   a malicious actor.

   draft-sparks-sip-nit-actions describes the solutions for the
   problems described in the companion document.

   These solutions motivate several modifications in normative processing
   in the Session Initiation Protocol (SIP), in RFC 3261, and they
   are shown to address the problems identified with the SIP
   non-INVITE transaction.  These modifications reduce the probability
   of messages losing the race condition inherent in the non-INVITE
   transaction and reduce useless network traffic.  They also improve
   the robustness of SIP networks when elements stop responding. 
  
   draft-sparks-sip-nit-actions updates RFC 3261.
 
 Working Group Summary
 
  It was very difficult for the SIP Working Group to come to consensus on
  the scope of problems with non-INVITE transactions.  Demonstrating
  and narrowing the problem statement required a very careful set of consensus
  discussions related to the differences in perspective of the participants,
  and the difficulty of obtaining a completely clear statement of complex
  issues.  The consensus once won resulted in clear solutions, and both
  documents were forwarded for advancement with strong consensus.
 
Protocol Quality
 
 The initiation of this work was due to the editor's activities with
 implementations in SIP interoperability events.  He has stated that the 
 problem statement and solutions are both implementation-based.

The Responsible Area Director for the documents is Allison Mankin.  
The Working Group Shepherd for these documents is Rohan Mahy.

Notes to the RFC Editor
 
Replace the Security Considerations Section  text of 
draft-ietf-sip-nit-problems-02.txt with:

   This document describes some problems in the core SIP
   specification [1] related to the SIP non-INVITE, the messages other
   than the INVITE handshake that begins transactions.  A few of
   the problems lead to flooding or forgery risk, and could possibly be
   exploited by an adversary in a denial of service attack.  Solutions are
   defined in the companion draft-sip-nit-action-03.txt [RFC Editor - 
   replace this with the corresponding RFC number].
   
   One solution there prohibits proxies and User Agents from sending 408
   responses to non-INVITE transactions.  Without this change, proxies
   automatically generate a storm of useless responses.
   An attacker could capitalize on this by enticing User Agents to
   send non-INVITE requests to a black hole (through social engineering
   or DNS poisoning) or by selectively dropping responses.

   Another solution prohibits proxies from forwarding late responses.
   Without this change, an attacker could easily forge messages which
   appear to be late responses.  All proxies compliant with RFC 3261 are
   required to forward these responses, wasting bandwidth and CPU and
   potentially overwhelming target User Agents (especially those with
   low speed connections).
------
Please change the name of the References sections in draft-sparks-nit-problems
to Informative References, and in draft-sparks-nit-actions-03.txt to 
Normative References.