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]