--- 1/draft-ietf-p2psip-concepts-00.txt 2007-11-15 20:12:09.000000000 +0100 +++ 2/draft-ietf-p2psip-concepts-01.txt 2007-11-15 20:12:09.000000000 +0100 @@ -1,22 +1,24 @@ P2PSIP Working Group D. Bryan Internet-Draft College of William and Mary and Intended status: Informational SIPeerior Technologies -Expires: December 3, 2007 P. Matthews +Expires: May 18, 2008 P. Matthews Avaya E. Shim Locus Telecommunications D. Willis Unaffiliated + November 15, 2007 + Concepts and Terminology for Peer to Peer SIP - draft-ietf-p2psip-concepts-00 + draft-ietf-p2psip-concepts-01 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 @@ -27,21 +29,21 @@ 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 December 3, 2007. + This Internet-Draft will expire on May 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines concepts and terminology for use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are @@ -72,42 +74,42 @@ 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. The Distributed Database Function . . . . . . . . . . . . 13 5.2. Using the Distributed Database Function . . . . . . . . . 15 5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18 5.4. Locating and Joining an Overlay . . . . . . . . . . . . . 20 5.5. Possible Client Behavior . . . . . . . . . . . . . . . . . 21 5.6. Interacting with non-P2PSIP entities . . . . . . . . . . . 22 + 5.7. Architecture . . . . . . . . . . . . . . . . . . . . . . . 23 - 6. Additional Questions . . . . . . . . . . . . . . . . . . . . . 23 + 6. Additional Questions . . . . . . . . . . . . . . . . . . . . . 24 6.1. Selecting between Multiple Peers offering the Same - Service . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 6.2. Visibility of Messages to Intermediate Peers . . . . . . . 23 - 6.3. Using C/S SIP and P2PSIP Simultaneously in a Single UA . . 23 - 6.4. Clients, Peers, and Services . . . . . . . . . . . . . . . 24 - 6.5. Relationships of Domains to Overlays . . . . . . . . . . . 24 - 6.6. Protocol Layering . . . . . . . . . . . . . . . . . . . . 24 + Service . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 6.2. Visibility of Messages to Intermediate Peers . . . . . . . 24 + 6.3. Using C/S SIP and P2PSIP Simultaneously in a Single UA . . 25 + 6.4. Clients, Peers, and Services . . . . . . . . . . . . . . . 25 + 6.5. Relationships of Domains to Overlays . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 9. Changes in This Version . . . . . . . . . . . . . . . . . . . 25 + 9. Changes in This Version . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30 1. Background One of the fundamental problems in multimedia communication between Internet nodes is that of discovering the host at which a given user can be reached. In the Session Initiation Protocol (SIP) [RFC3261] this problem is expressed as the problem of mapping an Address of Record (AoR) for a user into one or more Contact URIs [RFC3986]. The AoR is a name for the user that is independent of the host or hosts @@ -136,21 +138,21 @@ concepts of such a peer-to-peer overlay, and lists the open questions that still need to be resolved. As the work proceeds, it is expected that this document will develop into a high-level architecture document for the solution. 2. High Level Description A P2PSIP Overlay is a collection of nodes organized in a peer-to-peer fashion for the purpose of enabling real-time communication using the Session Initiation Protocol (SIP). Collectively, the nodes in the - overlay provide a distributed mechanism for mapping names to network + overlay provide a distributed mechanism for mapping names to overlay locations. This provides for the mapping of Addresses of Record (AoRs) to Contact URIs, thereby providing the "location server" function of [RFC3261]. A P2PSIP Overlay also provides a transport function by which SIP messages can be transported between any two nodes in the overlay. A P2PSIP Overlay consists of one or more nodes called P2PSIP Peers. The peers in the overlay collectively run a distributed database algorithm. This distributed database algorithm allows data to be stored on peers and retrieved in an efficient manner. It may also @@ -256,22 +258,25 @@ This implies that Peer Protocol connections must be able to traverse NATs. It also means that the peers must collectively provide a distributed transport function that allows a peer to send a SIP message to any other peer in the overlay - without this function two peers in different IP address spaces might not be able to exchange SIP messages. 3. Reference Model The following diagram shows a P2PSIP Overlay consisting of a number - of P2PSIP Peers and one P2PSIP Client. It also shows an ordinary SIP - UA. + of P2PSIP Peers, one P2PSIP Client, and an ordinary SIP UA. It + illustrates a typical P2PSIP overlay but does not limit other + compositions or variations; for example, Proxy Peer P might also talk + to a ordinary SIP proxy as well. The figure is not intended to cover + all possible architecture variations in this document. --->PSTN +------+ N +------+ +---------+ / | | A | | | Gateway |-/ | UA |####T#####| UA |#####| Peer |######## | Peer | N | Peer | | G | # P2PSIP | E | A | F | +---------+ # Client | | T | | # Protocol +------+ N +------+ # | # A # | @@ -465,20 +470,24 @@ data for the overlay. P2PSIP Resource Record: A block of data, stored using distributed database mechanism of the P2PSIP Overlay, that includes information relevant to a specific resource. We presume that there may be multiple types of resource records. Some may hold data about Users, and others may hold data about Services, and the working group may define other types. The types, usages, and formats of the records are a question for future study. + P2PSIP Responsible Peer The Peer that is responsible for storing the + Resource Record for a Resource. In the literature, the term "Root + Peer" is also used for this concept. + P2PSIP Peer Protocol: The protocol spoken between P2PSIP Overlay peers to share information and organize the P2PSIP Overlay Network. P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients and P2PSIP Peers. It is used to store and retrieve information from the P2P Overlay. The nature of this protocol, and even its existence, is under discussion. However, if it exists, it has been agreed that the Client Protocol is a functional subset of the P2P Peer Protocol, but may differ in syntax and protocol @@ -944,20 +953,82 @@ these UAs into the distributed database, and retrieves contact information when proxying INVITE messages. Another example is a peer that has a fully-qualified domain name (FQDN) that matches the name of the overlay and acts as a SIP proxy for calls coming into the overlay. A SIP INVITE addressed to "user@overlay-name" arrives at the peer (using the mechanisms in [RFC3263]) and this peer then looks up the user in the distributed database and proxies the call onto it. +5.7. Architecture + + There has been much debate in the group over what an appropriate + architecture for P2PSIP should be. Currently, the group is + investigating architectures that involve a P2P layer that is distinct + from the applications that run on the overlay. + __________________________ + | | + | SIP, other apps... | + | ___________________| + | | P2P Layer | + |______|___________________| + | Transport Layer | + |__________________________| + + The P2P layer implements the Peer Protocol (and the Client Protocol, + if such a protocol exists). Applications access this P2P layer for + various overlay-related services. Applications are also free to + bypass this layer and access the existing transport layer protocols + (e.g., TCP, UDP, etc.) directly. + + A notable feature of this architecture is that it envisions the use + of protocols other than SIP in the overlay. Though the working group + is primarily focused on the use of SIP in peer-to-peer overlays, this + architecture envisions a future in which other protocols can play a + role. + + The group initially considered another architecture. In this + alternative architecture, the Peer Protocol was defined as an + extension to SIP. That is, that the necessary operations for forming + and maintaining the overlay and for storing and retrieving resource + records in the distributed database were defined as extensions to + SIP. Each peer in the overlay was viewed as a SIP proxy that would + forward the overlay maintenance and distributed database query + messages (expressed in SIP) on behalf of other peers. + [I-D.bryan-p2psip-dsip] presents a detailed design, and + [I-D.zangrilli-p2psip-whysip] argues for this general approach. + + This architecture was eventually rejected by the working group for + the following reasons: + + o The architecture was totally focused on SIP, and made it difficult + to use other protocols in the overlay. + + o In SIP, proxies are assumed to be trusted parties. Relying on the + peers to route the message as proxies exposes the SIP messages to + attacks from untrusted proxies that SIP's design does not + anticipate. A design that does not allow the peers to modify the + SIP message and ideally prevents them from reading it is + preferable. + + o SIP was seen as a "heavy-weight" protocol for this task. SIP uses + a text-based encoding which is very flexible, but leads to both + large messages and slow processing times at proxies. This was + seen to be a poor match for P2PSIP, where a distributed database + lookup operation requires O(log N) peers to receive, process and + forward the message. + + More discussion on this alternate approach and why it was rejected + can be found on the P2PSIP mailing list in a thread that started on + 20 March 2007. + 6. Additional Questions This section lists some additional questions that the proposed P2PSIP Working Group may need to consider in the process of defining the Peer and Client protocols. 6.1. Selecting between Multiple Peers offering the Same Service If a P2PSIP network contains two or more peers that offer the same service, then how does a peer or client that wishes to use that @@ -1018,48 +1089,20 @@ 2. Can there be names from one domain in more than a single overlay? If so, how do we route Client/Server SIP requests to the right overlay? 3. Can the domain of an AoR be in more than one overlay? 4. Should we have a "default overlay" to search for peers in many domains? -6.6. Protocol Layering - - It is possible to define the overlay operations as extensions to SIP - as proposed in [I-D.bryan-p2psip-dsip] or using a lower level - transport protocol (or distinct P2P protocol layer below SIP) as - described in [I-D.matthews-p2psip-hip-hop], [I-D.bryan-p2psip-reload] - and [I-D.marocco-p2psip-xpp-pcan]. Which is the better or more - appropriate model? It seems that this requires analysis along - several axes, presumably described below in descending order of - priority.: - - 1. Functionality: Which approach more completely meets the - functional requirements implicit in the conceptual model? - - 2. Simplicity: Ease of implementation. Which approach can be more - readily turned into running code? - - 3. Generality: Do we have a requirement to only provide P2P support - for SIP operations, or is it likely that other applications will - need this functionality? If we make SIP work for P2P, will this - increase the pressure on SIP to serve as a general transport - protocol because it solves the rendezvous problem using P2P, - despite the warnings of [RFC4485] about using SIP as a transport - protocol? - - 4. Efficiency: Which approach produces the lesser loading on the - transport layer, the peers themselves, and other infrastructure? - 7. Security Considerations Building a P2PSIP system has many security considerations, many of which we have only begun to consider. We anticipate that the protocol documents describing the actual protocols will deal more thoroughly with security topics. One critical security issue that will need to be addressed is providing for the privacy and integrity of SIP messages being routed by peer nodes, when those peer nodes might well be hostile. This is @@ -1129,57 +1172,64 @@ 11.2. Informative References [I-D.bryan-p2psip-dsip] Bryan, D., "dSIP: A P2P Approach to SIP Registration and Resource Location", draft-bryan-p2psip-dsip-00 (work in progress), February 2007. [I-D.bryan-p2psip-reload] Bryan, D., "REsource LOcation And Discovery (RELOAD)", - draft-bryan-p2psip-reload-00 (work in progress), - June 2007. + draft-bryan-p2psip-reload-01 (work in progress), + July 2007. [I-D.iab-nat-traversal-considerations] Rosenberg, J., "Considerations for Selection of Techniques for NAT Traversal", draft-iab-nat-traversal-considerations-00 (work in progress), October 2005. [I-D.ietf-behave-rfc3489bis] - Rosenberg, J., "Session Traversal Utilities for (NAT) - (STUN)", draft-ietf-behave-rfc3489bis-06 (work in - progress), March 2007. + Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for (NAT) (STUN)", + draft-ietf-behave-rfc3489bis-12 (work in progress), + November 2007. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", - draft-ietf-mmusic-ice-16 (work in progress), June 2007. + draft-ietf-mmusic-ice-19 (work in progress), October 2007. [I-D.ietf-sipping-nat-scenarios] Boulton, C., "Best Current Practices for NAT Traversal for - SIP", draft-ietf-sipping-nat-scenarios-06 (work in - progress), March 2007. + SIP", draft-ietf-sipping-nat-scenarios-07 (work in + progress), July 2007. [I-D.marocco-p2psip-xpp-pcan] Marocco, E. and E. Ivov, "XPP Extensions for Implementing a Passive P2PSIP Overlay Network based on the CAN Distributed Hash Table", draft-marocco-p2psip-xpp-pcan-00 (work in progress), June 2007. [I-D.matthews-p2psip-hip-hop] Cooper, E., "A Distributed Transport Function in P2PSIP using HIP for Multi-Hop Overlay Routing", draft-matthews-p2psip-hip-hop-00 (work in progress), June 2007. + [I-D.zangrilli-p2psip-whysip] + Zangrilli, M. and B. Lowekamp, "Why SIP should be used for + encoding the P2PSIP Peer Protocol.", + draft-zangrilli-p2psip-whysip-00 (work in progress), + March 2007. + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)",