SIP J. Rosenberg Internet-Draft dynamicsoft Expires: June 26, 2003 December 26, 2002 The Session Initiation Protocol (SIP) INFO Method Considered Harmful draft-rosenberg-sip-info-harmful-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 26, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The Session Initiation Protocol (SIP) INFO method defines a means for transporting mid-dialog application layer data between user agents. Its initial use was to support the transport of ISUP mid-call messages which could not be mapped to any other SIP request method. However, since its initial usage for that purpose, INFO has seen widespread abuse as a means for introducing non-standard and non-interoperable extensions to SIP. For this reason, we now believe INFO should be considered harmful, and therefore, deprecated in its current form. Rosenberg Expires June 26, 2003 [Page 1] Internet-Draft INFO Considered Harmful December 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems with INFO . . . . . . . . . . . . . . . . . . . . . . 4 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 Informative References . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Rosenberg Expires June 26, 2003 [Page 2] Internet-Draft INFO Considered Harmful December 2002 1. Introduction The Session Initiation Protocol (SIP), was first published as RFC 2543 [2] in March of 1999, and later revised as RFC 3261 [1] in June 2002. SIP was engineered to support extensions, through new methods, new headers, new parameters, and new body types. The first extension to SIP that was published after RFC 2543 (and indeed, the only one published before SIP itself was revised), was the SIP INFO method, documented in RFC 2976 [3]. The original application of the INFO method was to support the transport of ISUP mid-call signaling messages, as part of the SIP-T [6] framework. However, the group believed that transport of ISUP messages was an overly narrow problem space. So, the scope of the INFO method was expanded to allow for the transport of any application layer mid-call signaling. As long as it didn't modify the dialog or transaction state, it was a legal usage of INFO. Unfortunately, since the publication of RFC 2976, there has been extensive misuse of INFO to support vendor proprietary extensions, resulting in loss of interoperability, amongst other things. Section 2 overviews the problems with the current specification, and Section 3 proposes a path forward. Rosenberg Expires June 26, 2003 [Page 3] Internet-Draft INFO Considered Harmful December 2002 2. Problems with INFO The problems with INFO derive from its lack of any well defined semantic. Section 2, which overviews the INFO method, has this to say: There are no specific semantics associated with INFO. The semantics are derived from the body or new headers defined for usage in INFO. This means that INFO is purposefully defined as a tunneling protocol for other extensions. Indeed, it has been proposed (and in fact, used), for a wide variety of functions, including: o The transport of DTMF digits to proxies and user agents o Control of media servers o Control of video encoding (fast intra updates, picture freeze)[9] o Managing QoS reservations [8] o Floor control There are several problems with these usages: Lack of Interoperability. None of these usages interoperate. Part of the problem is that many are vendor extensions which are not described through any IETF specifications. Another problem is that INFO itself provides no way to signal the actual usage. Interoperation depends on configuration to properly determine the implied INFO usage. Inappropriateness. Many of these usages are not proper usages for SIP. The guidelines for authors of SIP extensions [7] clearly rules some of them, such as media server control, out of scope. Since INFO is effectively a way to tunnel information between two endpoints connected through SIP, it appears to attract any kind of usage that requires bidirectional information transfer. Many such usages are inappropriate because of the scaling issues (proxy overload), timing issues, and sequencing issues that arise when SIP is used. Incorrectness. Many of these extensions and usages have protocol errors, security weaknesses, race conditions, and so on. These are typically the result of insufficient review by the working group. Such reviews never take place because the INFO method does not define any framework by which its usages can be defined. It Rosenberg Expires June 26, 2003 [Page 4] Internet-Draft INFO Considered Harmful December 2002 does not specify any means by which vendors can publish informational usages, and thereby obtain IETF review. It is our belief that the root cause of these troubles is that INFO is a "content-free framework". It is a framework because it leaves actual protocol semantics to usages - other extensions - which ride ontop of INFO. Its goal as a framework is to support mid-call information transfer unrelated to SIP dialog or transaction state. However, it is "content-free" because it doesn't describe any means by which those extensions can be used in an interoperable way. This is in contrast to the SIP events framework [4], which defines a way to specify packages that build on the framework. It defines an IANA registration procedure, describes guidelines for when the SIP events framework should be used, specifies framework-specific behaviors, and specifies a means for indicating support for particular packages. We believe all of these features are essential for any protocol that defines itself as a framework. However, none of these features are defined in RFC 2976. There are no IANA procedures for "INFO extensions", no guidelines for what makes a good INFO usage, and no means of indicating support for a particular INFO usage. Perhaps most interestingly, it does not specify any semantics for INFO itself. Nothing about INFO processing differs from any other method. Any new feature could be defined using a new method, and would suffer no duplication of functionality compared to defining it as a new usage of INFO. It is this latter characteristic which truly makes it content-free. What is the value of a framework that provides no semantics whatsoever? There is no value. Rosenberg Expires June 26, 2003 [Page 5] Internet-Draft INFO Considered Harmful December 2002 3. Proposed Solution There are a few directions that can be taken to remedy this problem. We enumerate them all for completeness: 1. Do nothing. 2. Revise RFC 2976, turning it into a proper framework. That would mean the specification of an IANA registration procedure, usage guidelines, and so on, patterned after RFC 3265. 3. Revise RFC 2976, restricting its usage to the only approved one - support for SIP-T. We believe that the proper course of action is the third. While the second of these seems attractive, there is really little value. Thats because INFO does not actually define any semantics. The SIP events framework, by contrast, defines a significant amount of behavior as part of the framework. Indeed, one might argue that the vast majority of the semantics of any package exist in the framework. It is merely the definition of some defaults, and the establishment of some guidelines, which rest purely with the package. The exact opposite is true of INFO. In fact, it is not clear that there are any general, usage independent semantics that could be defined. In the absence of such semantics, the usage of a framework provides no value. Option 3 would allow us to retain backwards compatibility with the only approved usage (and one of the most common ones). Any other usage would be non-standard. The functions that were previously being provided by INFO usages would now need to be specified as proper SIP extensions, and would therefore be subject to the SIP change process [5]. That will be valuable in addressing many of the problems outlined in Section 2. The SIP change process will ensure that the extension is a proper SIP usage, is correct in its behavior, and that it interoperates. Rosenberg Expires June 26, 2003 [Page 6] Internet-Draft INFO Considered Harmful December 2002 4. Security Considerations Well documented and reviewed protocols always provide better security than hacks piled ontop of a vague framework. Therefore, we believe this proposal will generally improve the security of the Internet. Rosenberg Expires June 26, 2003 [Page 7] Internet-Draft INFO Considered Harmful December 2002 5. Acknowledgments Credit goes to Dean Willis for suggesting, at some point, that INFO could be reformulated as a framework along the lines of RFC 3265. It is also worth mentioning that the faults of RFC 2976 do not lie with its author, who is a respected contributor in the SIP community. At the time of publication, it represented our best understanding of the way to approach the problem. Significant experience has been gained since its publication, and it is that experience which has led us to conclude that the direction was ultimately not the right one. Rosenberg Expires June 26, 2003 [Page 8] Internet-Draft INFO Considered Harmful December 2002 Informative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. [6] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002. [7] Rosenberg, J., "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", draft-ietf-sip-guidelines-06 (work in progress), November 2002. [8] Salsano, S., Veltri, L. and D. Papalilo, "SIP Extensions for QoS support", draft-veltri-sip-qsip-01 (work in progress), October 2002. [9] Levin, O., Olson, S. and R. Even, "XML Schema for Media Control", draft-levin-mmusic-xml-media-control-00 (work in progress), October 2002. Author's Address Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue East Hanover, NJ 07936 US Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Rosenberg Expires June 26, 2003 [Page 9] Internet-Draft INFO Considered Harmful December 2002 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Rosenberg Expires June 26, 2003 [Page 10] Internet-Draft INFO Considered Harmful December 2002 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg Expires June 26, 2003 [Page 11]