H. Sinnreich/Adobe, editor A. Johnston/Avaya E. Shim/Panasonic K. Singh/Adobe Internet Draft Expires: March 2007 October 15, 2006 Lightweight SIP Toolkit for Peer-to-Peer and Basic Client- Server Systems Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 15, 2007. Abstract The number of SIP related standards can be significantly reduced for various application scenarios by (1) using SIP Sinnreich et al. Expires March 2007 [Page 1] Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007 without "network based services" and (2) without emulating the telephone network. Such an approach reduces the number of SIP related standards (as by mid 2006) from roughly 100 to about 11. Core SIP interoperability and SIP compliance can be preserved without relying on complex server based networks. Successful IP communications must also include the relevant standards for NAT traversal, some of which are not directly related to SIP and also several standards for security. These standards are included here as well. Conventions used in this document Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction.........................................3 2. Methodology to Develop Lightweight SIP...............4 2.1 Updating the use of SIP and SDP...................5 2.2 Re-using other SIP standards......................6 3. Presence and Instant Messaging.......................6 3.1 Presence............................................6 3.2 Instant Messaging...................................6 4. NAT and Firewall Traversal...........................6 5. Security Considerations..............................7 5.1 Security for SIP Signaling........................7 5.2 Media Security....................................8 5.3 Authenticated Identity for SIP....................8 6. IANA Considerations..................................8 7. Conclusions.......................................8 8. Acknowledgements.....................................8 9. References...........................................9 9.1 Normative References..............................9 9.2 Informative References............................9 Author's Addresses........................................10 Intellectual Property Statement...........................12 Sinnreich et al. Expires March 2007 [Page 2] Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007 Disclaimer of Validity....................................12 Copyright Statement.......................................12 Acknowledgment............................................13 1. Introduction SIP standardization was started in the IETF in 1996 in the expectation to have a simple and flexible protocol for establishing multimedia communication. In the roughly ten years that have passed, the SIP family of related protocols has grown into approximately 100 RFCs with thousands of pages of specifications [12] and an ever increasing number of Internet Drafts, many of them about to join and thus increase even more the large number of existing RFCs on SIP. The common root of the complexity of SIP is (a) the overuse of the client server model and the resulting migration of endpoint applications, such as voice, presence, IM and video into (b) "network based services" trying to emulate the telephone system. P2P SIP systems may not need to support many of the network based services. And by the nature of P2P systems, their architectural difference from client server systems, P2P SIP systems may need approaches different from those taken in the context of client-server (CS) SIP to realize certain services. The emergence of P2P SIP raises the question as to what parts of SIP must be used to (1) preserve the core SIP properties, (2) preserve basic interoperability with server based SIP systems and (3) preserve the advantages of SIP for use in P2P communication systems. The objective of this memo is to clarify what parts of SIP are essential to meet these objectives. We will refer for brevity in the following to these essential tools for SIP as "LIGHTWEIGHT SIP". This memo is not trying to redefine SIP in any sense. Also, it is important to note that using the lightweight tools for SIP is not a profile of SIP. Furthermore it involves no modifications or subtractions to the MUSTs in RFC3261. And it is not a subset of the SIP protocol, either. However, it represents an attempt to reign in the seemingly endless set of SIP extensions which add "network functionality and services" to the SIP ecosystem. Sinnreich et al. Expires March 2007 [Page 3] Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007 Lightweight SIP separates the SIP discovery and message routing functions from the other SIP extensions aimed at providing applications in the network. The notion of basic CS SIP is understood here as the functions that provide only endpoint discovery and SIP message routing for session initiation. Though Lightweight SIP is targeted primarily for P2P SIP, Lightweight SIP is also useful for basic CS SIP systems that use the peer-to-peer SIP call control model [13], not to be confused with P2P SIP. Even complex telephony functions can be accomplished with Lightweight SIP, but with the difference that all the complex features are endpoint resident. Such applications do not rely on any other service in the network except registration and proxy, as specified in RFC 3261. Examples of specialized telephony applications residing in endpoints are the interactive voice response (IVR), the auto-attendant, the receptionist workstation and the agent workstation in a customer contact center. Lightweight SIP is therefore limited to the original intent of SIP; establishing sessions between endpoints and leaving the applications in the endpoints. Establishing a session also includes the negotiation of the session parameters. 2. Methodology to Develop Lightweight SIP The method to develop Lightweight SIP has several parts: a. Preserve the basic SIP definitions as per RFC 3261 [2]. SIP can work with or without servers. The trapezoid model in RFC 3261 is only an example. Also, in the trapezoid model no attempt is made to provide any specific services in the network, since the proxies only act as application level message routers. We do not propose any changes to RFC 3261, to eliminate any methods or headers, error messages, etc., since this would carry among other risks the danger of losing backward interoperability and lack of flexibility. b. Analyze the main SIP related specifications as highlighted in [14] and eliminate all network based services residing in servers and various other network elements. Sinnreich et al. Expires March 2007 [Page 4] Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007 c. Adopt the NAT traversal techniques developed for SIP. d. Adopt the security techniques developed for SIP and RTP, to the extent that they are not dependent on central control and on providing network based telephony style services. 2.1 Updating the use of SIP and SDP We do not intend to re-write RFC 3261 for Lightweight SIP, but to take into account later work in SIP. Examples are: . Add items that have been developed in later work on SIP, such as the use of "rport" in the Via header and how to use the connection data "c=" in the SDP body behind a NAT. This information is now used differently as per RFC 3489bis defining the STUN protocol. . Add the offer/answer model with SDP as per RFC 3264 [3]. . Add Locating SIP Servers [4]. . Make TLS mandatory and leave S/MIME optional since it has not found as wide acceptance. Note that not making S/MIME mandatory does not preclude end-to-end privacy of messages in P2P SIP. End-to-end privacy is still possible in the single hop P2P SIP architecture. . Simplify early media by specifying that User Agents accept but do not generate early media. Early media functionality is best delegated to IP-PSTN VoIP gateway networks. Most of the User Agent behavior described in RFC 3261 can be re-used in Lightweight SIP, while the proxy behavior should be Sinnreich et al. Expires March 2007 [Page 5] Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007 limited to the most basic interoperability between P2P SIP nodes and CS SIP systems. One key difference between RFC 3261 and P2P SIP systems is the replacement of the location database at the back side of SIP proxy and registrar servers with the P2P DHT layer as proposed in [15]. 2.2 Re-using other SIP standards A summary review of the other over roughly 100 SIP related standards reveals that they are mostly dedicated to telephony style of "services in the network" and therefore are out of scope for Lightweight SIP. The only exception is probably RFC 3840 for indicating user agent capabilities [5], such as for various media types and SIP events. 3. Presence and Instant Messaging 3.1 Presence Subscriptions and notifications for presence based on SIP have been defined in [6] and the data format for presence information has been defined in [7]. Rich presence information can be conveyed about the location, activity and other data about a user. Presence can also be used to integrate applications and communications. Such extended applications for presence are however beyond the scope of this memo. 3.2 Instant Messaging Instant messaging for SIP is based on the simple extension "MESSAGE" defined in [8]. Interesting activity information can be conveyed in various ways, such as the indication of "is typing" [9]. 4. NAT and Firewall Traversal While NAT traversal is not strictly speaking a SIP signaling property, we believe that any IP communication and application is useless without complete NAT traversal capabilities. The essential documents for a complete solution for NAT traversal for SIP based communications are referenced here. Sinnreich et al. Expires March 2007 [Page 6] Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007 A. Requirements for NAT to "behave" [16] for UDP packets. B. NAT Traversal for SIP 1. Updating the Via header information with "rport" for symmetric response routing [10]. 2. Connection reuse for "SIP Outbound" [17]. C. NAT Traversal for RTP/RTCP Media 1. Symmetric RTP [11] 2. Simple Traversal Under NAT (STUN) [18] 3. Media relay function for STUN servers [19] 4. Interactive Connectivity Establishment (ICE) [20]. An excellent summary of all the above in the form of deployment examples is given in the document on NAT scenarios [21]. 5. Security Considerations Security for SIP communications touches on both signaling and media. Existing security standards for CS SIP are described here. In P2P SIP systems, besides the security for signaling and media, the additional security for the P2P layer must also be provided. There are however no security standards as yet for P2P SIP. 5.1 Security for SIP Signaling SIP secure authentication between the UA and the server is based on the digest authentication schema as specified in RFC 3261. SIP transport security for confidentiality is based on Transport Level Security (TLS) that is also specified in RFC 3261. End-to-end SIP security through intermediaries based on S/MIME has not found wide application at present, but it MAY be implemented in Lightweight SIP. Instead, P2P TLS connections SHOULD be used to achieve end-to-end security. Sinnreich et al. Expires March 2007 [Page 7] Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007 5.2 Media Security End-to-end media security without any dependency on intermediaries, such as SIP proxies and certificate authorities will be provided using SRTP as per RFC 3711. Key management for SRTP is currently an active area of discussion and standardization in the IETF. The authors favor key management approaches that have no reliance on centralized certificate authorities and PKI infrastructures. For VoIP, the recommended protocol is ZRTP protocol [22]. ZRTP is based on users authenticating themselves to each other by voice or video, before activating media encryption for the rest of the conversation and for all following communications. 5.3 Authenticated Identity for SIP In scenarios where the identity and authentication is required, the SIP identity header will be used as described in [23]. In P2P systems, the user enrollment server can be the source for the authentication service. 6. IANA Considerations There are no IANA considerations associated with this memo. 7. Conclusions We have shown in this document how the number of SIP related standards for presence, IM and multimedia communications can be reduced by (1) using SIP without network based services and (2) without emulating the telephone network. The approach for Lightweight SIP reduces the number of SIP related standards (as in 2006) from roughly 100 to about 11. Successful IP communications must however include a number of standards for NAT traversal, some of which are not directly related to SIP. The standards for NAT traversal are however referenced here, since SIP based communications must traverse NAT. 8. Acknowledgements We would like to thank Wilhelm Wimmreuter for the detailed review of the initial draft. Sinnreich et al. Expires March 2007 [Page 8] Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007 9. References 9.1 Normative References [1] RFC 2119: "Key words for use in RFCs to Indicate Requirement Levels" by S. Bradner. IETF, March 1997. [2] RFC 3261: "SIP: Session Initiation Protocol" by J. Rosenberg et al. IETF June 2002. [3] RFC 3264: "An Offer/Answer Model with Session Description Protocol (SDP)" by J. Rosenberg and H. Schulzrinne. June 2002. [4] RFC 3263 "Locating SIP Servers" by J. Rosenberg and H. Schulzrinne. IETF, June 2002. [5] RFC 3840: "Indicating User Agent Capabilities in SIP" by J. Rosenberg, et al. IETF, August 2004. [6] RFC 3856: "A Presence Event Package for SIP" by J. Rosenberg. IETF, August 2004. [7] RFC 3863 "Presence Information Data Format (PIDF)" by H. Sugano et al. IETF, August 2004. [8] RFC 3428: "SIP Extension for Instant Messaging" by B. Campbell et al. IETF, December 2002. [9] RFC 3994: "Indication of Message Composition for Instant Messaging" by H. Schulzrinne. IETF, January 2005. [10] RFC 3581: "An Extension to SIP for Symmetric Response Routing" by J. Rosenberg and H. Schulzrinne. IETF, August 2003. [11] RFC xxxx: "Symmetric RTP and RTCP Considered Helpful" by D. Wing. IETF, 2006. 9.2 Informative References [12] "VoIP RFC Watch" by Nils Ohlmeier, http://rfc3261.net/. [13] "A Call Control and Multi-party usage framework for SIP" by R. Mahy et al. . Work in progress, IETF, March 2006. Sinnreich et al. Expires March 2007 [Page 9] Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007 [14] "A Hitchikers' Guide to SIP" by J. Rosenberg. . Work in progress, IETF, February 2006. [15] "SIP, P2P and internet Communications" by A. Johnston and H. Sinnreich. Work in progress, Internet Draft, IETF, March 2006. [16] "NAT Behavioral Requirements for Unicast UDP" by F. Audet and C. Jennings. Work in progress, , IETF, May 2006. [17] "Managing Client Initiated Connections in SIP" by C. Jennings and R. Mahy. Work in progress, < draft-ietf-sip- outbound>, IETF, June 2006. [18] RFC 3489bis: "Simple Traversal Under NAT (STUN)" by J. Rosenberg et al. Work in progress, < draft-ietf-behave- rfc3489bis> , IETF, July 2006. [19] "Obtaining Relay Addresses from Simple Traversal of UDP Through NAT (STUN)" by J. Rosenberg, . Work in progress, IETF, February 2006. [20] "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols" by J.Rosenberg. Work in progress, , IETF, August 2006. [21] "Best Current Practices for NAT Traversal for SIP" by C. Boulton et al. Work in progress, < draft-ietf-sipping-nat- scenarios>, IETF, June 2006. [22] "ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP" by P. Zimmermann et al. Work in progress, IETF, March 2006. [23] "Enhancements for Authenticated Identity Management in SIP" by J. Peterson and C. Jennings, . Work in progress, IETF, October 2005. Author's Addresses Alan Johnston Avaya Sinnreich et al. Expires March 2007 [Page 10] Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007 211 Mt. Airy Rd. Basking Ridge, NJ 07920 USA Email: alan.b.johnston@avaya.com Eunsoo Shim Panasonic Princeton Laboratory Two Research Way, 3rd Floor Princeton, NJ 08540, USA Email: eunsoo@research.panasonic.com Kundan Singh Adobe Systems, Inc. 601 Townsend Street, San Francisco, CA 94103, USA Email: kundan@adobe.com Henry Sinnreich Adobe Systems, Inc. 601 Townsend Street, San Francisco, CA 94103, USA Email: henrys@adobe.com Sinnreich et al. Expires March 2007 [Page 11] Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Sinnreich et al. Expires March 2007 [Page 12] Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sinnreich et al. Expires March 2007 [Page 13]