Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, sip mailing list <firstname.lastname@example.org>, sip chair <email@example.com> 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  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.