--- 1/draft-ietf-p2psip-sip-16.txt 2016-03-09 03:16:03.967854968 -0800 +++ 2/draft-ietf-p2psip-sip-17.txt 2016-03-09 03:16:04.007855961 -0800 @@ -1,26 +1,26 @@ P2PSIP C. Jennings Internet-Draft Cisco Intended status: Standards Track B. Lowekamp -Expires: July 3, 2016 Skype +Expires: September 10, 2016 Skype E. Rescorla RTFM, Inc. S. Baset H. Schulzrinne Columbia University T. Schmidt, Ed. HAW Hamburg - December 31, 2015 + March 9, 2016 A SIP Usage for RELOAD - draft-ietf-p2psip-sip-16 + draft-ietf-p2psip-sip-17 Abstract This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent Uris (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a peer, the AppAttach method @@ -35,25 +35,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on July 3, 2016. + This Internet-Draft will expire on September 10, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -71,63 +71,62 @@ it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Registering AORs in the Overlay . . . . . . . . . . . . . . . 5 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 6 - 3.3. Access Control . . . . . . . . . . . . . . . . . . . . . 9 + 3.3. Access Control . . . . . . . . . . . . . . . . . . . . . 8 3.4. Overlay Configuration Document Extension . . . . . . . . 9 - 4. Looking up an AOR . . . . . . . . . . . . . . . . . . . . . . 10 - 4.1. Finding a Route to an AOR . . . . . . . . . . . . . . . . 10 + 4. Looking up an AOR . . . . . . . . . . . . . . . . . . . . . . 11 + 4.1. Finding a Route to an AOR . . . . . . . . . . . . . . . . 11 4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . 11 - 5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 11 - 5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 11 + 5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 12 + 5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 12 5.2. Keeping a Connection Alive . . . . . . . . . . . . . . . 12 - 6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . 14 8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 14 8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . 14 - 8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 14 + 8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 15 8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . 15 8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 15 - 9.2. XML Name Space Registration . . . . . . . . . . . . . . . 15 + 9.2. XML Name Space Registration . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Third Party Registration . . . . . . . . . . . . . . 18 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18 B.1. Changes since draft-ietf-p2psip-sip-09 . . . . . . . . . 18 B.2. Changes since draft-ietf-p2psip-sip-08 . . . . . . . . . 18 - B.3. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . 18 + B.3. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . 19 B.4. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction - The REsource LOcation And Discovery (RELOAD) [RFC6940] specifies a - peer-to-peer (P2P) signaling protocol for the general use on the - Internet. This document defines a SIP Usage of RELOAD that allows - SIP [RFC3261] user agents (UAs) to establish peer-to-peer SIP (or - SIPS) sessions without the requirement for permanent proxy or - registration servers, e.g., a fully distributed telephony service. - In such a network, the RELOAD overlay itself performs the - registration and rendezvous functions ordinarily associated with such - servers. + REsource LOcation And Discovery (RELOAD) [RFC6940] specifies a peer- + to-peer (P2P) signaling protocol for the general use on the Internet. + This document defines a SIP Usage of RELOAD that allows SIP [RFC3261] + user agents (UAs) to establish peer-to-peer SIP (or SIPS) sessions + without the requirement for permanent proxy or registration servers, + e.g., a fully distributed telephony service. In such a network, the + RELOAD overlay itself performs the registration and rendezvous + functions ordinarily associated with such servers. The SIP Usage involves two basic functions. Registration: SIP UAs can use the RELOAD data storage functionality to store a mapping from their address-of-record (AOR) to their Node-ID in the overlay, and to retrieve the Node-ID of other UAs. Rendezvous: Once a SIP UA has identified the Node-ID for an AOR it wishes to call, it can use the RELOAD message routing system to set up a direct connection for exchanging SIP messages. @@ -195,30 +194,29 @@ "bob@dht.example.com -> charlie@dht.example.com". When Alice wants to call Bob, she retrieves this mapping and can then fetch Charlie's AOR to retrieve his Node-ID. These mechanisms are described in Section 3. Alternatively, Globally Routable User Agent URIs (GRUUs) can be used for directly accessing peers. They are handled via a separate mechanism, as described in Section 6. The SIP Usage for RELOAD addresses a fully distributed deployment of - session-based services among overlay peers. Two opposite scenarios - of deploying P2P SIP services are in the focus of this document: A - highly regulated environment of a "single provider" that admits - parties using AORs with domains from controlled namespace(s), only, - and an open, multi-party infrastructure that liberally allows a - registration and rendezvous for various or any domain namespace. It - is noteworthy in this context that - in contrast to regular SIP - - domain names play no role in routing to a proxy server. Once - connectivity to an overlay is given, any name registration can be - technically processed. + session-based services among overlay peers. This RELOAD usage may be + relevant in a variety of environments, including a highly regulated + environment of a "single provider" that admits parties using AORs + with domains from controlled namespace(s) only, or an open, multi- + party infrastructure that liberally allows a registration and + rendezvous for various or any domain namespace. It is noteworthy in + this context that - in contrast to regular SIP - domain names play no + role in routing to a proxy server. Once connectivity to an overlay + is given, any name registration can be technically processed. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. We use the terminology and definitions from Concepts and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base Protocol [RFC6940] extensively in this document. @@ -246,21 +244,21 @@ A RELOAD overlay MAY restrict the storage of AORs. Namespaces (i.e., the right hand side of the AOR) that are supported for registration and lookup can be configured for each RELOAD deployment as described in Section 3.4. As a simple example, consider Alice with AOR "alice@dht.example.org" at Node-ID "1234". She might store the mapping "alice@dht.example.org -> 1234" telling anyone who wants to call her to contact node "1234". - RELOAD peers MAY store two kinds of SIP mappings, + RELOAD peers can store two kinds of SIP mappings, o from an AOR to a destination list (a single Node-ID is just a trivial destination list), or o from an AOR to another AOR. The meaning of the first kind of mapping is "in order to contact me, form a connection with this peer." The meaning of the second kind of mapping is "in order to contact me, dereference this AOR". The latter allows for forwarding. For instance, if Alice wants her calls @@ -307,37 +305,32 @@ the registration data o If the registration is of type "sip_registration_uri", then the contents are an opaque string containing the AOR as specified in Section 2. o If the registration is of type "sip_registration_route", then the contents are an opaque string containing the callee's contact preferences and a destination list for the peer. - The encoding of contact_prefs - the callee's contact preferences - - follows the media feature set syntax of [RFC2533] (see also - [RFC2738]). As an example, a voicemail server that is a UA that - supports audio and video media types and is not mobile would carry - the following feature set description in its contact_prefs attribute: - - (& (sip.audio=TRUE) - (sip.video=TRUE) - (sip.actor=msg-taker) - (sip.automata=TRUE) - (sip.mobility=fixed) - (| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS) - (sip.methods=ACK) (sip.methods=CANCEL))) + The callee expresses its capabilities within the contact preferences + as specified in [RFC3840]. It encodes a media feature set comprised + of its capabilities as a contact predicate, i.e., a string of feature + parameters that appear as part of the Contact header field. Feature + parameters are derived from the media feature set syntax of [RFC2533] + (see also [RFC2738]) as described in [RFC3840]. - A callee MAY indicate that it prefers contact via a particular SIP - scheme - SIP or SIPS - by using one of the following contact_prefs - attribute: + This encoding covers all SIP User Agent capabilities, as defined in + [RFC3840] and registered in the SIP feature tag registration tree. + In particular, a callee can indicate that it prefers contact via a + particular SIP scheme - SIP or SIPS - by using one of the following + contact_prefs attribute: (sip.schemes=SIP) (sip.schemes=SIPS) RELOAD explicitly supports multiple registrations for a single AOR. The registrations are stored in a Dictionary with Node-IDs as the dictionary keys. Consider, for instance, the case where Alice has two peers: o her desk phone (1234) @@ -395,62 +388,73 @@ 3.4. Overlay Configuration Document Extension The use of a SIP-enabled overlay MAY be restricted to users with AORs from specific domains. When deploying an overlay service, providers can decide about these use case scenarios by defining a set of namespaces for admissible domain names. This section extends the overlay configuration document by defining new elements for patterns that describe a corresponding domain name syntax. A RELOAD overlay can be configured to accept store requests for any - AOR, or to apply domain name restrictions. For the latter, an - enumeration of admissible domain names including wildcarded name - patterns of the following form MAY be configured. + AOR, or to apply domain name restrictions. To apply restrictions, + the overlay configuration document needs to contain a element. The element serves as a + container for zero to multiple sub-elements. A + element MAY be present if the "enable" attribute of its parent + element is set to true. Each element defines a pattern for + constructing admissible resource names. It is of type xsd:string and + interpreted as a regular expression according to "POSIX Extended + Regular Expression" (see the specifications in [IEEE-Posix]). + + Encoding of the domain name complies to the restricted ASCII + character set without character escaping as defined in Section 19.1 + of [RFC3261]. + + Inclusion of a element in an overlay + configuration document is OPTIONAL. If the element is not included, + the default behavior is to accept any AOR. If the element is + included and the "enable" attribute is not set or set to false, the + overlay MUST only accept AORs that match the domain name of the + overlay. If the element is included and the "enable" attribute is + set to true, the overlay MUST only accept AORs that match patterns + specified in the element. Example of Domain Patterns: dht\.example\.com - .*\.my\.name + .*\.my\.example In this example, any AOR will be accepted that is either of the form - @dht.example.com, or ends with the domain "my.name". When - restrictions apply and in the absence of domain patterns, the default - behavior is to accept only AORs that exactly match the domain name of - the overlay. Otherwise, i.e., when restrictions are not configured - (attribute enable not set), the default behavior is to accept any - AOR. In the absence of a element, implementors - SHOULD assume this default value. Encoding of the domain name - complies to the restricted ASCII character set without character - escaping as defined in Section 19.1 of [RFC3261]. + @dht.example.com, or ends with the domain "my.example". The element serves as a container for zero to multiple sub-elements. A element MAY be present if the "enable" attribute of its parent element is set to true. Each element defines a pattern for constructing admissible resource names. It is of type xsd:string and interpreted as a regular expression according to "POSIX Extended Regular Expression" (see the specifications in [IEEE-Posix]). The Relax NG Grammar for the AOR Domain Restriction reads: - + # AOR DOMAIN RESTRICTION URN SUB-NAMESPACE namespace sip = "urn:ietf:params:xml:ns:p2p:config-base:sip" - + # AOR DOMAIN RESTRICTION ELEMENT Kind-parameter &= element sip:domain-restriction { attribute enable { xsd:boolean } - + # PATTERN ELEMENT - element pattern { xsd:string }* + element sip:pattern { xsd:string }* }? 4. Looking up an AOR 4.1. Finding a Route to an AOR A RELOAD user, member of an overlay, who wishes to call another user with given AOR SHALL proceed in the following way. AOR is GRUU? If the AOR is a GRUU for this overlay, the callee can @@ -497,24 +501,25 @@ 5. Forming a Direct Connection 5.1. Setting Up a Connection Once the peer has translated the AOR into a set of destination lists, it then uses the overlay to route AppAttach messages to each of those peers. The "application" field MUST be either 5060 to indicate SIP or 5061 for using SIPS. If certificate-based authentication is in use, the responding peer MUST present a certificate with a Node-ID matching the terminal entry in the destination list. Otherwise, the - connection MUST NOT be used and closed. Note that it is possible - that the peers already have a RELOAD connection mutually established. - This MUST NOT be used for SIP messages unless it is a SIP connection. - A previously established SIP connection MAY be used for a new call. + connection MUST NOT be used and MUST be closed. Note that it is + possible that the peers already have a RELOAD connection mutually + established. This MUST NOT be used for SIP messages unless it is a + SIP connection. A previously established SIP connection MAY be used + for a new call. Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted SIP messages over the connection as in normal SIP. A caller MAY choose to contact the callee using SIP or secure SIPS, but SHOULD follow a preference indicated by the callee in its contact_prefs attribute (see Section 3.2). A callee MAY choose to listen on both SIP and SIPS ports and accept calls from either SIP scheme, or select a single one. However, a callee that decides to accept SIPS calls, only, SHOULD indicate its choice by setting the corresponding attribute in its contact_prefs. It is noteworthy that according to @@ -542,31 +547,30 @@ alive techniques in agreement with its transport binding as defined in Section 3.5 of [RFC5626]. 6. Using GRUUs Globally Routable User Agent Uris (GRUUs) [RFC5627] have been designed to allow direct routing without the indirection of a SIP proxy function. The concept is transferred to RELOAD overlays as follows. GRUUs in RELOAD are constructed by embedding a base64-encoded destination list in the gr URI parameter of the GRUU. - The base64 encoding is done with the alphabet specified in table 1 of [RFC4648] with the exception that ~ is used in place of =. Example of a RELOAD GRUU: alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~ GRUUs do not require to store data in the Overlay Instance. Rather when a peer needs to route a message to a GRUU in the same P2P overlay, it simply uses the destination list and connects to that - peer. Because a GRUU contains a destination list, it MAY have the + peer. Because a GRUU contains a destination list, it can have the same contents as a destination list stored elsewhere in the resource dictionary. Anonymous GRUUs [RFC5767] are constructed analogously, but require either that the enrollment server issues a different Node-ID for each anonymous GRUU required, or that a destination list be used that includes a peer that compresses the destination list to stop the Node-ID from being revealed. 7. SIP-REGISTRATION Kind Definition @@ -635,38 +639,39 @@ retarget all calls to some victim. This attack is common to SIP and difficult to ameliorate without requiring the target of a SIP registration to authorize all stores. The overhead of that requirement would be excessive and in addition there are good use cases for retargeting to a peer without its explicit cooperation. 8.2.3. Misuse of AORs A RELOAD overlay and enrollment service that liberally accept registrations for AORs of domain names unrelated to the overlay - instance and without further justification, eventually store presence + instance and without further authorisation, eventually store presence state for misused AORs. An attacker could hijack names, register a bogus presence and attract calls dedicated to a victim that resides within or outside the Overlay Instance. A hijacking of AORs can be mitigated by restricting the name spaces admissible in the Overlay Instance, or by additional verification actions of the enrollment service. To prevent an (exclusive) routing to a bogus registration, a caller can in addition query the DNS (or other discovery services at hand) to search for an alternative presence of the callee in another overlay or a normal SIP infrastructure. 8.2.4. Privacy Issues - All RELOAD SIP registration data is public. Methods of providing - location and identity privacy are still being studied. Location - privacy can be gained from using anonymous GRUUs. + All RELOAD SIP registration data is visible to all nodes in the + overlay. Methods of providing location and identity privacy are + still being studied. Location privacy can be gained from using + anonymous GRUUs. 9. IANA Considerations 9.1. Data Kind-ID IANA shall register the following code point in the "RELOAD Data Kind-ID" Registry (cf., [RFC6940]) to represent the SIP-REGISTRATION Kind, as described in Section 7. [NOTE TO IANA/RFC-EDITOR: Please replace RFC-AAAA with the RFC number for this specification in the following list.] @@ -690,22 +696,22 @@ 10. Acknowledgments This document was generated in parts from initial drafts and discussions in the early specification phase of the P2PSIP base protocol. Significant contributions (in alphabetical order) were from David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan Rosenberg, and Marcia Zangrilli, which is gratefully acknowledged. Additional thanks go to all those who helped with ideas, discussions, and reviews, in particular (in alphabetical order) Roland Bless, - Michael Chen, Marc Petit-Huguenin, Brian Rosen, and Matthias - Waehlisch. + Michael Chen, Alissa Cooper, Marc Petit-Huguenin, Brian Rosen, and + Matthias Waehlisch. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -725,54 +731,60 @@ . [RFC2738] Klyne, G., "Corrections to "A Syntax for Describing Media Feature Sets"", RFC 2738, DOI 10.17487/RFC2738, December 1999, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . + [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, + "Indicating User Agent Capabilities in the Session + Initiation Protocol (SIP)", RFC 3840, + DOI 10.17487/RFC3840, August 2004, + . + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, + . + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, . [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, . - [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data - Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, - . - [IEEE-Posix] "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 1-55937-255-9, January 1993. 11.2. Informative References [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", - draft-ietf-p2psip-concepts-07 (work in progress), May - 2015. + draft-ietf-p2psip-concepts-08 (work in progress), February + 2016. [RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent- Driven Privacy Mechanism for SIP", RFC 5767, DOI 10.17487/RFC5767, April 2010, . [I-D.ietf-p2psip-share] Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A Usage for Shared Resources in RELOAD (ShaRe)", draft-ietf- p2psip-share-07 (work in progress), November 2015.