| TOC |
|
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 © The Internet Society (2006).
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 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.
1.
Introduction
1.1.
Terminology
1.2.
Scope of the Document
2.
Common Environments Requiring P2P SIP
2.1.
Ad-Hoc Networks
2.2.
Host Networks
2.2.1.
Metropolitan Free Wireless Networks
3.
Connecting P2P and Public SIP Domains
3.1.
Overview
3.2.
Signaling Flow
3.3.
Media Flow
3.4.
Example
4.
Common Scenarios
4.1.
Ephemeral Overlay Networks
4.2.
Stable Overlay Networks
5.
Security Considerations
6.
References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
This document provides a detailed description of some scenarios where SIP Connectivity [2] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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] (Bryan, D., “A P2P Approach to SIP Registration and Resource Location,” March 2006.) 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.
| TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [1].
Definitions in this document are intended to be in keeping with terminology used in the P2P SIP community [3] (Bryan, D., “A P2P Approach to SIP Registration and Resource Location,” March 2006.), [4] (Bryan, D., “Use Cases for Peer-to-Peer Session Initiation Protocol (P2P SIP),” December 2005.), [5] (Shim, E., “An Architecture for Peer-to-Peer Session Initiation Protocol (P2P SIP),” March 2006.) and [6] (Baset, S., “Requirements for SIP-based Peer-to-Peer Internet Telephony,” November 2005.).
Terminology defined in RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [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] (Bryan, D., “A P2P Approach to SIP Registration and Resource Location,” March 2006.), is a "node" or "peer".
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 (Rosenberg, J., “Obtaining Relay Addresses from Simple Traversal of UDP Through NAT (STUN),” March 2006.) [7] and TEREDO (Huitema, C., “Teredo: Tunneling IPv6 over UDP through NATs,” April 2005.) [8] for allowing media streaming between P2P SIP nodes and user agents (UAs) on the Internet.
| TOC |
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] (Bryan, D., “Use Cases for Peer-to-Peer Session Initiation Protocol (P2P SIP),” December 2005.) - it is possible to establish an overlay network which allows SIP communications between local nodes.
The main goals of this document are:
Scenarios described in this document match with those P2P SIP use cases [4] (Bryan, D., “Use Cases for Peer-to-Peer Session Initiation Protocol (P2P SIP),” December 2005.) where traditional SIP could not be considered a practical choice.
| TOC |
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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.); 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] (Bryan, D., “Use Cases for Peer-to-Peer Session Initiation Protocol (P2P SIP),” December 2005.).
| TOC |
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.
| TOC |
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 users.
| TOC |
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.
| TOC |
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).
| TOC |
A P2P SIP overlay network should provide the following resources to permit full connectivity:
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 (Example) 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.
| TOC |
To exchange SIP signaling with UAs on the Internet, a node of a P2P SIP overlay network would likely have to:
If the registering user does not have an account with a public AOR, 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.
| TOC |
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 (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” March 2006.) [9] mechanism. Therefore it is important for any DHT to provide a method for registering and retrieving elements like TURN servers [7] (Rosenberg, J., “Obtaining Relay Addresses from Simple Traversal of UDP Through NAT (STUN),” March 2006.) and TEREDO relays [8] (Huitema, C., “Teredo: Tunneling IPv6 over UDP through NATs,” April 2005.); a naive one would be to reserve local URLs for that purpose (e.g. sip:stun-relay@..., sip:teredo-relay@..., urn:service:relay..., etc).
| TOC |
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:
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:
Analogously, when Alice calls Bob at his URL sip:bob@biloxi.com:
It is worth noting that for proper behavior P2P SIP proxies must record route every message.
| TOC |
[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 (Connecting P2P and Public SIP Domains), 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.
| TOC |
Ephemeral P2P SIP overlay networks will be deployed for satisfying temporary needs. Some common scenarios would be:
| TOC |
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:
| TOC |
In addition to the security issues already raised in SIP [2] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) and earlier P2P SIP work [3] (Bryan, D., “A P2P Approach to SIP Registration and Resource Location,” March 2006.) [5] (Shim, E., “An Architecture for Peer-to-Peer Session Initiation Protocol (P2P SIP),” March 2006.), 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 (Connecting P2P and Public SIP Domains)) 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?]
| TOC |
| [1] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [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 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. |
| TOC |
| 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 |
| TOC |
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.
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 © 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.
Funding for the RFC Editor function is currently provided by the Internet Society.