draft-ietf-p2psip-sip-08.txt   draft-ietf-p2psip-sip-09.txt 
P2PSIP C. Jennings P2PSIP C. Jennings
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track B. Lowekamp Intended status: Standards Track B. Lowekamp
Expires: July 3, 2013 Skype Expires: August 29, 2013 Skype
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
S. Baset S. Baset
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
T C. Schmidt, Ed. T C. Schmidt, Ed.
HAW Hamburg HAW Hamburg
December 30, 2012 February 25, 2013
A SIP Usage for RELOAD A SIP Usage for RELOAD
draft-ietf-p2psip-sip-08 draft-ietf-p2psip-sip-09
Abstract Abstract
This document defines a SIP Usage for REsource LOcation And Discovery This document defines a SIP Usage for REsource LOcation And Discovery
(RELOAD). The SIP Usage provides the functionality of a SIP proxy or (RELOAD). The SIP Usage provides the functionality of a SIP proxy or
registrar in a fully-distributed system and includes a lookup service registrar in a fully-distributed system and includes a lookup service
for Address of Records (AoRs) stored in the overlay. It also defines for Address of Records (AORs) stored in the overlay. It also defines
Globally Routable User Agent Uris (GRUUs) that allow the Globally Routable User Agent Uris (GRUUs) that allow the
registrations to map an AoR to a specific node reachable through the registrations to map an AOR to a specific node reachable through the
overlay. After such initial contact of a peer, the AppAttach method overlay. After such initial contact of a peer, the AppAttach method
is used to establish a direct connection between nodes through which is used to establish a direct connection between nodes through which
SIP messages are exchanged. SIP messages are exchanged.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 3, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Registering AORs in the Overlay . . . . . . . . . . . . . . . 6 3. Registering AORs in the Overlay . . . . . . . . . . . . . . . 6
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Access Control . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Access Control . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Overlay Configuration Document Extension . . . . . . . . . 9 3.4. Overlay Configuration Document Extension . . . . . . . . . 9
4. Looking up an AOR . . . . . . . . . . . . . . . . . . . . . . 10 4. Looking up an AOR . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Finding a Route to an AOR . . . . . . . . . . . . . . . . 10 4.1. Finding a Route to an AOR . . . . . . . . . . . . . . . . 11
4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . . 11 4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . . 11
5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 11 5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 11
6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . . 12 7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . . 13 8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . . 13
8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 13 8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 14
8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . . 13 8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . . 14
8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 13 8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 14
8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . . 13 8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . . 14
8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . . 14 8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. XML Name Space Registration . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Third Party Registration . . . . . . . . . . . . . . 15 Appendix A. Third Party Registration . . . . . . . . . . . . . . 17
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17
B.1. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . . 16 B.1. Changes since draft-ietf-p2psip-sip-08 . . . . . . . . . . 17
B.2. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . . 16 B.2. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 B.3. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The REsource LOcation And Discovery (RELOAD) [I-D.ietf-p2psip-base] The REsource LOcation And Discovery (RELOAD) [I-D.ietf-p2psip-base]
specifies a peer-to-peer (P2P) signaling protocol for the general use specifies a peer-to-peer (P2P) signaling protocol for the general use
on the Internet. This document defines a SIP Usage of RELOAD that on the Internet. This document defines a SIP Usage of RELOAD that
allows SIP [RFC3261] user agents (UAs) to establish peer-to-peer SIP allows SIP [RFC3261] user agents (UAs) to establish peer-to-peer SIP
sessions without the requirement for permanent proxy or registration (or SIPS) sessions without the requirement for permanent proxy or
servers, , e.g., a fully distributed telephony service. In such a registration servers, e.g., a fully distributed telephony service.
network, the RELOAD overlay itself performs the registration and In such a network, the RELOAD overlay itself performs the
rendezvous functions ordinarily associated with such servers. registration and rendezvous functions ordinarily associated with such
servers.
The SIP Usage involves two basic functions. The SIP Usage involves two basic functions.
Registration: SIP UAs can use the RELOAD data storage functionality Registration: SIP UAs can use the RELOAD data storage functionality
to store a mapping from their address-of-record (AOR) to their 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. 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 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 wishes to call, it can use the RELOAD message routing system to
set up a direct connection for exchanging SIP messages. set up a direct connection for exchanging SIP messages.
skipping to change at page 4, line 36 skipping to change at page 4, line 37
this document. All operations required to perform a SIP registration this document. All operations required to perform a SIP registration
or rendezvous are standard RELOAD protocol methods. or rendezvous are standard RELOAD protocol methods.
For example, Bob registers his AOR, "bob@dht.example.com", for his For example, Bob registers his AOR, "bob@dht.example.com", for his
Node-ID "1234". When Alice wants to call Bob, she queries the Node-ID "1234". When Alice wants to call Bob, she queries the
overlay for "bob@dht.example.com" and receives Node-ID 1234 in overlay for "bob@dht.example.com" and receives Node-ID 1234 in
return. She then uses the overlay routing to establish a direct return. She then uses the overlay routing to establish a direct
connection with Bob and can directly transmit a standard SIP INVITE. connection with Bob and can directly transmit a standard SIP INVITE.
In detail, this works along the following steps. In detail, this works along the following steps.
1. Bob, operating Node-ID 1234, stores a mapping from his URI to his 1. Bob, operating Node-ID 1234, stores a mapping from his AOR to his
Node-ID in the overlay by applying a Store request for Node-ID in the overlay by applying a Store request for
"bob@dht.example.com -> 1234". "bob@dht.example.com -> 1234".
2. Alice, operating Node-ID 5678, decides to call Bob. She retrieves 2. Alice, operating Node-ID 5678, decides to call Bob. She retrieves
Node-ID "1234" by performing a Fetch request on Node-ID "1234" by performing a Fetch request on
"bob@dht.example.com". "bob@dht.example.com".
3. Alice uses the overlay to route an AppAttach message to Bob's 3. Alice uses the overlay to route an AppAttach message to Bob's
peer (ID 1234). Bob responds with his own AppAttach and they set peer (ID 1234). Bob responds with his own AppAttach and they set
up a direct connection, as shown in Figure 1. Note that mutual up a direct connection, as shown in Figure 1. Note that mutual
ICE checks are invoked automatically from AppAttach message ICE checks are invoked automatically from AppAttach message
exchange. exchange.
skipping to change at page 5, line 30 skipping to change at page 5, line 30
<--------------------------------------------- OK <--------------------------------------------- OK
ACK --------------------------------------------> ACK -------------------------------------------->
<------------ ICE Checks for media -------------> <------------ ICE Checks for media ------------->
<-------------------- RTP ----------------------> <-------------------- RTP ---------------------->
Figure 1: Connection setup in P2P SIP using the RELOAD overlay 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 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 up the direct SIP connection between Alice and Bob. As soon as the
ICE checks complete and the connection is established, ordinary SIP ICE checks complete and the connection is established, ordinary SIP
is used. In particular, the establishment of the media channel for a or SIPS is used. In particular, the establishment of the media
phone call happens via the usual SIP mechanisms, and RELOAD is not channel for a phone call happens via the usual SIP mechanisms, and
involved. Media never traverses the overlay. After the successful RELOAD is not involved. Media never traverses the overlay. After
exchange of SIP messages, call peers run ICE connectivity checks for the successful exchange of SIP messages, call peers run ICE
media. connectivity checks for media.
In addition to mappings from AORs to Node-IDs, the SIP Usage also In addition to mappings from AORs to Node-IDs, the SIP Usage also
allows mappings from AORs to other AORs. This enables an indirection allows mappings from AORs to other AORs. This enables an indirection
useful for call forwarding. For instance, if Bob wants his phone useful for call forwarding. For instance, if Bob wants his phone
calls temporarily forwarded to Charlie, he can store the mapping calls temporarily forwarded to Charlie, he can store the mapping
"bob@dht.example.com -> charlie@dht.example.com". When Alice wants "bob@dht.example.com -> charlie@dht.example.com". When Alice wants
to call Bob, she retrieves this mapping and can then fetch Charlie's to call Bob, she retrieves this mapping and can then fetch Charlie's
AOR to retrieve his Node-ID. These mechanisms are described in AOR to retrieve his Node-ID. These mechanisms are described in
Section 3. Section 3.
skipping to change at page 6, line 28 skipping to change at page 6, line 28
We use the terminology and definitions from Concepts and Terminology We use the terminology and definitions from Concepts and Terminology
for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base
Protocol [I-D.ietf-p2psip-base] extensively in this document. Protocol [I-D.ietf-p2psip-base] extensively in this document.
In addition, term definitions from SIP [RFC3261] apply to this memo. 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 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. 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 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 include the scheme (e.g sip:) as the AOR needs to match the
rfc822Name in the X509v3 certificates. rfc822Name in the X509v3 certificates. It is worth noting that SIP
and SIPS are distinguished in P2PSIP by the Application-ID.
3. Registering AORs in the Overlay 3. Registering AORs in the Overlay
3.1. Overview 3.1. Overview
In ordinary SIP, a UA registers its AOR and location with a In ordinary SIP, a UA registers its AOR and location with a
registrar. In RELOAD, this registrar function is provided by the registrar. In RELOAD, this registrar function is provided by the
overlay as a whole. To register its location, a RELOAD peer stores a overlay as a whole. To register its location, a RELOAD peer stores a
SipRegistration Resource Record under its own AOR using the SIP- SipRegistration Resource Record under its own AOR using the SIP-
REGISTRATION Kind, which is formally defined in Section 7. A RELOAD REGISTRATION Kind, which is formally defined in Section 7. A RELOAD
skipping to change at page 7, line 19 skipping to change at page 7, line 22
form a connection with this peer." The meaning of the second kind of form a connection with this peer." The meaning of the second kind of
mapping is "in order to contact me, dereference this AOR". The mapping is "in order to contact me, dereference this AOR". The
latter allows for forwarding. For instance, if Alice wants her calls latter allows for forwarding. For instance, if Alice wants her calls
to be forwarded to her secretary, Sam, she might insert the following to be forwarded to her secretary, Sam, she might insert the following
mapping "alice@dht.example.org -> sam@dht.example.org". mapping "alice@dht.example.org -> sam@dht.example.org".
3.2. Data Structure 3.2. Data Structure
This section defines the SipRegistration Resource Record as follows: This section defines the SipRegistration Resource Record as follows:
enum {sip_registration_uri (1), sip_registration_route (2), enum { sip_registration_uri(1), sip_registration_route(2),
(255)} SipRegistrationType; (255) } SipRegistrationType;
select (SipRegistration.type) { select (SipRegistration.type) {
case sip_registration_uri: case sip_registration_uri:
opaque uri<0..2^16-1>; opaque uri<0..2^16-1>;
case sip_registration_route: case sip_registration_route:
opaque contact_prefs<0..2^16-1>; opaque contact_prefs<0..2^16-1>;
Destination destination_list<0..2^16-1>; Destination destination_list<0..2^16-1>;
/* This type can be extended */ /* This type can be extended */
} SipRegistrationData; } SipRegistrationData;
struct { struct {
SipRegistrationType type; SipRegistrationType type;
uint16 length; uint16 length;
SipRegistrationData data; SipRegistrationData data;
} SipRegistration; } SipRegistration;
The contents of the SipRegistration PDU are: The contents of the SipRegistration Resource Record are:
type type
the type of the registration the type of the registration
length length
the length of the rest of the PDU the length of the rest of the PDU
data data
the registration data the registration data
o If the registration is of type "sip_registration_uri", then the o If the registration is of type "sip_registration_uri", then the
contents are an opaque string containing the URI. contents are an opaque string containing the URI.
o If the registration is of type "sip_registration_route", then the o If the registration is of type "sip_registration_route", then the
contents are an opaque string containing the callee's contact contents are an opaque string containing the callee's contact
preferences and a destination list for the peer. preferences and a destination list for the peer.
The encoding of contact_prefs - the callee's contact preferences - The encoding of contact_prefs - the callee's contact preferences -
follows the media feature set syntax of [RFC2533]. As an example, a follows the media feature set syntax of [RFC2533] (see also
voicemail server that is a UA that supports audio and video media [RFC2738]). As an example, a voicemail server that is a UA that
types and is not mobile would carry the following feature set supports audio and video media types and is not mobile would carry
description in its contact_prefs attribute: the following feature set description in its contact_prefs attribute:
(& (sip.audio=TRUE) (& (sip.audio=TRUE)
(sip.video=TRUE) (sip.video=TRUE)
(sip.actor=msg-taker) (sip.actor=msg-taker)
(sip.automata=TRUE) (sip.automata=TRUE)
(sip.mobility=fixed) (sip.mobility=fixed)
(| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS) (| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS)
(sip.methods=ACK) (sip.methods=CANCEL))) (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. RELOAD explicitly supports multiple registrations for a single AOR.
The registrations are stored in a Dictionary with Node-IDs as the The registrations are stored in a Dictionary with Node-IDs as the
dictionary keys. Consider, for instance, the case where Alice has dictionary keys. Consider, for instance, the case where Alice has
two peers: two peers:
o her desk phone (1234) o her desk phone (1234)
o her cell phone (5678) o her cell phone (5678)
Alice might store the following in the overlay at resource Alice might store the following in the overlay at resource
"alice@dht.example.com". "alice@dht.example.com".
skipping to change at page 9, line 48 skipping to change at page 10, line 9
namespaces for admissible domain names. This section extends the namespaces for admissible domain names. This section extends the
overlay configuration document by defining new elements for patterns overlay configuration document by defining new elements for patterns
that describe a corresponding domain name syntax. that describe a corresponding domain name syntax.
A RELOAD overlay can be configured to accept store requests for any A RELOAD overlay can be configured to accept store requests for any
AOR, or to apply domain name restrictions. For the latter, an AOR, or to apply domain name restrictions. For the latter, an
enumeration of admissible domain names including wildcarded name enumeration of admissible domain names including wildcarded name
patterns of the following form MAY be configured. patterns of the following form MAY be configured.
Example of Domain Patterns: Example of Domain Patterns:
dht.example.com dht\.example\.com
.*.my.name .*\.my\.name
In this example, any AOR will be accepted that is either of the form In this example, any AOR will be accepted that is either of the form
<user>@dht.example.com, or contains the domain suffix "my.name". <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].
When restrictions apply and in the absence of domain patterns, the The <domain-restrictions> element serves as a container for zero to
default behavior is to accept only AORs that exactly match the domain multiple <pattern> sub-elements. A <pattern> element MAY be present
name of the overlay. Otherwise, i.e., when restrictions are not if the "enable" attribute of its parent element is set to true. Each
configured (attribute enable not set), the default behavior is to <pattern> element defines a pattern for constructing admissible
accept any AOR. Encoding of the domain name complies to the resource names. It is of type xsd:string and interpreted as a
restricted ASCII character set without character escaping as defined regular expression according to "POSIX Extended Regular Expression"
in Section 19.1 of [RFC3261]. (see the specifications in [IEEE-Posix]).
The Relax NG Grammar for the AOR Domain Restriction reads: The Relax NG Grammar for the AOR Domain Restriction reads:
<!-- AOR DOMAIN RESTRICTION URN SUB-NAMESPACE --> <!-- AOR DOMAIN RESTRICTION URN SUB-NAMESPACE -->
namespace sip = "urn:ietf:params:xml:ns:p2p:config-base:sip" namespace sip = "urn:ietf:params:xml:ns:p2p:config-base:sip"
<!-- AOR DOMAIN RESTRICTION ELEMENT --> <!-- AOR DOMAIN RESTRICTION ELEMENT -->
kind-parameter &= element sip:domain-restriction { Kind-parameter &= element sip:domain-restriction {
attribute enable { xsd:boolean } attribute enable { xsd:boolean }
<!-- PATTERN ELEMENT --> <!-- PATTERN ELEMENT -->
element pattern { xsd:string }* element pattern { xsd:string }*
}? }?
4. Looking up an AOR 4. Looking up an AOR
skipping to change at page 11, line 16 skipping to change at page 11, line 36
call fails. call fails.
The procedures described above likewise apply when nodes are The procedures described above likewise apply when nodes are
simultaneously connected to several overlays. simultaneously connected to several overlays.
4.2. Resolving an AOR 4.2. Resolving an AOR
A RELOAD user that has discovered a route to an AOR in the current A RELOAD user that has discovered a route to an AOR in the current
overlay SHALL execute the following steps. overlay SHALL execute the following steps.
1. Perform a Fetch for kind SIP-REGISTRATION at the Resource-ID 1. Perform a Fetch for Kind SIP-REGISTRATION at the Resource-ID
corresponding to the AOR. This Fetch SHOULD NOT indicate any corresponding to the AOR. This Fetch SHOULD NOT indicate any
dictionary keys, so that it will fetch all the stored values. dictionary keys, so that it will fetch all the stored values.
2. If any of the results of the Fetch are non-GRUU AORs, then repeat 2. If any of the results of the Fetch are non-GRUU AORs, then repeat
step 1 for that AOR. step 1 for that AOR.
3. Once only GRUUs and destination lists remain, the peer removes 3. Once only GRUUs and destination lists remain, the peer removes
duplicate destination lists and GRUUs from the list and initiates duplicate destination lists and GRUUs from the list and initiates
SIP connections to the appropriate peers as described in the SIP or SIPS connections to the appropriate peers as described in
following sections. If there are also external AORs, the peer the following sections. If there are also external AORs, the
follows the appropriate procedure for contacting them as well. peer follows the appropriate procedure for contacting them as
well.
5. Forming a Direct Connection 5. Forming a Direct Connection
Once the peer has translated the AOR into a set of destination lists, 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 it then uses the overlay to route AppAttach messages to each of those
peers. The "application" field MUST be 5060 to indicate SIP. If peers. The "application" field MUST be either 5060 to indicate SIP
certificate-based authentication is in use, the responding peer MUST or 5061 for using SIPS. If certificate-based authentication is in
present a certificate with a Node-ID matching the terminal entry in use, the responding peer MUST present a certificate with a Node-ID
the route list. Note that it is possible that the peers already have matching the terminal entry in the route list. Note that it is
a RELOAD connection mutually established. This MUST NOT be used for possible that the peers already have a RELOAD connection mutually
SIP messages unless it is a SIP connection. A previously established established. This MUST NOT be used for SIP messages unless it is a
SIP connection MAY be used for a new call. Once the AppAttach SIP connection. A previously established SIP connection MAY be used
succeeds, the peer sends SIP messages over the connection as in for a new call.
normal SIP.
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.
6. Using GRUUs 6. Using GRUUs
Globally Routable User Agent Uris (GRUUs) [RFC5627] have been Globally Routable User Agent Uris (GRUUs) [RFC5627] have been
designed to allow direct routing without the indirection of a SIP designed to allow direct routing without the indirection of a SIP
proxy function. The concept is transferred to RELOAD overlays as proxy function. The concept is transferred to RELOAD overlays as
follows. GRUUs in RELOAD are constructed by embedding a base64- follows. GRUUs in RELOAD are constructed by embedding a base64-
encoded destination list in the gr URI parameter of the GRUU. The encoded destination list in the gr URI parameter of the GRUU. The
base64 encoding is done with the alphabet specified in table 1 of base64 encoding is done with the alphabet specified in table 1 of
[RFC4648] with the exception that ~ is used in place of =. [RFC4648] with the exception that ~ is used in place of =.
skipping to change at page 12, line 23 skipping to change at page 13, line 7
dictionary. dictionary.
Anonymous GRUUs [RFC5767] are constructed analogously, but require Anonymous GRUUs [RFC5767] are constructed analogously, but require
either that the enrollment server issues a different Node-ID for each either that the enrollment server issues a different Node-ID for each
anonymous GRUU required, or that a destination list be used that anonymous GRUU required, or that a destination list be used that
includes a peer that compresses the destination list to stop the includes a peer that compresses the destination list to stop the
Node-ID from being revealed. Node-ID from being revealed.
7. SIP-REGISTRATION Kind Definition 7. SIP-REGISTRATION Kind Definition
This section defines the SIP-REGISTRATION kind. This section defines the SIP-REGISTRATION Kind.
Name SIP-REGISTRATION Name SIP-REGISTRATION
Kind IDs The Resource Name for the SIP-REGISTRATION Kind-ID is the Kind IDs The Resource Name for the SIP-REGISTRATION Kind-ID is the
AOR of the user. The data stored is a SipRegistration, which can AOR of the user. The data stored is a SipRegistration, which can
contain either another URI or a destination list to the peer which contain either another URI or a destination list to the peer which
is acting for the user. is acting for the user.
Data Model The data model for the SIP-REGISTRATION Kind-ID is Data Model The data model for the SIP-REGISTRATION Kind-ID is
dictionary. The dictionary key is the Node-ID of the storing dictionary. The dictionary key is the Node-ID of the storing
peer. This allows each peer (presumably corresponding to a single peer. This allows each peer (presumably corresponding to a single
device) to store a single route mapping. device) to store a single route mapping.
Access Control USER-NODE-MATCH. Note that this matches the SIP AOR Access Control USER-NODE-MATCH. Note that this matches the SIP AOR
against the rfc822Name in the X509v3 certificate. The rfc822Name against the rfc822Name in the X509v3 certificate. The rfc822Name
does not include the scheme so that the "sip:" prefix needs to be does not include the scheme so that the "sip:" prefix needs to be
removed from the SIP AOR before matching. removed from the SIP AOR before matching.
Data stored under the SIP-REGISTRATION kind is of type Data stored under the SIP-REGISTRATION Kind is of type
SipRegistration. This comes in two varieties: SipRegistration. This comes in two varieties:
sip_registration_uri sip_registration_uri
a URI which the user can be reached at. a URI which the user can be reached at.
sip_registration_route sip_registration_route
a destination list which can be used to reach the user's peer. a destination list which can be used to reach the user's peer.
8. Security Considerations 8. Security Considerations
skipping to change at page 14, line 22 skipping to change at page 15, line 4
presence of the callee in another overlay or a normal SIP presence of the callee in another overlay or a normal SIP
infrastructure. infrastructure.
8.2.4. Privacy Issues 8.2.4. Privacy Issues
All RELOAD SIP registration data is public. Methods of providing All RELOAD SIP registration data is public. Methods of providing
location and identity privacy are still being studied. Location location and identity privacy are still being studied. Location
privacy can be gained from using anonymous GRUUs. privacy can be gained from using anonymous GRUUs.
9. IANA Considerations 9. IANA Considerations
9.1. Data Kind-ID
IANA shall register the following code point in the "RELOAD Data IANA shall register the following code point in the "RELOAD Data
Kind-ID" Registry (cf., [I-D.ietf-p2psip-base]) to represent the SIP- Kind-ID" Registry (cf., [I-D.ietf-p2psip-base]) to represent the SIP-
REGISTRATION kind, as described in Section 7. [NOTE TO IANA/ REGISTRATION Kind, as described in Section 7. [NOTE TO IANA/
RFC-EDITOR: Please replace RFC-AAAA with the RFC number for this RFC-EDITOR: Please replace RFC-AAAA with the RFC number for this
specification in the following list.] specification in the following list.]
+---------------------+------------+----------+ +---------------------+------------+----------+
| Kind | Kind-ID | RFC | | Kind | Kind-ID | RFC |
+---------------------+------------+----------+ +---------------------+------------+----------+
| SIP-REGISTRATION | 1 | RFC-AAAA | | SIP-REGISTRATION | 1 | RFC-AAAA |
+---------------------+------------+----------+ +---------------------+------------+----------+
9.2. XML Name Space Registration
This document registers the following URI for the config XML
namespace in the IETF XML registry defined in [RFC3688]
URI: urn:ietf:params:xml:ns:p2p:config-base:sip
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace
10. Acknowledgments 10. Acknowledgments
This document was generated in parts from initial drafts and This document was generated in parts from initial drafts and
discussions in the early specification phase of the P2PSIP base discussions in the early specification phase of the P2PSIP base
protocol. Significant contributions (in alphabetical order) were protocol. Significant contributions (in alphabetical order) were
from David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan from David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan
Rosenberg, and Marcia Zangrilli, which is gratefully acknowledged. Rosenberg, and Marcia Zangrilli, which is gratefully acknowledged.
Additional thanks go to all those who helped with ideas, discussions, Additional thanks go to all those who helped with ideas, discussions,
and reviews, in particular (in alphabetical order) Michael Chen, Marc and reviews, in particular (in alphabetical order) Michael Chen, Marc
skipping to change at page 15, line 4 skipping to change at page 15, line 40
discussions in the early specification phase of the P2PSIP base discussions in the early specification phase of the P2PSIP base
protocol. Significant contributions (in alphabetical order) were protocol. Significant contributions (in alphabetical order) were
from David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan from David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan
Rosenberg, and Marcia Zangrilli, which is gratefully acknowledged. Rosenberg, and Marcia Zangrilli, which is gratefully acknowledged.
Additional thanks go to all those who helped with ideas, discussions, Additional thanks go to all those who helped with ideas, discussions,
and reviews, in particular (in alphabetical order) Michael Chen, Marc and reviews, in particular (in alphabetical order) Michael Chen, Marc
Petit-Huguenin, Brian Rosen, and Matthias Waehlisch. Petit-Huguenin, Brian Rosen, and Matthias Waehlisch.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-p2psip-base] [I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-23 (work in Base Protocol", draft-ietf-p2psip-base-26 (work in
progress), November 2012. progress), February 2013.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", [RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets",
RFC 2533, March 1999. RFC 2533, March 1999.
[RFC2738] Klyne, G., "Corrections to "A Syntax for Describing Media
Feature Sets"", RFC 2738, December 1999.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009. (SIP)", RFC 5627, October 2009.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, 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 11.2. Informative References
[I-D.ietf-p2psip-concepts] [I-D.ietf-p2psip-concepts]
Bryan, D., Willis, D., Shim, E., Matthews, P., and S. Bryan, D., Willis, D., Shim, E., Matthews, P., and S.
Dawkins, "Concepts and Terminology for Peer to Peer SIP", Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-04 (work in progress), draft-ietf-p2psip-concepts-04 (work in progress),
October 2011. October 2011.
[RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent- [RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-
Driven Privacy Mechanism for SIP", RFC 5767, April 2010. Driven Privacy Mechanism for SIP", RFC 5767, April 2010.
[I-D.ietf-p2psip-share] [I-D.ietf-p2psip-share]
Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A
Usage for Shared Resources in RELOAD (ShaRe)", Usage for Shared Resources in RELOAD (ShaRe)",
draft-ietf-p2psip-share-00 (work in progress), draft-ietf-p2psip-share-01 (work in progress),
October 2012. February 2013.
Appendix A. Third Party Registration Appendix A. Third Party Registration
In traditional SIP, the mechanism of a third party registration In traditional SIP, the mechanism of a third party registration
(i.e., an assistant acting for a boss, changing users register a (i.e., an assistant acting for a boss, changing users register a
role-based AOR, ...) is defined in Section 10.2 of [RFC3261]. This 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 is a REGISTER which uses the URI of the third-party in its From
header and cannot be translated directly into a P2PSIP registration, header and cannot be translated directly into a P2PSIP registration,
because only the owner of the certificate can store a SIP- because only the owner of the certificate can store a SIP-
REGISTRATION in a RELOAD overlay. REGISTRATION in a RELOAD overlay.
A way to implement third party registration is by using the extended A way to implement third party registration is by using the extended
access control mechanism USER-CHAIN-ACL defined in access control mechanism USER-CHAIN-ACL defined in
[I-D.ietf-p2psip-share]. Creating a new kind "SIP-3P-REGISTRATION" [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 that is ruled by USER-CHAIN-ACL allows the owner of the certificate
to delegate the right for registration to individual third parties. to delegate the right for registration to individual third parties.
In this way, original SIP functionality can be regained without In this way, original SIP functionality can be regained without
weakening the security control of RELOAD. weakening the security control of RELOAD.
Appendix B. Change Log Appendix B. Change Log
B.1. Changes since draft-ietf-p2psip-sip-07 B.1. Changes since draft-ietf-p2psip-sip-08
o Added the handling of SIPS
o Specified use of Posix regular expressions in configuration
document
o Added IANA registration for namespace
o Editorial polishing
o Updated and extended references
B.2. Changes since draft-ietf-p2psip-sip-07
o Cleared open issues o Cleared open issues
o Clarified use cases after WG discussion o Clarified use cases after WG discussion
o Added configuration document extensions for configurable domain o Added configuration document extensions for configurable domain
names names
o Specified format of contact_prefs o Specified format of contact_prefs
o Clarified routing to AORs o Clarified routing to AORs
o Extended security section o Extended security section
o Added Appendix on Third Party Registration o Added Appendix on Third Party Registration
o Added IANA code points o Added IANA code points
o Editorial polishing o Editorial polishing
o Updated and extended references o Updated and extended references
B.2. Changes since draft-ietf-p2psip-sip-06 B.3. Changes since draft-ietf-p2psip-sip-06
o Added Open Issue o Added Open Issue
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
MS: SJC-21/2 MS: SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
USA USA
 End of changes. 40 change blocks. 
75 lines changed or deleted 136 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/