Internet DRAFT - draft-marocco-sipping-p2p-scenarios
draft-marocco-sipping-p2p-scenarios
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]
