draft-ietf-p2psip-sip-19.txt		draft-ietf-p2psip-sip-20.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 19, 2016 Skype		Expires: October 21, 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 17, 2016		April 19, 2016
	A SIP Usage for RELOAD		A SIP Usage for RELOAD
	draft-ietf-p2psip-sip-19		draft-ietf-p2psip-sip-20
	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 19, 2016.		This Internet-Draft will expire on October 21, 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 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	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
	6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 13		7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 13
	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 . . . . . . . . . . . . . . . . . . . 14
	8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . 14		8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . 14
	8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 14		8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 15
	8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . 15		8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . 15
	8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . 15		8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 15		9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 15
	9.2. XML Name Space Registration . . . . . . . . . . . . . . . 16		9.2. XML Name Space Registration . . . . . . . . . . . . . . . 16
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	11.1. Normative References . . . . . . . . . . . . . . . . . . 16		11.1. Normative References . . . . . . . . . . . . . . . . . . 16
	11.2. Informative References . . . . . . . . . . . . . . . . . 18		11.2. Informative References . . . . . . . . . . . . . . . . . 18
	Appendix A. Third Party Registration . . . . . . . . . . . . . . 18		Appendix A. Third Party Registration . . . . . . . . . . . . . . 18
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
	B.1. Changes since draft-ietf-p2psip-sip-09 . . . . . . . . . 18		B.1. Changes since draft-ietf-p2psip-sip-09 . . . . . . . . . 19
	B.2. Changes since draft-ietf-p2psip-sip-08 . . . . . . . . . 19		B.2. Changes since draft-ietf-p2psip-sip-08 . . . . . . . . . 19
	B.3. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . 19		B.3. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . 19
	B.4. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . 19		B.4. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		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. In such a network, the
	RELOAD overlay itself performs the registration and rendezvous		RELOAD overlay itself performs the registration and rendezvous
	skipping to change at page 11, line 12 ¶		skipping to change at page 11, line 12 ¶
	AOR is GRUU? If the AOR is a GRUU for this overlay, the callee can		AOR is 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 SHOULD query the		is not supported in the current overlay, the user might query the
	DNS (or other discovery services at hand) to search for an		DNS (or other discovery services at hand) to search for an
	alternative overlay that services the AOR under request.		alternative overlay that services the AOR under request.
	Alternatively, standard SIP procedures for contacting the callee		Alternatively, standard SIP procedures for contacting the callee
	SHOULD be used.		might be used.
	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
	skipping to change at page 12, line 15 ¶		skipping to change at page 12, line 15 ¶
	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 secure SIPS, but SHOULD
	follow a preference indicated by the callee in its contact_prefs		follow a preference indicated by the callee in its contact_prefs
	attribute (see Section 3.2). A callee MAY choose to listen on both		attribute (see Section 3.2). A callee MAY choose to listen on both
	SIP and SIPS ports and accept calls from either SIP schemes, or		SIP and SIPS ports and accept calls from either SIP scheme, or select
	select a single one. However, a callee that decides to accept SIPS		a single one. However, a callee that decides to accept SIPS calls,
	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 end-to-end protection that may include client links and		SIPS requires protection of all links that may include client links
	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
	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 will traverse NATs and Firewalls
	skipping to change at page 13, line 41 ¶		skipping to change at page 13, line 41 ¶
	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. Escaped characters ('%'		removed from the SIP AOR before matching. Escaped characters ('%'
	encoding) in the SIP AOR also need to be decoded prior to		encoding) in the SIP AOR also need to be decoded prior to matching
	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. 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
	skipping to change at page 14, line 37 ¶		skipping to change at page 14, line 37 ¶
	However, domain name control relies on a lightweight pattern matching		However, domain name control relies on a lightweight pattern matching
	and can be processed prior to validating certificates. Hence no		and can be processed prior to validating certificates. Hence no
	extra burden is introduced for RELOAD peers beyond loads already		extra burden is introduced for RELOAD peers beyond loads already
	present in the base protocol.		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 are a potential DoS concern.		multiple recipients), fork bombs (i.e., attacks using SIP forking to
	However, in the SIP usage of RELOAD, fork bombs are a much lower		amplify the effect on the intended victims) are a potential DoS
	concern than in a conventional SIP Proxy infrastructure, because the		concern. However, in the SIP usage of RELOAD, fork bombs are a much
	calling party is involved in each retargeting event. It can		lower concern than in a conventional SIP Proxy infrastructure,
	therefore directly measure the number of forks and throttle at some		because the calling party is involved in each retargeting event. It
	reasonable number.		can therefore directly measure the number of forks and throttle at
			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		Another potential DoS attack is for the owner of an attractive AOR to
	retarget all calls to some victim. This attack is common to SIP and		retarget all calls to some victim. This attack is common to SIP and
	difficult to ameliorate without requiring the target of a SIP		difficult to ameliorate without requiring the target of a SIP
	registration to authorize all stores. The overhead of that		registration to authorize all stores. The overhead of that
	requirement would be excessive and in addition there are good use		requirement would be excessive and in addition there are good use
	cases for retargeting to a peer without its explicit cooperation.		cases for retargeting to a peer without its explicit cooperation.
	skipping to change at page 17, line 19 ¶		skipping to change at page 17, line 19 ¶
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<http://www.rfc-editor.org/info/rfc3688>.		<http://www.rfc-editor.org/info/rfc3688>.
	[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,		[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
	"Indicating User Agent Capabilities in the Session		"Indicating User Agent Capabilities in the Session
	Initiation Protocol (SIP)", RFC 3840,		Initiation Protocol (SIP)", RFC 3840,
	DOI 10.17487/RFC3840, August 2004,		DOI 10.17487/RFC3840, August 2004,
	<http://www.rfc-editor.org/info/rfc3840>.		<http://www.rfc-editor.org/info/rfc3840>.
			[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
			Resource Identifier (URI): Generic Syntax", STD 66,
			RFC 3986, DOI 10.17487/RFC3986, January 2005,
			<http://www.rfc-editor.org/info/rfc3986>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<http://www.rfc-editor.org/info/rfc4648>.		<http://www.rfc-editor.org/info/rfc4648>.
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment		[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols", RFC 5245,		Traversal for Offer/Answer Protocols", RFC 5245,
	DOI 10.17487/RFC5245, April 2010,		DOI 10.17487/RFC5245, April 2010,
	<http://www.rfc-editor.org/info/rfc5245>.		<http://www.rfc-editor.org/info/rfc5245>.
End of changes. 14 change blocks.
	22 lines changed or deleted		28 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/