draft-ietf-p2psip-sip-21.txt		rfc7904.txt
	P2PSIP C. Jennings		Internet Engineering Task Force (IETF) C. Jennings
	Internet-Draft Cisco		Request for Comments: 7904 Cisco
	Intended status: Standards Track B. Lowekamp		Category: Standards Track B. Lowekamp
	Expires: October 29, 2016 Skype		ISSN: 2070-1721 Skype
	E. Rescorla		E. Rescorla
	RTFM, Inc.		RTFM, Inc.
	S. Baset		S. Baset
			IBM
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	T. Schmidt, Ed.		T. Schmidt, Ed.
	HAW Hamburg		HAW Hamburg
	April 27, 2016		October 2016
	A SIP Usage for RELOAD		A SIP Usage for REsource LOcation And Discovery (RELOAD)
	draft-ietf-p2psip-sip-21
	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 RELOAD AppAttach		overlay. After such initial contact of a Peer, the RELOAD AppAttach
	method is used to establish a direct connection between nodes through		method is used to establish a direct connection between nodes through
	which SIP messages are exchanged.		which SIP messages are exchanged.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	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		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on October 29, 2016.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7904.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	skipping to change at page 2, line 34 ¶		skipping to change at page 3, line 7 ¶
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		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 . . . . . . . . . . . . . . . . . . . . . 6		3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Access Control . . . . . . . . . . . . . . . . . . . . . 8		3.3. Access Control . . . . . . . . . . . . . . . . . . . . . 9
	3.4. Overlay Configuration Document Extension . . . . . . . . 9		3.4. Overlay Configuration Document Extension . . . . . . . . 10
	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 . . . . . . . . . . . . . . . . . . . . 12
	5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 11		5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 12
	5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 11		5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 12
	5.2. Keeping a Connection Alive . . . . . . . . . . . . . . . 12		5.2. Keeping a Connection Alive . . . . . . . . . . . . . . . 13
	6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 13		7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 14		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . 14		8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . 14
	8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 14		8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 15
	8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . 14		8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . 15
	8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 15		8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 15
	8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . 15		8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . 15
	8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . 15		8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . 16
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 15		9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 16
	9.2. XML Name Space Registration . . . . . . . . . . . . . . . 16		9.2. XML Namespace Registration . . . . . . . . . . . . . . . 16
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		10.1. Normative References . . . . . . . . . . . . . . . . . . 16
	11.1. Normative References . . . . . . . . . . . . . . . . . . 16		10.2. Informative References . . . . . . . . . . . . . . . . . 18
	11.2. Informative References . . . . . . . . . . . . . . . . . 18		Appendix A. Third-Party Registration . . . . . . . . . . . . . . 19
	Appendix A. Third Party Registration . . . . . . . . . . . . . . 18		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
	B.1. Changes since draft-ietf-p2psip-sip-09 . . . . . . . . . 19
	B.2. Changes since draft-ietf-p2psip-sip-08 . . . . . . . . . 19
	B.3. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . 19
	B.4. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	REsource LOcation And Discovery (RELOAD) [RFC6940] specifies a peer-		REsource LOcation And Discovery (RELOAD) [RFC6940] specifies a peer-
	to-peer (P2P) signaling protocol for the general use on the Internet.		to-peer (P2P) signaling protocol for general use on the Internet.
	This document defines a SIP Usage of RELOAD that allows SIP [RFC3261]		This document defines a SIP Usage of RELOAD that allows SIP [RFC3261]
	user agents (UAs) to establish peer-to-peer SIP (or SIPS) sessions		user agents (UAs) to establish peer-to-peer SIP (or SIPS) sessions
	without the requirement for permanent proxy or registration servers,		without the requirement for a permanent proxy or registration
	e.g., a fully distributed telephony service. This service		servers, e.g., a fully distributed telephony service. This service
	transparently supports SIP addressing including telephone numbers.		transparently supports SIP addressing including telephone numbers.
	In such a network, the RELOAD overlay itself performs the		In such a network, the RELOAD overlay itself performs the
	registration and rendezvous functions ordinarily associated with such		registration and rendezvous functions ordinarily associated with such
	servers.		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.
	Mappings are stored in the SipRegistration Resource Record defined in		Mappings are stored in the SipRegistration Resource Record defined in
	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 AOR to		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		his 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		2. Alice, operating Node-ID "5678", decides to call Bob. She
	retrieves Node-ID "1234" by performing a Fetch request on		retrieves 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		Peer (ID "1234"). Bob responds with his own AppAttach and they
	set up a direct connection, as shown in Figure 1. Note that		set up a direct connection, as shown in Figure 1. Note that
	mutual Interactive Connectivity Establishment (ICE) checks are		mutual Interactive Connectivity Establishment (ICE) checks are
	invoked automatically from AppAttach message exchange.		invoked automatically from the AppAttach message exchange.
	Overlay		Overlay
	Alice Peer1 ... PeerN Bob		Alice Peer1 ... PeerN Bob
	(5678) (1234)		(5678) (1234)
	-------------------------------------------------		-------------------------------------------------
	AppAttach ->		AppAttach ->
	AppAttach ->		AppAttach ->
	AppAttach ->		AppAttach ->
	AppAttach ->		AppAttach ->
	<- AppAttach		<- AppAttach
	skipping to change at page 4, line 42 ¶		skipping to change at page 5, line 25 ¶
	<- AppAttach		<- AppAttach
	<- AppAttach		<- AppAttach
	<------------------ ICE Checks ----------------->		<------------------ ICE Checks ----------------->
	INVITE ----------------------------------------->		INVITE ----------------------------------------->
	<--------------------------------------------- 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 the only role of RELOAD in this example
	up the direct SIP connection between Alice and Bob. As soon as the		is to set up the direct SIP connection between Alice and Bob. As
	ICE checks complete and the connection is established, ordinary SIP		soon as the ICE checks complete and the connection is established,
	or SIPS is used. In particular, the establishment of the media		ordinary SIP or SIPS is used. In particular, the establishment of
	channel for a phone call happens via the usual SIP mechanisms, and		the media channel for a phone call happens via the usual SIP
	RELOAD is not involved. Media never traverses the overlay. After		mechanisms, and RELOAD is not involved. Media never traverses the
	the successful exchange of SIP messages, call peers run ICE		overlay. After the successful exchange of SIP messages,
	connectivity checks for media.		communicating Peers run ICE 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.
	Alternatively, Globally Routable User Agent URIs (GRUUs) [RFC5627]		Alternatively, Globally Routable User Agent URIs (GRUUs) [RFC5627]
	can be used for directly accessing peers. They are handled via a		can be used for directly accessing Peers. They are handled via a
	separate mechanism, as described in Section 6.		separate mechanism, as described in Section 6.
			Concepts used in this document can be extended to include tel URIs
			[RFC3966], but this will require further specifications to ensure
			semantic interoperability of implementations.
	The SIP Usage for RELOAD addresses a fully distributed deployment of		The SIP Usage for RELOAD addresses a fully distributed deployment of
	session-based services among overlay peers. This RELOAD usage may be		session-based services among overlay Peers. This RELOAD Usage may be
	relevant in a variety of environments, including a highly regulated		relevant in a variety of environments, including a tightly controlled
	environment of a "single provider" that admits parties using AORs		environment of a single provider that admits parties using AORs with
	with domains from controlled namespace(s) only, or an open, multi-		domains from controlled namespace(s) only, or an open, multi-party
	party infrastructure that liberally allows a registration and		infrastructure that liberally allows a registration and rendezvous
	rendezvous for various or any domain namespace. It is noteworthy in		for various or any domain namespace. It is noteworthy in this
	this context that - in contrast to regular SIP - domain names play no		context that -- in contrast to regular SIP -- domain names play no
	role in routing to a proxy server. Once connectivity to an overlay		role in routing to a proxy server. Once connectivity to an overlay
	is given, any name registration can be technically processed.		is given, the technology allows any name registration, possibly
			constrained by overlay domain restrictions.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	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 (P2PSIP)" [RFC7890] and the RELOAD Base Protocol
	Protocol [RFC6940] extensively in this document.		[RFC6940] extensively in this document.
	In addition, term definitions from SIP [RFC3261] apply to this memo.		In addition, terms defined by SIP [RFC3261] apply to this memo. The
	The term AOR is the SIP "Address of Record" used to identify a user		term AOR is the SIP "Address of Record" used to identify a user in
	in SIP. For example, alice@example.com could be the AOR for Alice.		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 [RFC5280]. It is worth noting		rfc822Name in the X.509 v3 certificates [RFC5280]. It is worth
	that SIP and SIPS are distinguished in P2PSIP by the Application-ID.		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 the user's AOR and its network		In ordinary SIP, a UA registers the user's AOR and its network
	location with a registrar. In RELOAD, this registrar function is		location with a registrar. In RELOAD, this registrar function is
	provided by the overlay as a whole. To register its location, a		provided by the overlay as a whole. To register its location, a
	RELOAD peer stores a SipRegistration Resource Record under its own		RELOAD peer stores a SipRegistration Resource Record under its own
	AOR using the SIP-REGISTRATION Kind, which is formally defined in		AOR using the SIP-REGISTRATION Kind, which is formally defined in
	Section 7. Note that the registration lifetime known from the		Section 7. Note that the registration lifetime known from the
	regular SIP REGISTER method is inherited from the lifetime attribute		regular SIP REGISTER method is inherited from the lifetime attribute
	of the basic RELOAD StoredData structure (see Section 7 in		of the basic RELOAD StoredData structure (see Section 7 in
	[RFC6940]).		[RFC6940]).
	A RELOAD overlay MAY restrict the storage of AORs. Namespaces (i.e.,		A RELOAD overlay MAY restrict the storage of AORs. Namespaces (i.e.,
	the right hand side of the AOR) that are supported for registration		the right-hand side of the AOR) that are supported for registration
	and lookup can be configured for each RELOAD deployment as described		and lookup can be configured for each RELOAD deployment as described
	in Section 3.4.		in Section 3.4.
	As a simple example, consider Alice with AOR "alice@dht.example.org"		As a simple example, consider Alice with an AOR
	at Node-ID "1234". She might store the mapping		"alice@dht.example.org" at Node-ID "1234". She might store the
	"alice@dht.example.org -> 1234" telling anyone who wants to call her		mapping "alice@dht.example.org -> 1234" telling anyone who wants to
	to contact node "1234".		call her to contact node "1234".
	RELOAD peers can 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		o from an AOR to a destination list (a single Node-ID is just a
	trivial destination list), or		trivial destination list), or
	o from an AOR to another AOR.		o from one AOR to another.
	The meaning of the first kind of mapping is "in order to contact me,		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		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 {
	(255) } SipRegistrationType;		sip_registration_uri(1),
			sip_registration_route(2),
			(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<3..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 Resource Record are:		The contents of the SipRegistration Resource Record are:
	type		type
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 29 ¶
	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 AOR.		contents are an opaque string containing the AOR.
	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 registrant's contact		contents are an opaque string containing the registrant's contact
	preferences and a destination list for the peer.		preferences and a destination list for the Peer.
	The callee expresses its capabilities within the contact preferences		The callee expresses its capabilities within the contact preferences
	as specified in [RFC3840]. It encodes a media feature set comprised		as specified in [RFC3840]. It encodes a media feature set comprised
	of its capabilities as a contact predicate, i.e., a string of feature		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 that appear as part of the Contact header field. Feature
	parameters are derived from the media feature set syntax of [RFC2533]		parameters are derived from the media feature set syntax of [RFC2533]
	(see also [RFC2738]) as described in [RFC3840].		(see also [RFC2738]) as described in [RFC3840].
	This encoding covers all SIP User Agent capabilities, as defined in		This encoding covers all SIP User Agent capabilities, as defined in
	[RFC3840] and registered in the SIP feature tag registration tree.		[RFC3840] and registered in the SIP feature tag registration tree.
	In particular, a callee can indicate that it prefers contact via a		In particular, a callee can indicate that it prefers contact via a
	particular SIP scheme - SIP or SIPS - by using one of the following		particular SIP scheme -- SIP or SIPS -- by using one of the following
	contact_prefs attribute:		contact_prefs attributes:
	(sip.schemes=SIP)		(sip.schemes=SIP)
	(sip.schemes=SIPS)		(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":
	o A SipRegistration of type "sip_registration_route" with dictionary		o a SipRegistration of type "sip_registration_route" with dictionary
	key "1234" and value "1234".		key "1234" and value "1234", both referring to Node-IDs
	o A SipRegistration of type "sip_registration_route" with dictionary		o a SipRegistration of type "sip_registration_route" with dictionary
	key "5678" and value "5678".		key "5678" and value "5678"
	Note that this structure explicitly allows one Node-ID to forward to		Note that this structure explicitly allows one Node-ID to forward to
	another Node-ID. For instance, Alice could set calls to her desk		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		phone to ring at her cell phone by storing a SipRegistration of type
	"sip_registration_route" with dictionary key "1234" and value "5678".		"sip_registration_route" with a dictionary key "1234" and a value
			"5678".
	3.3. Access Control		3.3. Access Control
	In order to prevent hijacking or other misuse, registrations are		In order to prevent hijacking or other misuse, registrations are
	subject to access control rules. Two kinds of restrictions apply:		subject to access control rules. Two kinds of restrictions apply:
	o A Store is permitted only for AORs with domain names that fall		o A Store is permitted only for AORs with domain names that fall
	into the namespaces supported by the RELOAD overlay instance.		into the namespaces supported by the RELOAD Overlay Instance.
	o Storing requests are performed according to the USER-NODE-MATCH		o Storing requests are performed according to the USER-NODE-MATCH
	access control policy of RELOAD.		access control policy of RELOAD.
	Before issuing a Store request to the overlay, any peer SHOULD verify		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		that the AOR of the request is a valid Resource Name with respect to
	its domain name and the namespaces defined in the overlay		its domain name and the namespaces defined in the overlay
	configuration document (see Section 3.4).		configuration document (see Section 3.4).
	Before a Store is permitted, the storing peer MUST check that:		Before a Store is permitted, the Storing Peer MUST check that:
	o The AOR of the request is a valid Resource Name with respect to		o The AOR of the request is a valid Resource Name with respect to
	the namespaces defined in the overlay configuration document.		the namespaces defined in the overlay configuration document.
	o The certificate contains a username that is a SIP AOR which hashes		o The certificate contains a username that is a SIP AOR that hashes
	to the Resource-ID it is being stored at.		to the Resource-ID it is being stored at.
	o The certificate contains a Node-ID that is the same as the		o The certificate contains a Node-ID that is the same as the
	dictionary key it is being stored at.		dictionary key it is being stored at.
	If any of these checks fail, the request MUST be rejected with an		If any of these checks fail, the request MUST be rejected with an
	Error_Forbidden error.		Error_Forbidden error.
	Note that these rules permit Alice to forward calls to Bob without		Note that these rules permit Alice to forward calls to Bob without
	his permission. However, they do not permit Alice to forward Bob's		his permission. However, they do not permit Alice to forward Bob's
	calls to her. See Section 8.2.2 for additional descriptions.		calls to her. See Section 8.2.2 for additional details.
	3.4. Overlay Configuration Document Extension		3.4. Overlay Configuration Document Extension
	The use of a SIP-enabled overlay MAY be restricted to users with AORs		The use of a SIP-enabled overlay MAY be restricted to users with AORs
	from specific domains. When deploying an overlay service, providers		from specific domains. When deploying an overlay service, providers
	can decide about these use case scenarios by defining a set of		can implement such restrictions by defining a set of namespaces for
	namespaces for admissible domain names. This section extends the		admissible domain names. This section extends the overlay
	overlay configuration document by defining new elements for patterns		configuration document by defining new elements for patterns that
	that describe a corresponding domain name syntax.		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. To apply restrictions,		AOR, or to apply domain name restrictions. To apply restrictions,
	the overlay configuration document needs to contain a <domain-		the overlay configuration document needs to contain a <domain-
	restrictions> element. The <domain-restrictions> element serves as a		restrictions> element. The <domain-restrictions> element serves as a
	container for zero to multiple <pattern> sub-elements. A <pattern>		container for zero to multiple <pattern> sub-elements. A <pattern>
	element MAY be present if the "enable" attribute of its parent		element MAY be present if the "enable" attribute of its parent
	element is set to true. Each <pattern> element defines a pattern for		element is set to true. Each <pattern> element defines a pattern for
	constructing admissible resource names. It is of type xsd:string and		constructing admissible resource names. It is of type xsd:string and
	interpreted as a regular expression according to "POSIX Extended		interpreted as a regular expression according to "POSIX Extended
	Regular Expression" (see the specifications in [IEEE-Posix]).		Regular Expression" (see the specifications in [IEEE-Posix]).
			Encoding of the domain name adheres to the restricted ASCII character
	Encoding of the domain name complies to the restricted ASCII		set without character escaping as defined in Section 19.1 of
	character set without character escaping as defined in Section 19.1		[RFC3261].
	of [RFC3261].
	Inclusion of a <domain-restrictions> element in an overlay		Inclusion of a <domain-restrictions> element in an overlay
	configuration document is OPTIONAL. If the element is not included,		configuration document is OPTIONAL. If the element is not included,
	the default behavior is to accept any AOR. If the element is		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		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 MUST only accept AORs that match the domain name of the
	overlay. If the element is included and the "enable" attribute is		overlay. If the element is included and the "enable" attribute is
	set to true, the overlay MUST only accept AORs that match patterns		set to true, the overlay MUST only accept AORs that match patterns
	specified in the <domain-restrictions> element.		specified in the <domain-restrictions> element.
	Example of Domain Patterns:		Example of Domain Patterns:
	dht\.example\.com		dht\.example\.com
	.*\.my\.example		.*\.my\.example
	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 ends with the domain "my.example".		<user>@dht.example.com, or ends with the domain "my.example".
	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 sip:pattern { xsd:string }*		element sip:pattern { xsd:string }*
	}?		}?
	4. Looking up an AOR		4. Looking Up an AOR
	4.1. Finding a Route to an AOR		4.1. Finding a Route to an AOR
	A RELOAD user, member of an overlay, who wishes to call another user		A RELOAD user, member of an overlay, who wishes to call another user
	with given AOR SHALL proceed in the following way.		with a given AOR SHALL proceed in the following way:
	AOR is GRUU? If the AOR is a GRUU for this overlay, the callee can		AOR is a GRUU? If the AOR is a GRUU for this overlay, the callee can
	be contacted directly as described in Section 6.		be contacted directly as described in Section 6.
	AOR domain is hosted in overlay? If the domain part of the AOR		AOR domain is hosted in overlay? If the domain part of the AOR
	matches a domain pattern configured in the overlay, the user can		matches a domain pattern configured in the overlay, the user can
	continue to resolve the AOR in this overlay. The user MAY choose		continue to resolve the AOR in this overlay. The user MAY choose
	to query the DNS service records to search for additional support		to query the DNS service records to search for additional support
	of this domain name.		of this domain name.
	AOR domain not supported by overlay? If the domain part of the AOR		AOR domain not supported by overlay? If the domain part of the AOR
	is not supported in the current overlay, the user might query the		is not supported in the current overlay, the user might query the
	skipping to change at page 11, line 27 ¶		skipping to change at page 12, line 8 ¶
	AOR inaccessible? If all of the above contact attempts fail, the		AOR inaccessible? If all of the above contact attempts fail, the
	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 or SIPS connections to the appropriate peers as described in		SIP or SIPS connections to the appropriate Peers as described in
	the following sections. If there are also external AORs, the		the following sections. If there are also external AORs, the
	peer follows the appropriate procedure for contacting them as		Peer follows the appropriate procedure for contacting them as
	well.		well.
	5. Forming a Direct Connection		5. Forming a Direct Connection
	5.1. Setting Up a Connection		5.1. Setting Up a 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 either 5060 to indicate SIP		Peers. The "application" field MUST be either 5060 to indicate SIP
	or 5061 for using SIPS. If certificate-based authentication is in		or 5061 to indicate SIPS. If certificate-based authentication is in
	use, the responding peer MUST present a certificate with a Node-ID		use, the responding Peer MUST present a certificate with a Node-ID
	matching the terminal entry in the destination list. Otherwise, the		matching the terminal entry in the destination list. Otherwise, the
	connection MUST NOT be used and MUST be closed. Note that it is		connection MUST NOT be used and MUST be closed. Note that it is
	possible that the peers already have a RELOAD connection mutually		possible that the Peers already have a RELOAD connection mutually
	established. This MUST NOT be used for SIP messages unless it is a		established. This MUST NOT be used for SIP messages unless it is a
	SIP connection. A previously established SIP connection MAY be used		SIP connection. A previously established SIP connection MAY be used
	for a new call.		for a new call.
	Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted		Once the AppAttach succeeds, the Peer sends plain or (D)TLS-encrypted
	SIP messages over the connection as in normal SIP. A caller MAY		SIP messages over the connection as in normal SIP. A caller MAY
	choose to contact the callee using SIP or SIPS, but SHOULD follow a		choose to contact the callee using SIP or SIPS, but SHOULD follow a
	preference indicated by the callee in its contact_prefs attribute		preference indicated by the callee in its contact_prefs attribute
	(see Section 3.2). A callee MAY choose to listen on both SIP and		(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		SIPS ports and accept calls from either SIP scheme, or select a
	single one. However, a callee that decides to accept SIPS calls,		single one. However, a callee that decides to accept SIPS calls
	only, SHOULD indicate its choice by setting the corresponding		only, SHOULD indicate its choice by setting the corresponding
	attribute in its contact_prefs. It is noteworthy that according to		attribute in its contact_prefs. It is noteworthy that, according to
	[RFC6940] all overlay links are built on (D)TLS secured transport.		[RFC6940], all overlay links are built on (D)TLS-secured transport.
	While hop-wise encrypted paths do not prevent the use of plain SIP,
	SIPS requires protection of all links that may include client links
	(if present) and endpoint certificates.
	SIP messages carry the SIP URIs of actual overlay endpoints (e.g.,		SIP messages carry the SIP URIs of actual overlay endpoints (e.g.,
	"sip:alice@dht.example.com") in the Via and Contact headers, while		"sip:alice@dht.example.com") in the Via and Contact headers, while
	the communication continues via the RELOAD connection. However, a UA		the communication continues via the RELOAD connection. However, a UA
	can redirect its communication path by setting an alternate Contact		can redirect its communication path by setting an alternate Contact
	header field like in ordinary SIP.		header field like in ordinary SIP.
	5.2. Keeping a Connection Alive		5.2. Keeping a Connection Alive
	In many cases, RELOAD connections will traverse NATs and Firewalls		In many cases, RELOAD connections established from ICE [RFC5245]
	that maintain states established from ICE [RFC5245] negotiations. It		negotiations will traverse stateful NATs and firewalls. It is the
	is the responsibility of the Peers to provide sufficiently frequent		responsibility of the Peers to send messages with a frequency
	traffic to keep NAT and Firewall states present and the connection		sufficient to maintain the necessary state in these NATs and
	alive. Keepalives are a mandatory component of ICE (see Section 10		firewalls and thus keep the connection alive. Keepalives are a
	of [RFC5245]) and no further operations are required. Applications		mandatory component of ICE (see Section 10 of [RFC5245]) and no
	that want to assure maintenance of sessions individually need to		further operations are required. Applications that want to assure
	follow regular SIP means. Accordingly, a SIP Peer MAY apply keep-		maintenance of sessions individually need to follow regular SIP
	alive techniques in agreement with its transport binding as defined		means. Accordingly, a SIP Peer MAY apply keep-alive techniques in
	in Section 3.5 of [RFC5626].		agreement with its transport binding as defined in Section 3.5 of
			[RFC5626].
	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 to a specific UA instance without		designed to allow direct routing to a specific UA instance without
	the need for dereferencing by a domain-specific SIP proxy function.		the need for dereferencing by a domain-specific SIP proxy function.
	The concept is transferred to RELOAD overlays as follows. GRUUs in		The concept is transferred to RELOAD overlays as follows. GRUUs in
	RELOAD are constructed by embedding a base64-encoded destination list		RELOAD are constructed by embedding a base64-encoded destination list
	in the "gr" URI parameter of the GRUU. The base64 encoding is done		in the "gr" URI parameter of the GRUU. The base64 encoding is done
	with the alphabet specified in table 1 of [RFC4648] with the		with the alphabet specified in Table 1 of [RFC4648] with the
	exception that ~ is used in place of =.		exception that "~" is used in place of "=".
	Example of a RELOAD GRUU:		Example of a RELOAD GRUU:
	alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~		alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~
	GRUUs do not require to store data in the Overlay Instance. Rather		GRUUs do not require storing data in the Overlay Instance. Rather,
	when a peer needs to route a message to a GRUU in the same P2P		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		overlay, it simply uses the destination list and connects to that
	peer. Because a GRUU contains a destination list, it can 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		same contents as a destination list stored elsewhere in the resource
	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 as specified in Section 2. The data stored is a		AOR of the user as specified in Section 2. The data stored is a
	SipRegistration, which can contain either another URI or a		SipRegistration, which can contain either another URI or a
	destination list to the peer which is acting for the user.		destination list to the Peer that 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 a
	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 X.509 v3 certificate. The
	does not include the scheme so that the "sip:" prefix needs to be		rfc822Name does not include the scheme so that the "sip:" prefix
	removed from the SIP AOR before matching. Escaped characters ('%'		needs to be removed from the SIP AOR before matching. Escaped
	encoding) in the SIP AOR also need to be decoded prior to matching		characters ('%' encoding) in the SIP AOR also need to be decoded
	(see [RFC3986]).		prior to matching (see [RFC3986]).
	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, containing one of two data types:
	sip_registration_uri		sip_registration_uri
	a URI which the user can be reached at.		A URI that 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 that can be used to reach the user's Peer.
	8. Security Considerations		8. Security Considerations
	8.1. RELOAD-Specific Issues		8.1. RELOAD-Specific Issues
	This Usage for RELOAD does not define new protocol elements or		This Usage for RELOAD does not define new protocol elements or
	operations. Hence no new threats arrive from message exchanges in		operations. Hence, no new threats arrive from message exchanges in
	RELOAD.		RELOAD.
	This document introduces an AOR domain restriction function that must		This document introduces an AOR domain restriction function that must
	be surveyed by the storing peer. A misconfigured or malicious peer		be compared against the registration attempt by the Storing Peer. A
	could cause frequent rejects of illegitimate storing requests.		misconfigured or malicious Peer could cause frequent rejects of
	However, domain name control relies on a lightweight pattern matching		illegitimate storing requests. However, domain name control relies
	and can be processed prior to validating certificates. Hence no		on a lightweight pattern matching and can be processed prior to
	extra burden is introduced for RELOAD peers beyond loads already		validating certificates. Hence, no extra burden is introduced for
	present in the base protocol.		RELOAD peers beyond loads already present in the base protocol.
	8.2. SIP-Specific Issues		8.2. SIP-Specific Issues
	8.2.1. Fork Explosion		8.2.1. Fork Explosion
	Because SIP includes a forking capability (the ability to retarget to		Because SIP includes a forking capability (the ability to retarget to
	multiple recipients), fork bombs (i.e., attacks using SIP forking to		multiple recipients), fork bombs (i.e., attacks using SIP forking to
	amplify the effect on the intended victims) are a potential DoS		amplify the effect on the intended victims) are a potential DoS
	concern. However, in the SIP usage of RELOAD, fork bombs are a much		concern. However, in the SIP Usage of RELOAD, fork bombs are a much
	lower concern than in a conventional SIP Proxy infrastructure,		lower concern than in a conventional SIP Proxy infrastructure,
	because the calling party is involved in each retargeting event. It		because the calling party is involved in each retargeting event. It
	can therefore directly measure the number of forks and throttle at		can therefore directly measure the number of forks and throttle at
	some reasonable number.		some reasonable number.
	8.2.2. Malicious Retargeting		8.2.2. Malicious Retargeting
	Another potential DoS attack is for the owner of an attractive AOR to		To launch a DoS attack, the owner of a popular AOR could retarget all
	retarget all calls to some victim. This attack is common to SIP and		calls to the victim. This attack is common to SIP and is difficult
	difficult to ameliorate without requiring the target of a SIP		to ameliorate without requiring the target of a SIP registration to
	registration to authorize all stores. The overhead of that		authorize all stores. The overhead of that requirement would be
	requirement would be excessive and in addition there are good use		excessive and, in addition, there are good use cases for retargeting
	cases for retargeting to a peer without its explicit cooperation.		to a Peer without its explicit cooperation.
	8.2.3. Misuse of AORs		8.2.3. Misuse of AORs
	A RELOAD overlay and enrollment service that liberally accept		A RELOAD overlay and enrollment service that liberally accepts
	registrations for AORs of domain names unrelated to the overlay		registrations for AORs of domain names unrelated to the overlay
	instance and without further authorisation, eventually store presence		instance and without further authorization could store presence state
	state for misused AORs. An attacker could hijack names, register a		for AORs without the consent of the owner of the AOR. An attacker
	bogus presence and attract calls dedicated to a victim that resides		could hijack names, register a bogus presence, and attract calls
	within or outside the Overlay Instance.		dedicated to a victim that resides within or outside the Overlay
			Instance.
	A hijacking of AORs can be mitigated by restricting the name spaces		A hijacking of AORs can be mitigated by restricting the name spaces
	admissible in the Overlay Instance, or by additional verification		admissible in the Overlay Instance, or by additional verification
	actions of the enrollment service. To prevent an (exclusive) routing		actions of the enrollment service. To prevent an (exclusive) routing
	to a bogus registration, a caller can in addition query the DNS (or		to a bogus registration, a caller can in addition query the DNS (or
	other discovery services at hand) to search for an alternative		other discovery services at hand), search for an alternative presence
	presence of the callee in another overlay or a normal SIP		of the callee in another overlay or a SIP infrastructure using
	infrastructure.		[RFC3263] for name resolution.
	8.2.4. Privacy Issues		8.2.4. Privacy Issues
	All RELOAD SIP registration data is visible to all nodes in the		All RELOAD SIP registration data is visible to all nodes in the
	overlay. Location privacy can be gained from using anonymous GRUUs.		overlay. Location privacy can be gained from using anonymous GRUUs.
	Methods of providing anonymity or deploying pseudonyms exist, but are		Methods of providing anonymity or deploying pseudonyms exist, but are
	beyond the scope of this document.		beyond the scope of this document.
	9. IANA Considerations		9. IANA Considerations
	9.1. Data Kind-ID		9.1. Data Kind-ID
	IANA shall register the following code point in the "RELOAD Data		IANA has registered the following code point in the "RELOAD Data
	Kind-ID" Registry (cf., [RFC6940]) to represent the SIP-REGISTRATION		Kind-ID" Registry (cf., [RFC6940]) to represent the SIP-REGISTRATION
	Kind, as described in Section 7. [NOTE TO IANA/RFC-EDITOR: Please		Kind, as described in Section 7.
	replace RFC-AAAA with the RFC number for this specification in the
	following list.]
	+---------------------+------------+----------+		+---------------------+------------+-----------+
	| Kind | Kind-ID | RFC |		| Kind | Kind-ID | Reference |
	+---------------------+------------+----------+		+---------------------+------------+-----------+
	| SIP-REGISTRATION | 1 | RFC-AAAA |		| SIP-REGISTRATION | 0x1 | RFC 7904 |
	+---------------------+------------+----------+		+---------------------+------------+-----------+
	9.2. XML Name Space Registration		9.2. XML Namespace Registration
	This document registers the following URI for the config XML		This document registers the following URI for the config XML
	namespace in the IETF XML registry defined in [RFC3688]		namespace in the IETF XML registry defined in [RFC3688]:
	URI: urn:ietf:params:xml:ns:p2p:config-base:sip		URI: urn:ietf:params:xml:ns:p2p:config-base:sip
	Registrant Contact: The IESG		Registrant Contact: The IESG
	XML: N/A, the requested URI is an XML namespace		XML: N/A; the requested URI is an XML namespace
	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, Alissa Cooper, Marc Petit-Huguenin, Brian Rosen, Meral
	Shirazipour, and Matthias Waehlisch.
	11. References		10. References
	11.1. Normative References		10.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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,		[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
	and H. Schulzrinne, "REsource LOcation And Discovery		and H. Schulzrinne, "REsource LOcation And Discovery
	(RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940,		(RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940,
	January 2014, <http://www.rfc-editor.org/info/rfc6940>.		January 2014, <http://www.rfc-editor.org/info/rfc6940>.
	skipping to change at page 18, line 6 ¶		skipping to change at page 18, line 17 ¶
	Initiation Protocol (SIP)", RFC 5626,		Initiation Protocol (SIP)", RFC 5626,
	DOI 10.17487/RFC5626, October 2009,		DOI 10.17487/RFC5626, October 2009,
	<http://www.rfc-editor.org/info/rfc5626>.		<http://www.rfc-editor.org/info/rfc5626>.
	[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, DOI 10.17487/RFC5627, October 2009,		(SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009,
	<http://www.rfc-editor.org/info/rfc5627>.		<http://www.rfc-editor.org/info/rfc5627>.
	[IEEE-Posix]		[IEEE-Posix]
	"IEEE Standard for Information Technology - Portable		IEEE, "International Standard - Information technology
	Operating System Interface (POSIX) - Part 2: Shell and		Portable Operating System Interface (POSIX) Base
	Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN		Specifications, Issue 7", ISO/IEC/IEEE 9945:2009,
	1-55937-255-9, January 1993.		DOI 10.1109/IEEESTD.2009.5393893, September 2009.
	11.2. Informative References		10.2. Informative References
	[I-D.ietf-p2psip-concepts]		[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
	Bryan, D., Matthews, P., Shim, E., Willis, D., and S.		Protocol (SIP): Locating SIP Servers", RFC 3263,
	Dawkins, "Concepts and Terminology for Peer to Peer SIP",		DOI 10.17487/RFC3263, June 2002,
	draft-ietf-p2psip-concepts-09 (work in progress), April		<http://www.rfc-editor.org/info/rfc3263>.
	2016.
			[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
			RFC 3966, DOI 10.17487/RFC3966, December 2004,
			<http://www.rfc-editor.org/info/rfc3966>.
			[RFC7890] Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
			Dawkins, "Concepts and Terminology for Peer-to-Peer SIP
			(P2PSIP)", RFC 7890, DOI 10.17487/RFC7890, June 2016,
			<http://www.rfc-editor.org/info/rfc7890>.
	[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,		Driven Privacy Mechanism for SIP", RFC 5767,
	DOI 10.17487/RFC5767, April 2010,		DOI 10.17487/RFC5767, April 2010,
	<http://www.rfc-editor.org/info/rfc5767>.		<http://www.rfc-editor.org/info/rfc5767>.
	[I-D.ietf-p2psip-share]		[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)", Work in
	Usage for Shared Resources in RELOAD (ShaRe)", draft-ietf-		Progress, draft-ietf-p2psip-share-08, March 2016.
	p2psip-share-08 (work in progress), March 2016.
	Appendix 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
	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.
	Appendix B. Change Log
	B.1. Changes since draft-ietf-p2psip-sip-09
	o Added subsection on keepalive
	o Updated references
	B.2. 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.3. Changes since draft-ietf-p2psip-sip-07
	o Cleared open issues
	o Clarified use cases after WG discussion
	o Added configuration document extensions for configurable domain
	names
	o Specified format of contact_prefs
	o Clarified routing to AORs
	o Extended security section
	o Added Appendix on Third Party Registration		Appendix A. Third-Party Registration
	o Added IANA code points		Non-peer-to-peer SIP defines third-party registration (e.g., an
			assistant acting for a manager or a changing set of users registering
			under a role-based AOR) in Section 10.2 of [RFC3261]. This is a
			REGISTER that 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.
	o Editorial polishing		Third-party registration can be implemented by using the extended
			access control mechanism USER-CHAIN-ACL defined in [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. This way, the SIP third-
			party registration functionality can be regained without weakening
			the security controls of RELOAD.
	o Updated and extended references		Acknowledgments
	B.4. Changes since draft-ietf-p2psip-sip-06		This document was generated in parts from initial drafts and
			discussions in the early specification phase of the P2PSIP base
			protocol. We gratefully acknowledge the significant contributions
			made by (in alphabetical order) David A. Bryan, James Deverick,
			Marcin Matuszewski, Jonathan Rosenberg, and Marcia Zangrilli.
	o Added Open Issue		Additional thanks go to all those who helped with ideas, discussions,
			and reviews, in particular (in alphabetical order) Roland Bless,
			Michael Chen, Alissa Cooper, Marc Petit-Huguenin, Brian Rosen, Meral
			Shirazipour, and Matthias Waehlisch.
	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		United States of America
	Phone: +1 408 421-9990		Phone: +1 408 421-9990
	Email: fluffy@cisco.com		Email: fluffy@cisco.com
	Bruce B. Lowekamp		Bruce B. Lowekamp
	Skype		Skype
	Palo Alto, CA		Palo Alto, CA
	USA		United States of America
	Email: bbl@lowekamp.net		Email: bbl@lowekamp.net
	Eric Rescorla		Eric Rescorla
	RTFM, Inc.		RTFM, Inc.
	2064 Edgewood Drive		2064 Edgewood Drive
	Palo Alto, CA 94303		Palo Alto, CA 94303
	USA		United States of America
	Phone: +1 650 678 2350		Phone: +1 650 678 2350
	Email: ekr@rtfm.com		Email: ekr@rtfm.com
	Salman A. Baset		Salman A. Baset
	Columbia University		IBM T. J. Watson Research Center
	1214 Amsterdam Avenue		1101 Kitchawan Road
	New York, NY		Yorktown Heights, NY 10598
	USA		United States of America
			Email: sabaset@us.ibm.com
	Email: salman@cs.columbia.edu
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	1214 Amsterdam Avenue		1214 Amsterdam Avenue
	New York, NY		New York, NY 10027
	USA		United States of America
	Email: hgs@cs.columbia.edu		Email: hgs@cs.columbia.edu
	Thomas C. Schmidt (editor)		Thomas C. Schmidt (editor)
	HAW Hamburg		HAW Hamburg
	Berliner Tor 7		Berliner Tor 7
	Hamburg 20099		Hamburg 20099
	Germany		Germany
	Email: t.schmidt@haw-hamburg.de		Email: t.schmidt@haw-hamburg.de
End of changes. 111 change blocks.
	311 lines changed or deleted		263 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/