| P2PSIP | C. Jennings |
| Internet-Draft | Cisco |
| Intended status: Standards Track | B. B. Lowekamp |
| Expires: July 31, 2014 | Skype |
| E.K. Rescorla | |
| RTFM, Inc. | |
| S.A. Baset | |
| H.G. Schulzrinne | |
| Columbia University | |
| T. C. Schmidt, Ed. | |
| HAW Hamburg | |
| January 27, 2014 |
A SIP Usage for RELOAD
draft-ietf-p2psip-sip-12
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 is used to establish a direct connection between nodes through which SIP messages are exchanged.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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 31, 2014.
Copyright (c) 2014 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 described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
The REsource LOcation And Discovery (RELOAD) [I-D.ietf-p2psip-base] 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.
Mappings are stored in the SipRegistration Resource Record defined in this document. All operations required to perform a SIP registration or rendezvous are standard RELOAD protocol methods.
For example, Bob registers his AOR, "bob@dht.example.com", for his Node-ID "1234". When Alice wants to call Bob, she queries the overlay for "bob@dht.example.com" and receives Node-ID 1234 in return. She then uses the overlay routing to establish a direct connection with Bob and can directly transmit a standard SIP INVITE. In detail, this works along the following steps.
Overlay
Alice Peer1 ... PeerN Bob
(5678) (1234)
-------------------------------------------------
AppAttach ->
AppAttach ->
AppAttach ->
AppAttach ->
<- AppAttach
<- AppAttach
<- AppAttach
<- AppAttach
<------------------ ICE Checks ----------------->
INVITE ----------------------------------------->
<--------------------------------------------- OK
ACK -------------------------------------------->
<------------ ICE Checks for media ------------->
<-------------------- RTP ---------------------->
Figure 1: Connection setup in P2P SIP using the RELOAD overlay
It is important to note that here the only role of RELOAD is to set up the direct SIP connection between Alice and Bob. As soon as the ICE checks complete and the connection is established, ordinary SIP or SIPS is used. In particular, the establishment of the media channel for a phone call happens via the usual SIP mechanisms, and RELOAD is not involved. Media never traverses the overlay. After the successful exchange of SIP messages, call peers run ICE connectivity checks for media.
In addition to mappings from AORs to Node-IDs, the SIP Usage also allows mappings from AORs to other AORs. This enables an indirection useful for call forwarding. For instance, if Bob wants his phone calls temporarily forwarded to Charlie, he can store the mapping "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.
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 [I-D.ietf-p2psip-base] extensively in this document.
In addition, term definitions from SIP [RFC3261] apply to this memo. The term AOR is the SIP "Address of Record" used to identify a user in SIP. For example, alice@example.com could be the AOR for Alice. For the purposes of this specification, an AOR is considered not to include the scheme (e.g sip:) as the AOR needs to match the rfc822Name in the X509v3 certificates. It is worth noting that SIP and SIPS are distinguished in P2PSIP by the Application-ID.
In ordinary SIP, a UA registers its AOR and location with a registrar. In RELOAD, this registrar function is provided by the overlay as a whole. To register its location, a RELOAD peer stores a SipRegistration Resource Record under its own AOR using the SIP-REGISTRATION Kind, which is formally defined in Section 7. 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,
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 to be forwarded to her secretary, Sam, she might insert the following mapping "alice@dht.example.org -> sam@dht.example.org".
This section defines the SipRegistration Resource Record as follows:
enum { sip_registration_uri(1), sip_registration_route(2),
(255) } SipRegistrationType;
select (SipRegistration.type) {
case sip_registration_uri:
opaque uri<0..2^16-1>;
case sip_registration_route:
opaque contact_prefs<0..2^16-1>;
Destination destination_list<0..2^16-1>;
/* This type can be extended */
} SipRegistrationData;
struct {
SipRegistrationType type;
uint16 length;
SipRegistrationData data;
} SipRegistration;
The contents of the SipRegistration Resource Record are:
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)))
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:
(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:
Alice might store the following in the overlay at resource "alice@dht.example.com".
Note that this structure explicitly allows one Node-ID to forward to another Node-ID. For instance, Alice could set calls to her desk phone to ring at her cell phone by storing a SipRegistration of type "sip_registration_route" with dictionary key "1234" and value "5678".
In order to prevent hijacking or other misuse, registrations are subject to access control rules. Two kinds of restrictions apply:
Before issuing a Store request to the overlay, any peer SHOULD verify that the AOR of the request is a valid Resource Name with respect to its domain name and the namespaces defined in the overlay configuration document (see Section 3.4).
Before a Store is permitted, the storing peer MUST check that:
Note that these rules permit Alice to forward calls to Bob without his permission. However, they do not permit Alice to forward Bob's calls to her. See Section 8.2.2 for additional descriptions.
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.
Example of Domain Patterns:
dht\.example\.com
.*\.my\.name
In this example, any AOR will be accepted that is either of the form <user>@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 <domain-restrictions> 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].
The <domain-restrictions> element serves as a container for zero to multiple <pattern> sub-elements. A <pattern> element MAY be present if the "enable" attribute of its parent element is set to true. Each <pattern> 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 }*
}?
Figure 2
A RELOAD user, member of an overlay, who wishes to call another user with given AOR SHALL proceed in the following way.
The procedures described above likewise apply when nodes are simultaneously connected to several overlays.
A RELOAD user that has discovered a route to an AOR in the current overlay SHALL execute the following steps.
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 route list. 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.
In many cases, RELOAD connections will traverse NATs and Firewalls that maintain states established from ICE [RFC5245] negotiations. It is the responsiblity of the Peers to provide sufficiently frequent traffic to keep NAT and Firewall states present and the connection alive. Keepalives are a mandatory component of ICE (see Section 10 of [RFC5245]) and no further operations are required. Applications that want to assure maintanance of sessions individually need to follow regular SIP means. Accordingly, a SIP Peer MAY apply keep-alive techniques in agreement with its transport binding as defined in Section 3.5 of [RFC5626].
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 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.
This section defines the SIP-REGISTRATION Kind.
Data stored under the SIP-REGISTRATION Kind is of type SipRegistration. This comes in two varieties:
This Usage for RELOAD does not define new protocol elements or operations. Hence no new threats arrive from message exchanges in RELOAD.
This document introduces an AOR domain restriction function that must be surveyed by the storing peer. A misconfigured or malicious peer could cause frequent rejects of illegitimate storing requests. However, domain name control relies on a lightweight pattern matching and can be processed prior to validating certificates. Hence no extra burden is introduced for RELOAD peers beyond loads already present in the base protocol.
Because SIP includes a forking capability (the ability to retarget to multiple recipients), fork bombs are a potential DoS concern. However, in the SIP usage of RELOAD, fork bombs are a much lower concern than in a conventional SIP Proxy infrastructure, because the calling party is involved in each retargeting event. It can therefore directly measure the number of forks and throttle at some reasonable number.
Another potential DoS attack is for the owner of an attractive AOR to 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.
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 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.
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.
IANA shall register the following code point in the "RELOAD Data Kind-ID" Registry (cf., [I-D.ietf-p2psip-base]) 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.]
+---------------------+------------+----------+ | Kind | Kind-ID | RFC | +---------------------+------------+----------+ | SIP-REGISTRATION | 1 | RFC-AAAA | +---------------------+------------+----------+
This document registers the following URI for the config XML namespace in the IETF XML registry defined in [RFC3688]
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) Michael Chen, Marc Petit-Huguenin, Brian Rosen, and Matthias Waehlisch.
| [I-D.ietf-p2psip-concepts] | Bryan, D., Matthews, P., Shim, E., Willis, D. and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", Internet-Draft draft-ietf-p2psip-concepts-05, July 2013. |
| [RFC5767] | Munakata, M., Schubert, S. and T. Ohba, "User-Agent-Driven Privacy Mechanism for SIP", RFC 5767, April 2010. |
| [I-D.ietf-p2psip-share] | Knauf, A., Schmidt, T., Hege, G. and M. Waehlisch, "A Usage for Shared Resources in RELOAD (ShaRe)", Internet-Draft draft-ietf-p2psip-share-02, August 2013. |
In traditional SIP, the mechanism of a third party registration (i.e., an assistant acting for a boss, changing users register a role-based AOR, ...) is defined in Section 10.2 of [RFC3261]. This is a REGISTER which uses the URI of the third-party in its From header and cannot be translated directly into a P2PSIP registration, because only the owner of the certificate can store a SIP-REGISTRATION in a RELOAD overlay.
A way to implement third party registration is by using the extended access control mechanism USER-CHAIN-ACL defined in [I-D.ietf-p2psip-share]. Creating a new Kind "SIP-3P-REGISTRATION" that is ruled by USER-CHAIN-ACL allows the owner of the certificate to delegate the right for registration to individual third parties. In this way, original SIP functionality can be regained without weakening the security control of RELOAD.