Network Working Group E. Marocco Internet-Draft Telecom Italia Expires: November 16, 2006 D. Bryan SIPeerior Technologies/William and Mary May 15, 2006 P2P SIP in Disconnected or Limited Connectivity Scenarios draft-marocco-sipping-p2p-scenarios-00 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 November 16, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides a detailed description of some scenarios where SIP Connectivity could be easily achieved only in a peer to peer fashion. Other than identifying use cases where a P2P SIP overlay Network is the only affordable solution, it describes how, under some circumstances, signaling and media communications both to and from public domains can be achieved with P2P SIP. Furthermore, it Marocco & Bryan Expires November 16, 2006 [Page 1] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 identifies some additional elements which can be shared by community members or let out by access providers for extending SIP Connectivity to such limited environments. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope of the Document . . . . . . . . . . . . . . . . . . 4 2. Common Environments Requiring P2P SIP . . . . . . . . . . . . 5 2.1. Ad-Hoc Networks . . . . . . . . . . . . . . . . . . . . . 5 2.2. Host Networks . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Metropolitan Free Wireless Networks . . . . . . . . . 6 3. Connecting P2P and Public SIP Domains . . . . . . . . . . . . 7 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Signaling Flow . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Media Flow . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Common Scenarios . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Ephemeral Overlay Networks . . . . . . . . . . . . . . . . 10 4.2. Stable Overlay Networks . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Marocco & Bryan Expires November 16, 2006 [Page 2] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 1. Introduction This document provides a detailed description of some scenarios where SIP Connectivity [2] could be easily achieved only in a peer to peer fashion. The deployment of these scenarios will allow multimedia communications in limited environments at different levels, from local communications in small ephemeral networks to global reachability in limited access LANs. The growing diffusion of cheap wireless devices has made common some minimal network topologies where few or no traditional services can be effectively deployed. These topologies range from ad-hoc networks to free metropolitan wireless networks which allow Internet access only for a small set of services (usually HTTP, HTTPS, POP3, IMAP4 and SMTP). Such networks still offer enough bandwidth for multimedia communications between local nodes, but, because of infrastructure fragility, they are unlikely to support the deployment of centralized elements; P2P SIP [3] fits well in such environments. Moreover, if some peer which has joined a P2P SIP overlay network also has a public address, it can advertise itself as a P2P SIP proxy for reaching public SIP domains and as a Relay Agent for allowing multimedia communications for other peers. 1.1. Terminology In this document, words which are normally key words, such as "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are used COLLOQUIALLY and are not intended to be interpreted as described in RFC 2119 [1]. Definitions in this document are intended to be in keeping with terminology used in the P2P SIP community [3], [4], [5] and [6]. Terminology defined in RFC 3261 [2] is used without definition. Overlay Network or Overlay: This document refers to the virtual network created by the interconnection between the nodes participating in the P2P SIP network as the "overlay network". Distributed Hash Table (DHT): The base mechanism of an overlay network, realized in cooperation by all the peers. The main functionalities of a DHT are storing and retrieving key-values pairs; Node or Peer: Any entity that participates in the overlay network, understanding the P2P SIP extensions [3], is a "node" or "peer". Marocco & Bryan Expires November 16, 2006 [Page 3] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 P2P SIP Proxy: A node of an overlay network which is able to route SIP messages directed to public URLs. If a P2P SIP proxy is bound to a Fully Qualified Domain Name (FQDN), it can be used also for routing SIP messages directed to nodes of the overlay network. Relay Agent: An element registered with the overlay network which provides relayed transport addresses through protocols like TURN [7] and TEREDO [8] for allowing media streaming between P2P SIP nodes and user agents (UAs) on the Internet. 1.2. Scope of the Document This document is focused on identifying those scenarios where, due to constraints such as strict network configurations, limited connectivity, or lack of bandwidth, it is not possible to use the SIP protocol for both local and Internet-wide communications. In such scenarios - a subset of P2P SIP use cases [4] - it is possible to establish an overlay network which allows SIP communications between local nodes. The main goals of this document are: o describing how a P2P SIP network could provide signaling and media connectivity with public traditional SIP networks; o identifying the minimal requirements for extending global SIP Connectivity to a limited P2P SIP network; o classifying common scenarios where SIP communications are available only in a peer to peer fashion; Scenarios described in this document match with those P2P SIP use cases [4] where traditional SIP could not be considered a practical choice. Marocco & Bryan Expires November 16, 2006 [Page 4] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 2. Common Environments Requiring P2P SIP IP based communications and advanced network applications using the SIP protocol are often desirable in environments where it is not reasonable to deploy centralized elements like SIP proxies and SIP registrars [2]; in such environments, it is still possible to establish SIP connectivity through the medium of an overlay network made up by all or some of the interested peers. Additionally, under some conditions the overlay can provide the same functionalities as a traditional SIP network in a way that is transparent to the user. This section describes some network environments characterized by limitations in connectivity such that use of traditional SIP infrastructures is not desirable, and which are considered use cases for P2P SIP [4]. 2.1. Ad-Hoc Networks Ad-hoc networks are extremely ephemeral and often provide connectivity only between nodes of the network. Despite the ease of deployment - such networks are self-organizing and can be built with common wireless devices - their adoption is often limited to custom applications due to a lack of basic services. In fact, even though ad-hoc networks often have sufficient bandwidth for most Internet applications, virtually all such applications require at least a DNS server to be usable. In such an environment, SIP mechanisms could be used to locate resources, even in the absence of a naming service such as DNS. However, it would not be practical to deploy centralized SIP elements mainly because of the fragility of the links. An overlay network, because of its intrinsic fault tolerance, could be effectively established. 2.2. Host Networks Mobile devices like laptops or PDAs often access host networks where the use of Internet services requires credentials that are not practical to get. In these networks - school and enterprise LANs often fall in this category - it is likely SIP service is available, but because the network's access policies are identity based, the SIP service may be unusable for occasional visitors. Sometimes in such environments, it happens that authorized users need to share reserved services with visitors; unfortunately this is frequently achieved by sharing precious credentials. P2P SIP is a valid alternative both for establishing a local communication service and for sharing resources needed for communicating with external Marocco & Bryan Expires November 16, 2006 [Page 5] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 users. 2.2.1. Metropolitan Free Wireless Networks During the past few years wireless technologies have successfully been adopted to deploy huge networks offering Internet access to entire cities. Additionally, new business models are pushing Internet service providers to offer free access to their users. It is probable that, in the near future, big cities will be covered by freely accessible wireless networks. Although these networks may have fast, high capacity links between local nodes, they may offer only limited connectivity to the Internet. In fact, due to cost limitations, they will not be able to support the traffic generated by applications with high bandwidth requirements towards the Internet; most likely, they will only allow common protocols like HTTP, HTTPS, POP3, IMAP4 and SMTP. Because of these limitations, such networks can be considered a particular case of host network and are a proper candidate for P2P SIP adoption; it would allow both the creation of a local communication service and potentially a method for providing additional resources needed for communicating with users on the Internet. Marocco & Bryan Expires November 16, 2006 [Page 6] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 3. Connecting P2P and Public SIP Domains The most desirable scenario is one where, through the deployment of elements like relay agents and P2P SIP proxies and the relative bindings in the public naming service (DNS), an overlay network provides full connectivity with public SIP domains (often client- server based). 3.1. Overview A P2P SIP overlay network should provide the following resources to permit full connectivity: o a P2P SIP proxy [5] with a public address, registered both with the Distributed Hash Table (DHT) and bound to a Fully Qualified Domain Name (FQDN); o a relay agent with a public address, registered with the DHT. Relay agents must be able to provide relayed transport addresses through protocols like TURN [7] and TEREDO [8] to allow media streaming between P2P SIP nodes and user agents (UAs) on the Internet. Moreover, the nodes wishing to have full connectivity must be registered with the DHT using Address of Records (AOR) with the host part matching the FQDN bound to P2P SIP proxies (see the example in Section 3.4 for clarification). A practical way to satisfy this requirement would be to bind P2P SIP proxies with a FQDN which matches the overlay name, and, in the mean time, to restrict DHT registrations to AORs with the host part matching that name. 3.2. Signaling Flow To exchange SIP signaling with UAs on the Internet, a node of a P2P SIP overlay network would likely have to: 1. register a unique temporary AOR with the DHT. The AOR's host part must match the overlay name; 2. find in the DHT a P2P SIP proxy registered both with the overlay and in the public naming service (DNS); 3. if the node has a SIP account with a public domain, it may register its AOR using the temporary AOR registered with the DHT as contact. Obviously, the REGISTER message must be routed to the P2P SIP proxy. If the registering user does not have an account with a public AOR, Marocco & Bryan Expires November 16, 2006 [Page 7] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 it can still be reached from the Internet with the URL registered with the overlay; however, such URL does not assure the identity of the user and its best usage is as a contact value. Once properly registered, the user will be able to send and receive SIP messages using any P2P SIP proxy bound to the right FQDN as an outbound proxy. However, since nodes may not have direct connectivity to the Internet, P2P SIP proxies must record route every SIP message. 3.3. Media Flow In the typical environment where P2P SIP overlay networks will be deployed, media streams between overlay nodes and UAs on the Internet may have to flow through relay agents and media session will be established using the ICE [9] mechanism. Therefore it is important for any DHT to provide a method for registering and retrieving elements like TURN servers [7] and TEREDO relays [8]; a naive one would be to reserve local URLs for that purpose (e.g. sip:stun- relay@..., sip:teredo-relay@..., urn:service:relay..., etc). 3.4. Example Assume Alice's UA has its default account configured for sip:alice@atlanta.com; after a reboot it gets access to a wireless LAN with the address 192.168.1.123, but cannot register with its default SIP registrar sip:atlanta.com, so it starts the P2P SIP module: 1. it discovers and joins the overlay named "overlay.citynetwork.org"; 2. it performs a registration in the DHT for the AOR sip:alice1@overlay.citynetwork.org and the contact sip: 192.168.1.123; 3. it queries the DHT for the URL sip:overlay.citynetwork.org and gets the contacts sip:192.168.1.100 and sip:192.168.1.200. Each of these elements can now be used as P2P SIP proxies; 4. using sip:192.168.1.100 or sip:192.168.1.200 as outbound proxy, it sends a REGISTER message to sip:atlanta.com for binding the AOR sip:alice@atlanta.com to sip:alice1@overlay.citynetwork.org. At this point, Alice is reachable from anywhere in the Internet. When Bob calls Alice using the known URL sip:alice@atlanta.com, the following occurs: Marocco & Bryan Expires November 16, 2006 [Page 8] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 1. Bob's UA routes an INVITE message for Alice to sip:atlanta.com; 2. the proxy authoritative for sip:atlanta.com finds sip:alice1@overlay.citynetwork.org as the contact of sip:alice@atlanta.com, so it performs a name resolution for overlay.citynetwork.org. Since the DNS resolution returns two addresses (the public addresses of the two P2P SIP proxies previously found by Alice's UA), it routes the INVITE to one of those; 3. the P2P SIP proxy which receives the INVITE performs a query in the DHT and routes the message to Alice's local address 192.168.1.123; 4. for establishing a media stream, Alice's UA queries the DHT for sip:stun-relay@overlay.citynetwork.org and sip:teredo-relay@overlay.citynetwork.org to find a TURN [7] or a TEREDO [8] server for gathering accessible relayed addresses. If Bob's UA supports ICE [9], it will be used for converging on the most efficient transport, otherwise the choice will be made following some pre-configured policy. Analogously, when Alice calls Bob at his URL sip:bob@biloxi.com: 1. Alice's UA queries the DHT for sip:stun-relay@overlay.citynetwork.org and sip:teredo-relay@overlay.citynetwork.org to find a TURN [7] or a TEREDO [8] server for gathering accessible relayed addresses; 2. Alice's UA builds an ICE [9] media session offer with the gathered candidates; 3. using sip:192.168.1.100 or sip:192.168.1.200 (the P2P SIP proxies retrieved at registration time or later) as outbound proxy, Alice's UA sends an INVITE to sip:bob@biloxi.com. It is worth noting that for proper behavior P2P SIP proxies must record route every message. Marocco & Bryan Expires November 16, 2006 [Page 9] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 4. Common Scenarios [TODO: this whole section should be merged with use cases draft] P2P SIP overlay networks will typically be deployed in environments with restricted connectivity to the Internet, where traditional SIP could not be practically used. While it would be often better to have the full-connected scenario described in Section 3, in some cases it is sufficient to have local connectivity. The scenarios can be distinguished from the nature of the overlay network they imply: ephemeral or stable. 4.1. Ephemeral Overlay Networks Ephemeral P2P SIP overlay networks will be deployed for satisfying temporary needs. Some common scenarios would be: o occasional ad-hoc networks in aggregation places: mainly for gaming, in airports, on trains or in schools; o special events in unconfigured network environments: mainly meetings in hotels, universities or enterprises; o emergency networks. 4.2. Stable Overlay Networks Stable P2P SIP overlay networks will be deployed for enabling SIP usage in environments where, due to impeded access to configurations or infrastructure fragility, it would not be practical to deploy centralized elements. Some common scenarios would be: o cheap wireless networks shared between neighbors: other than enabling local communications, it would let users share resources when they do not need them (e.g. a broadband access when the owner does not need it); o communications in metropolitan wireless networks: both for local communications and for sharing/hiring out broadband access (see Section 2.2.1). Marocco & Bryan Expires November 16, 2006 [Page 10] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 5. Security Considerations In addition to the security issues already raised in SIP [2] and earlier P2P SIP work [3] [5], the interconnection model based on "well known" URIs is vulnerable to spoofing attacks. [TODO: address spoofing attack] Another critical weakness is the registration of P2P SIP proxies with a public DNS; it could be either a point of failure, if registration policies are too permissive, or a threat to the peer to peer model, if they are too restrictive. [TODO: address DNS bindings issues] The full connected scenario (see Section 3) is where Identity Assertion is most important; this document shows how it could be achieved proxying regular authentication to traditional SIP domains. [TODO: is security weakness more justifiable in this scenarios?] 6. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Bryan, D., "A P2P Approach to SIP Registration and Resource Location", draft-bryan-sipping-p2p-02 (work in progress), March 2006. [4] Bryan, D., "Use Cases for Peer-to-Peer Session Initiation Protocol (P2P SIP)", draft-bryan-sipping-p2p-usecases-00 (work in progress), December 2005. [5] Shim, E., "An Architecture for Peer-to-Peer Session Initiation Protocol (P2P SIP)", draft-shim-sipping-p2p-arch-00 (work in progress), March 2006. [6] Baset, S., "Requirements for SIP-based Peer-to-Peer Internet Telephony", draft-baset-sipping-p2preq-00 (work in progress), November 2005. [7] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal of UDP Through NAT (STUN)", draft-ietf-behave-turn-00 (work in Marocco & Bryan Expires November 16, 2006 [Page 11] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 progress), March 2006. [8] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", draft-huitema-v6ops-teredo-05 (work in progress), April 2005. [9] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-08 (work in progress), March 2006. Marocco & Bryan Expires November 16, 2006 [Page 12] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 Authors' Addresses Enrico Marocco Telecom Italia Via G. Reiss Romoli, 274 Turin 10148 Italy Phone: +39 011 228 5029 Email: enrico.marocco@telecomitalia.it David Bryan SIPeerior Technologies and William and Mary Dept. of Computer Science P.O. Box 8795 Williamsburg, VA 23187 USA Email: bryan@ethernot.org Marocco & Bryan Expires November 16, 2006 [Page 13] Internet-Draft P2P SIP in Limited Connectivity Scenarios May 2006 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Marocco & Bryan Expires November 16, 2006 [Page 14]