SIPPING Working Group A. Johnston Internet-Draft MCI Expires: August 3, 2005 January 30, 2005 SIP, P2P, and Internet Communications draft-johnston-sipping-p2p-ipcom-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 3, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This somewhat terse draft discusses issues related to the application of peer to peer (P2P) technologies to SIP in particular, and Internet communications in general. While early work involving P2P and SIP proposes running P2P protocols over SIP messaging, this draft proposes the opposite layering - replacing SIP discovery and rendezvous functionality with a general P2P protocol. This layering of SIP on top of P2P has many advantages. A number of DHT Johnston Expires August 3, 2005 [Page 1] Internet-Draft P2P and IPCom January 2005 (Distributed Hash Table) P2P protocols that solve some similar functions are given as examples. Finally, an approach to the discovery of NAT traversal relays using a logically separate P2P network is proposed. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SIP is P2P . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. P2P over SIP . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. SIP over P2P . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. P2P NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Informative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Johnston Expires August 3, 2005 [Page 2] Internet-Draft P2P and IPCom January 2005 1. Introduction P2P technologies have been widely used on the Internet in file sharing and other applications including VoIP, IM, and presence. First, the lack of actual usage of the inherent P2P capabilities in SIP is bemoaned. Next, the draft compares two approaches to incorporating additional P2P functionality with SIP. One is to tunnel P2P messages over the SIP protocol. The other is to layer SIP on top of P2P protocols which provide discovery and rendezvous functions. Finally, an approach to the discovery of NAT traversal relays using a logically separate P2P network is proposed. 2. SIP is P2P SIP [1] actually already has quite a lot of inherent P2P capabilities, although most deployments of SIP today barely take advantage of them. For instance, all servers in SIP are optional, allowing User Agents (UAs) to directly communicate. Even when a server such as a proxy server is utilized, after the initial exchange, subsequent messaging is routed on a peer to peer basis using the Contact URI. Even presence can be published and retrieved in a peer to peer manner [2]. However, much development in SIP has been in the area of intermediaries. While the standard specification discusses in detail the roles of registrars, proxy servers, and redirect servers, many actual deployments of SIP have instead used B2BUA intermediaries which completely break the P2P properties of SIP by design. As a result, SIP is not yet a true Internet protocol. It is used today in closed networks, within walled gardens, and in mediated-middle networks. Much of its complexity is a side effect of its deployment in these environments. Some of us, however, have used SIP in P2P mode over the Internet for our personal communication for years. For SIP to truly become an Internet protocol, it needs to escape these closed networks and spread in the public Internet. The best way to make this happen is for SIP to take advantage of P2P technology and truly harness the P2P properties of SIP, rendering the closed networks and their intermediaries irrelevant. 3. P2P over SIP Some preliminary work [3], [4] has been published on the use of SIP and a class of P2P algorithms known as Distributed Hash Tables (DHTs). DHTs are an active research area in the P2P community that is highly scalable and offers efficient, low latency search and retrieval of data over an overlay network. However, these SIP Johnston Expires August 3, 2005 [Page 3] Internet-Draft P2P and IPCom January 2005 approaches propose utilizing DHT algorithms, but tunneling all P2P messages over SIP. For example, these approaches propose using SIP REGISTER requests to join, build, and communicate between peer nodes in the P2P overlay network. The rational for doing so is not clearly explained. Unfortunately, this is one area in which the use of SIP as a transport brings only overhead, delay, and poor scalability. (It also brings to mind the much-discredited DTMF over INFO layer violation.) One type of DHT known as Chord [5], and discussed in later sections, utilizes tables of peer nodes known as Finger Tables. A peer node running the Chord algorithm keeps track of at least N peer nodes, where the maximum network size is 2^N. Using the SHA-1 hashing algorithm, a value of 160 is used for N. In comparison, one Chord over SIP approach recommends instead a Finger Table size of only 32 [3]. Discussions with DHT implementers suggests that real DHT networks need the full 160 node hash table, with even more nodes contacted in a typical query for reasonable latency. Clearly maintaining SIP transaction state with 160 or more dialogs is a significant overhead. Optimizations and caching schemes for DHT algorithms is an area of active research in the P2P community. For the SIP community to try to replicate this work over SIP would require following this work in great detail. However, since many of these optimizations involve communicating with additional nodes in the network beyond the base of 160, it is clear that due to the overhead of SIP tunneling, few of these enhancements could be utilized. Instead, it makes much more sense for SIP to reuse the DHT protocols themselves, allowing them to optimize their own transport schemes. For example, DHT algorithms have been implemented and simulated using UDP and TCP transport, and with a variety of caching, striping, and congestion control algorithms [7]. In addition, a SIP-only approach limits the reach and scale of a P2P system. Instead, the SIP community should be working with the P2P community to standardize an interface between the discovery and rendezvous function (P2P) and session establishment and presence function (SIP). This discovery function could be utilized by any URI-based communications technology. For example, SIP, H.323, XMPP, and proprietary protocols could all share a single discovery P2P network based on DHT protocols. As a result, the SIP community should not seek to replicate other work but instead develop this standard interface, reuse general P2P protocols, and concentrate on solving the security and identity issues specific to P2P. Johnston Expires August 3, 2005 [Page 4] Internet-Draft P2P and IPCom January 2005 The REGISTER method should not be used to tunnel P2P messages - its semantics are already overloaded enough and clearly client/server in nature. Defining new SIP header fields or URI conventions is also unnecessary. Instead, a simplified discovery/rendezvous paradigm should be used. That is, a peer can publish a device against a name, and that name is searchable in the P2P network returning the set of active devices. In SIP, this would be a routable Contact URI against an Address of Record URI. Note: The failure to mention GRUU (Globally Routable User Agent URI) [8] URI in this definition is explicit. This is because the GRUU concept is defined in client/server terms and hence is not applicable here. In addition, note that the current GRUU mechanism work actually suggests a permanent client/server communication mode with SIP - clearly not useful or desirable for P2P SIP. 4. SIP over P2P An alternative architecture is to layer SIP above the P2P layer. SIP would use the P2P layer for discovery and rendezvous. The question of NAT traversal is discussed separately in the following section. The search key in a general discovery and rendezvous mechanism for Internet communications would be a URI. This URI would be a name, and would require resolution to a particular device (URL) that must be performed in real time. As an example set of functions that can be provided at the P2P layer (probably by an API call or similar) is: o Lookup of a key. Returns a set of addresses of peer nodes that store information about the key. o Retrieval of the data from a key node or nodes. o Publishing data to key node or nodes. For example, the Chord [5] distributed hash lookup primitive (http://www.pdos.lcs.mit.edu/chord/) is an active open source research project which provides the first of these functions. With the addition of the other two functions, complete P2P systems can be constructed. For example, the CFS (Cooperative File System) is a read-only file system built on top of Chord that utilizes P2P techniques to request the retrieval of data. CFS utilizes load balancing techniques to break stored data into chunks and randomly distribute them across a number of nodes. Chord is used to maintain routing tables Johnston Expires August 3, 2005 [Page 5] Internet-Draft P2P and IPCom January 2005 identifying which node stores which blocks. The second and third functions are provided by DHash which stores the data reliably in a number of nodes. CFS layers on top a file system that puts the retrieved blocks together as a complete data file. In another example, DDNS [9] is a Chord-based approach for providing DNS lookups. While these applications may not be exactly the discovery and rendezvous capabilities needed for Internet communications, they should be closely studied. Besides DHTs, there are other classes of P2P algorithms including CAN (Content Addressable Network) [10], Pastry [11], and Tapestry [12], The problem statement for each of these algorithms bears a striking similarity to the P2P discovery and rendezvous capability that would be useful in a SIP P2P network. 5. P2P NAT Traversal In some P2P Internet communications networks, the discovery, rendezvous, and NAT traversal functions are combined into a single network and service. In fact, joining some networks require you to agree to provide all of these functions, despite the disparate resource requirements. Logically, the discovery and rendezvous functions should be separate from the NAT traversal functions. A node agreeing to participate in the discovery and rendezvous P2P network should not have to agree to participate in offering NAT traversal. Also, the underlying P2P protocols, optimized for discovery and rendezvous, should not be complicated and burdened with NAT traversal issues. Instead, these protocols should assume that peers manage their own NAT traversal. This is how P2P protocols such as Chord operate today. The discovery of NAT traversal relay services is a useful P2P functionality in itself, however. Such a P2P network will likely be a hierarchical one, with super-nodes offering TURN-like services to normal nodes, with a NAT friendly protocol used between nodes and super-nodes. Once a node behind a NAT acquires a relay, it may then participate in the discovery and rendezvous P2P network. Note: The NAT traversal required is not identical to TURN [13] as it is defined today. The "lock down" property of TURN that limits it to relaying between a pair of hosts is a useful security property in a peer-wise media session. However, this property will block the arbitrary inter-node communication needed for normal P2P communication. As such, a relay acquired for the purposes of allowing a node behind a NAT to participate in a Chord network, for example, will be similar, but not exactly the same as a TURN server. Johnston Expires August 3, 2005 [Page 6] Internet-Draft P2P and IPCom January 2005 6. Conclusion This draft has discussed at a very high level the issues in layering SIP and P2P functions in an Internet communications system. Some Chord-based DHT P2P applications have been discussed as examples of protocols which may meet the discovery and rendezvous requirements of SIP. Finally, some observations were presented on the discovery of NAT traversal relays. 7. Acknowledgements I'd like to thank the members of the SIP community for their conversations about P2P SIP including Henry Sinnreich, Henning Schulzrinne, Robert Sparks, Cullen Jennings, Jon Peterson, and Adam Roach. In addition, thanks to the Chord developers especially Emil Sit for their feedback. 8. Security Considerations SIP utilization of P2P discovery and rendezvous techniques will introduce a number of new security, identity, and privacy considerations that will need to be solved. As a starting point, general P2P security papers such as [14] should be studied before jumping into SIP specific mechanisms. 9. 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] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Bryan, D. and C. Jennings, "A P2P Approach to SIP Registration", Internet-Draft draft-bryan-sipping-p2p-00, January 2005. [4] Singh, K. and H. Schulzrinne, "Peer-to-peer Internet Telephony using SIP", Columbia University Technical Report CUCS-044-04, New York, NY October 2004. [5] Stoica, I., Morris, R., Karger, D., Kaashoek, M. and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications", ACM SIGCOMM 2001, San Deigo, CA August 2001, pp. 149-160. [6] Dabek, F., Kaashoek, M., Karger, D., Morris, R. and I. Stoica, Johnston Expires August 3, 2005 [Page 7] Internet-Draft P2P and IPCom January 2005 "Wide-area Cooperative Storage with CFS", Proceedings of the 18th SOSP 2001. [7] Dabek, F., Kaashoek, M., Li, J., Morris, R., Robertson, J. and E. Sit, "Designing a DHT for Low Latency and High Throughput", NSDI 2004 March 2004. [8] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Internet-Draft draft-ietf-sip-gruu-02, July 2004. [9] Cox, R., Muthitacharoen, A. and R. Morris, "Serving DNS using a Peer-to-Peer Lookup Service", First International Workshop on Peer-to-Peer Systems (Cambridge, MA, Mar. 2002). [10] Ratmasamy, S., Francis, P., Handley, M., Karp, R. and S. Shenker, "A scalable content-addressable network", Proc. ACM SIGCOMM (San Diego, CA, August 2001), pp. 161û172. [11] Rowstron, A. and P. Druschel, "Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems", Proceedings of the 18th IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2001) (Nov. 2001), pp. 329û350. [12] Zhao, B., Kubiatowicz, J. and A. Joseph, "Tapestry: An infrastructure for fault-tolerant wide-area location and routing", Tech. Rep. UCB/CSD-01-1141, Computer Science Division, U. C. Berkeley April 2001. [13] Rosenberg, J., "Traversal Using Relay NAT (TURN)", Internet-Draft draft-rosenberg-midcom-turn-06, October 2004. [14] Sit, E. and J. Robertson, "Security Considerations for Peer-to-Peer Distributed Hash Tables", First International Workshop on Peer-to-Peer Systems (IPTPS 02) March 2002; Cambridge, MA. Author's Address Alan Johnston MCI 100 South 4th Street St. Louis, MO 63102 Email: alan.johnston@mci.com Johnston Expires August 3, 2005 [Page 8] Internet-Draft P2P and IPCom January 2005 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. 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 (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Johnston Expires August 3, 2005 [Page 9]