< draft-ietf-p2psip-sip-20.txt		draft-ietf-p2psip-sip-21.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: October 21, 2016 Skype		Expires: October 29, 2016 Skype
	E. Rescorla		E. Rescorla
	RTFM, Inc.		RTFM, Inc.
	S. Baset		S. Baset
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	T. Schmidt, Ed.		T. Schmidt, Ed.
	HAW Hamburg		HAW Hamburg
	April 19, 2016		April 27, 2016
	A SIP Usage for RELOAD		A SIP Usage for RELOAD
	draft-ietf-p2psip-sip-20		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
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 October 21, 2016.		This Internet-Draft will expire on October 29, 2016.
	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 36 ¶		skipping to change at page 2, line 36 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Registering AORs in the Overlay . . . . . . . . . . . . . . . 5		3. Registering AORs in the Overlay . . . . . . . . . . . . . . . 6
	3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 6		3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 6
	3.3. Access Control . . . . . . . . . . . . . . . . . . . . . 8		3.3. Access Control . . . . . . . . . . . . . . . . . . . . . 8
	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 . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. Finding a Route to an AOR . . . . . . . . . . . . . . . . 10		4.1. Finding a Route to an AOR . . . . . . . . . . . . . . . . 10
	4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . 11		4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . 11
	5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 11		5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 11
	5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 11		5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 11
	5.2. Keeping a Connection Alive . . . . . . . . . . . . . . . 12		5.2. Keeping a Connection Alive . . . . . . . . . . . . . . . 12
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	B.4. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . 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 the 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 permanent proxy or registration servers,
	e.g., a fully distributed telephony service. In such a network, the		e.g., a fully distributed telephony service. This service
	RELOAD overlay itself performs the registration and rendezvous		transparently supports SIP addressing including telephone numbers.
	functions ordinarily associated with such servers.		In such a network, the RELOAD overlay itself performs the
			registration and rendezvous functions ordinarily associated with such
			servers.
	The SIP Usage involves two basic functions.		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 5, line 14 ¶		skipping to change at page 5, line 16 ¶
	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) can be used		Alternatively, Globally Routable User Agent URIs (GRUUs) [RFC5627]
	for directly accessing peers. They are handled via a separate		can be used for directly accessing peers. They are handled via a
	mechanism, as described in Section 6.		separate mechanism, as described in Section 6.
	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 highly regulated
	environment of a "single provider" that admits parties using AORs		environment of a "single provider" that admits parties using AORs
	with domains from controlled namespace(s) only, or an open, multi-		with domains from controlled namespace(s) only, or an open, multi-
	party infrastructure that liberally allows a registration and		party infrastructure that liberally allows a registration and
	rendezvous for various or any domain namespace. It is noteworthy in		rendezvous for various or any domain namespace. It is noteworthy in
	this context that - in contrast to regular SIP - domain names play no		this 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
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 6 ¶
	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 [RFC5280]. It is worth noting		rfc822Name in the X509v3 certificates [RFC5280]. It is worth noting
	that SIP and SIPS are distinguished in P2PSIP by the Application-ID.		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 the user's AOR and its network
	registrar. In RELOAD, this registrar function is provided by the		location with a registrar. In RELOAD, this registrar function is
	overlay as a whole. To register its location, a RELOAD peer stores a		provided by the overlay as a whole. To register its location, a
	SipRegistration Resource Record under its own AOR using the SIP-		RELOAD peer stores a SipRegistration Resource Record under its own
	REGISTRATION Kind, which is formally defined in Section 7. Note that		AOR using the SIP-REGISTRATION Kind, which is formally defined in
	the registration lifetime known from the regular SIP REGISTER method		Section 7. Note that the registration lifetime known from the
	is inherited from the lifetime attribute of the basic RELOAD		regular SIP REGISTER method is inherited from the lifetime attribute
	StoredData structure (see Section 7 in [RFC6940]).		of the basic RELOAD StoredData structure (see Section 7 in
			[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 AOR "alice@dht.example.org"
	at Node-ID "1234". She might store the mapping		at Node-ID "1234". She might store the mapping
	"alice@dht.example.org -> 1234" telling anyone who wants to call her		"alice@dht.example.org -> 1234" telling anyone who wants to call her
	to contact node "1234".		to contact node "1234".
	skipping to change at page 8, line 6 ¶		skipping to change at page 8, line 6 ¶
	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 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 callee'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
	skipping to change at page 12, line 12 ¶		skipping to change at page 12, line 12 ¶
	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 secure SIPS, but SHOULD		choose to contact the callee using SIP or SIPS, but SHOULD follow a
	follow a preference indicated by the callee in its contact_prefs		preference indicated by the callee in its contact_prefs attribute
	attribute (see Section 3.2). A callee MAY choose to listen on both		(see Section 3.2). A callee MAY choose to listen on both SIP and
	SIP and SIPS ports and accept calls from either SIP scheme, or select		SIPS ports and accept calls from either SIP scheme, or select a
	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,		While hop-wise encrypted paths do not prevent the use of plain SIP,
	SIPS requires protection of all links that may include client links		SIPS requires protection of all links that may include client links
	(if present) and endpoint certificates.		(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
	skipping to change at page 12, line 46 ¶		skipping to change at page 12, line 46 ¶
	alive. Keepalives are a mandatory component of ICE (see Section 10		alive. Keepalives are a mandatory component of ICE (see Section 10
	of [RFC5245]) and no further operations are required. Applications		of [RFC5245]) and no further operations are required. Applications
	that want to assure maintenance of sessions individually need to		that want to assure maintenance of sessions individually need to
	follow regular SIP means. Accordingly, a SIP Peer MAY apply keep-		follow regular SIP means. Accordingly, a SIP Peer MAY apply keep-
	alive techniques in agreement with its transport binding as defined		alive techniques in agreement with its transport binding as defined
	in Section 3.5 of [RFC5626].		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 without the indirection of a SIP		designed to allow direct routing to a specific UA instance without
	proxy function. The concept is transferred to RELOAD overlays as		the need for dereferencing by a domain-specific SIP proxy function.
	follows. GRUUs in RELOAD are constructed by embedding a		The concept is transferred to RELOAD overlays as follows. GRUUs in
	base64-encoded destination list in the "gr" URI parameter of the		RELOAD are constructed by embedding a base64-encoded destination list
	GRUU. The base64 encoding is done with the alphabet specified in		in the "gr" URI parameter of the GRUU. The base64 encoding is done
	table 1 of [RFC4648] with the exception that ~ is used in place of =.		with the alphabet specified in table 1 of [RFC4648] with the
			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 to store 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.
	skipping to change at page 18, line 16 ¶		skipping to change at page 18, line 16 ¶
	"IEEE Standard for Information Technology - Portable		"IEEE Standard for Information Technology - Portable
	Operating System Interface (POSIX) - Part 2: Shell and		Operating System Interface (POSIX) - Part 2: Shell and
	Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN		Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN
	1-55937-255-9, January 1993.		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., Matthews, P., Shim, E., Willis, D., and S.		Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
	Dawkins, "Concepts and Terminology for Peer to Peer SIP",		Dawkins, "Concepts and Terminology for Peer to Peer SIP",
	draft-ietf-p2psip-concepts-08 (work in progress), February		draft-ietf-p2psip-concepts-09 (work in progress), April
	2016.		2016.
	[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]		[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)", draft-ietf-		Usage for Shared Resources in RELOAD (ShaRe)", draft-ietf-
End of changes. 13 change blocks.
	32 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/