< draft-ietf-dots-server-discovery-09.txt		draft-ietf-dots-server-discovery-10.txt >
	DOTS M. Boucadair		DOTS M. Boucadair
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track T. Reddy		Intended status: Standards Track T. Reddy
	Expires: July 12, 2020 McAfee		Expires: August 10, 2020 McAfee
	January 9, 2020		February 7, 2020
	Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent		Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent
	Discovery		Discovery
	draft-ietf-dots-server-discovery-09		draft-ietf-dots-server-discovery-10
	Abstract		Abstract
	It may not be possible for a network to determine the cause for an		It may not be possible for a network to determine the cause for an
	attack, but instead just realize that some resources seem to be under		attack, but instead just realize that some resources seem to be under
	attack. To fill that gap, Distributed-Denial-of-Service Open Threat		attack. To fill that gap, Distributed-Denial-of-Service Open Threat
	Signaling (DOTS) allows a network to inform a DOTS server that it is		Signaling (DOTS) allows a network to inform a DOTS server that it is
	under a potential attack so that appropriate mitigation actions are		under a potential attack so that appropriate mitigation actions are
	undertaken.		undertaken.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 12, 2020.		This Internet-Draft will expire on August 10, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 29 ¶		skipping to change at page 2, line 29 ¶
	5.1. DHCPv6 DOTS Options . . . . . . . . . . . . . . . . . . . 9		5.1. DHCPv6 DOTS Options . . . . . . . . . . . . . . . . . . . 9
	5.1.1. Format of DOTS Reference Identifier Option . . . . . 9		5.1.1. Format of DOTS Reference Identifier Option . . . . . 9
	5.1.2. Format of DOTS Address Option . . . . . . . . . . . . 10		5.1.2. Format of DOTS Address Option . . . . . . . . . . . . 10
	5.1.3. DHCPv6 Client Behavior . . . . . . . . . . . . . . . 10		5.1.3. DHCPv6 Client Behavior . . . . . . . . . . . . . . . 10
	5.2. DHCPv4 DOTS Options . . . . . . . . . . . . . . . . . . . 11		5.2. DHCPv4 DOTS Options . . . . . . . . . . . . . . . . . . . 11
	5.2.1. Format of DOTS Reference Identifier Option . . . . . 11		5.2.1. Format of DOTS Reference Identifier Option . . . . . 11
	5.2.2. Format of DOTS Address Option . . . . . . . . . . . . 12		5.2.2. Format of DOTS Address Option . . . . . . . . . . . . 12
	5.2.3. DHCPv4 Client Behavior . . . . . . . . . . . . . . . 13		5.2.3. DHCPv4 Client Behavior . . . . . . . . . . . . . . . 13
	6. Discovery using Service Resolution . . . . . . . . . . . . . 13		6. Discovery using Service Resolution . . . . . . . . . . . . . 13
	7. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 16		7. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	8.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 16		8.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.2. Service Resolution . . . . . . . . . . . . . . . . . . . 16		8.2. Service Resolution . . . . . . . . . . . . . . . . . . . 17
	8.3. DNS Service Discovery . . . . . . . . . . . . . . . . . . 17		8.3. DNS Service Discovery . . . . . . . . . . . . . . . . . . 17
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9.1. The Service Name and Transport Protocol Port Number		9.1. The Service Name and Transport Protocol Port Number
	Registry . . . . . . . . . . . . . . . . . . . . . . . . 17		Registry . . . . . . . . . . . . . . . . . . . . . . . . 18
	9.2. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 18		9.2. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 19
	9.3. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . 18		9.3. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . 19
	9.4. Application Service & Application Protocol Tags . . . . . 19		9.4. Application Service & Application Protocol Tags . . . . . 19
	9.4.1. DOTS Application Service Tag Registration . . . . . . 19		9.4.1. DOTS Application Service Tag Registration . . . . . . 19
	9.4.2. DOTS Call Home Application Service Tag Registration . 19		9.4.2. DOTS Call Home Application Service Tag Registration . 20
	9.4.3. signal.udp Application Protocol Tag Registration . . 20		9.4.3. signal.udp Application Protocol Tag Registration . . 20
	9.4.4. signal.tcp Application Protocol Tag Registration . . 20		9.4.4. signal.tcp Application Protocol Tag Registration . . 20
	9.4.5. data.tcp Application Protocol Tag Registration . . . 20		9.4.5. data.tcp Application Protocol Tag Registration . . . 20
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	12.1. Normative References . . . . . . . . . . . . . . . . . . 21		12.1. Normative References . . . . . . . . . . . . . . . . . . 21
	12.2. Informative References . . . . . . . . . . . . . . . . . 22		12.2. Informative References . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	DDoS Open Threat Signaling (DOTS) [I-D.ietf-dots-architecture]		DDoS Open Threat Signaling (DOTS) [I-D.ietf-dots-architecture]
	specifies an architecture, in which a DOTS client can inform a DOTS		specifies an architecture, in which a DOTS client can inform a DOTS
	server that the network is under a potential attack and that		server that the network is under a potential attack and that
	appropriate mitigation actions are required. Indeed, because the		appropriate mitigation actions are required. Indeed, because the
	lack of a common method to coordinate a real-time response among		lack of a common method to coordinate a real-time response among
	involved actors and network domains inhibits the effectiveness of		involved actors and network domains inhibits the effectiveness of
	DDoS attack mitigation, DOTS signal channel protocol		DDoS attack mitigation, DOTS signal channel protocol
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	[I-D.ietf-dots-signal-channel] to identify the IP address of the peer		[I-D.ietf-dots-signal-channel] to identify the IP address of the peer
	DOTS server (or Call Home DOTS client). For example:		DOTS server (or Call Home DOTS client). For example:
	Let's consider that the DOTS server is reachable at		Let's consider that the DOTS server is reachable at
	2001:db8:122:300::1 while the Call Home DOTS client is reachable		2001:db8:122:300::1 while the Call Home DOTS client is reachable
	at 2001:db8:122:300::2. The DHCP server will then return one DOTS		at 2001:db8:122:300::2. The DHCP server will then return one DOTS
	reference identifier and a list that includes both		reference identifier and a list that includes both
	2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP		2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP
	client. That list is passed to the DOTS client (or Call Home DOTS		client. That list is passed to the DOTS client (or Call Home DOTS
	server) which will try to establish connections to the addresses		server) which will try to establish connections to the addresses
	of that list and destination port number 4646 (or 4647). As a		of that list and destination port number TBD1 (or TBD2). As a
	result, the DOTS client (or Call Home DOTS server) will select		result, the DOTS client (or Call Home DOTS server) will select
	2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server (or		2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server (or
	Call Home DOTS client).		Call Home DOTS client).
	5.1. DHCPv6 DOTS Options		5.1. DHCPv6 DOTS Options
	5.1.1. Format of DOTS Reference Identifier Option		5.1.1. Format of DOTS Reference Identifier Option
	The DHCPv6 DOTS Reference Identifier option is used to configure a		The DHCPv6 DOTS Reference Identifier option is used to configure a
	name of the DOTS server (or the name of the Call Home DOTS client).		name of the DOTS server (or the name of the Call Home DOTS client).
	skipping to change at page 15, line 48 ¶		skipping to change at page 15, line 48 ¶
	Service Resolution		Service Resolution
	+-------+----------+-------------+------+		+-------+----------+-------------+------+
	| Order | Protocol | IP address | Port |		| Order | Protocol | IP address | Port |
	+-------+----------+-------------+------+		+-------+----------+-------------+------+
	| 1 | UDP | 2001:db8::2 | 6000 |		| 1 | UDP | 2001:db8::2 | 6000 |
	| 2 | TCP | 2001:db8::2 | 6001 |		| 2 | TCP | 2001:db8::2 | 6001 |
	+-------+----------+-------------+------+		+-------+----------+-------------+------+
	Table 2		Table 2
			Note that customized port numbers are used for the DOTS signal
			channel, DOTS data channel, and DOTS signal channel call home in the
			examples shown in Figures 8 and 9 for illustration purposes. If
			default port numbers are used in a deployment, the discovery
			procedure will return TBD1 (DOTS signal channel), 443 (DOTS data
			channel), and TBD2 (DOTS signal channel call home) as DOTS service
			port numbers.
	If no DOTS-specific S-NAPTR records can be retrieved, the discovery		If no DOTS-specific S-NAPTR records can be retrieved, the discovery
	procedure fails for this domain name (and the corresponding interface		procedure fails for this domain name (and the corresponding interface
	and IP protocol version). If more domain names are known, the		and IP protocol version). If more domain names are known, the
	discovery procedure MAY perform the corresponding S-NAPTR lookups		discovery procedure MAY perform the corresponding S-NAPTR lookups
	immediately. However, before retrying a lookup that has failed, a		immediately. However, before retrying a lookup that has failed, a
	DOTS client MUST wait a time period that is appropriate for the		DOTS client MUST wait a time period that is appropriate for the
	encountered error (e.g., NXDOMAIN, timeout, etc.).		encountered error (e.g., NXDOMAIN, timeout, etc.).
	7. DNS Service Discovery		7. DNS Service Discovery
	skipping to change at page 16, line 29 ¶		skipping to change at page 16, line 37 ¶
	The <Domain> portion specifies the DNS sub-domain where the service		The <Domain> portion specifies the DNS sub-domain where the service
	instance is registered. It may be "local.", indicating the mDNS		instance is registered. It may be "local.", indicating the mDNS
	local domain, or it may be a conventional domain name such as		local domain, or it may be a conventional domain name such as
	"example.com.".		"example.com.".
	The <Service> portion of the DOTS service instance name MUST be		The <Service> portion of the DOTS service instance name MUST be
	"_dots-signal._udp" or "_dots-signal._tcp" or "_dots-data._tcp" or		"_dots-signal._udp" or "_dots-signal._tcp" or "_dots-data._tcp" or
	"_dots-call-home._udp" or "_dots-call-home._tcp".		"_dots-call-home._udp" or "_dots-call-home._tcp".
			This document does not define any keys; the TXT record of a DNS-SD
			service is thus empty (Section 6 of [RFC6763]).
			Figure 10 depicts an excerpt of the DNS zone configuration file
			listing record examples to discover two DOTS signal channel servers.
			In this example, only UDP is supported as transport for the
			establishment of the DOTS signal channel.
			_dots-signal._udp.example.net. PTR a._dots-signal._udp.example.net.
			_dots-signal._udp.example.net. PTR b._dots-signal._udp.example.net.
			a._dots-signal._udp.example.net. SRV 0 0 4646 a.example.net.
			b._dots-signal._udp.example.net. SRV 0 0 4646 b.example.net.
			a._dots-signal._udp.example.net. TXT ""
			b._dots-signal._udp.example.net. TXT ""
			Figure 10: An Example of DNS-SD Records for the UDP DOTS Signal
			Channel involving Two Servers with the Same Priority.
	8. Security Considerations		8. Security Considerations
	DOTS-related security considerations are discussed in Section 4 of		DOTS-related security considerations are discussed in Section 4 of
	[I-D.ietf-dots-architecture]. As a reminder, DOTS agents must		[I-D.ietf-dots-architecture]. As a reminder, DOTS agents must
	authenticate each other using (D)TLS before a DOTS session is		authenticate each other using (D)TLS before a DOTS session is
	considered valid according to the [I-D.ietf-dots-signal-channel].		considered valid according to the [I-D.ietf-dots-signal-channel].
	8.1. DHCP		8.1. DHCP
	The security considerations in [RFC2131] and [RFC8415] are to be		The security considerations in [RFC2131] and [RFC8415] are to be
	skipping to change at page 19, line 27 ¶		skipping to change at page 19, line 46 ¶
	This document requests IANA to make the following allocations from		This document requests IANA to make the following allocations from
	the registries available at: https://www.iana.org/assignments/s-		the registries available at: https://www.iana.org/assignments/s-
	naptr-parameters/s-naptr-parameters.xhtml#s-naptr-parameters-1 for		naptr-parameters/s-naptr-parameters.xhtml#s-naptr-parameters-1 for
	Application Service Tags and https://www.iana.org/assignments/s-		Application Service Tags and https://www.iana.org/assignments/s-
	naptr-parameters/s-naptr-parameters.xhtml#s-naptr-parameters-2 for		naptr-parameters/s-naptr-parameters.xhtml#s-naptr-parameters-2 for
	Application Protocol Tags.		Application Protocol Tags.
	9.4.1. DOTS Application Service Tag Registration		9.4.1. DOTS Application Service Tag Registration
	o Application Protocol Tag: DOTS		o Application Service Tag: DOTS
	o Intended Usage: See Section 6		o Intended Usage: See Section 6
	o Security Considerations: See Section 8		o Security Considerations: See Section 8
	o Interoperability considerations: None		o Interoperability considerations: None
	o Relevant publications: This document		o Relevant publications: This document
	9.4.2. DOTS Call Home Application Service Tag Registration		9.4.2. DOTS Call Home Application Service Tag Registration
	o Application Protocol Tag: DOTS-CALL-HOME		o Application Service Tag: DOTS-CALL-HOME
	o Intended Usage: See Section 6		o Intended Usage: See Section 6
	o Security Considerations: See Section 8		o Security Considerations: See Section 8
	o Interoperability considerations: None		o Interoperability considerations: None
	o Relevant publications: This document		o Relevant publications: This document
	9.4.3. signal.udp Application Protocol Tag Registration		9.4.3. signal.udp Application Protocol Tag Registration
	skipping to change at page 22, line 27 ¶		skipping to change at page 22, line 45 ¶
	[I-D.ietf-anima-bootstrapping-keyinfra]		[I-D.ietf-anima-bootstrapping-keyinfra]
	Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,		Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
	and K. Watsen, "Bootstrapping Remote Secure Key		and K. Watsen, "Bootstrapping Remote Secure Key
	Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-		Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
	keyinfra-34 (work in progress), January 2020.		keyinfra-34 (work in progress), January 2020.
	[I-D.ietf-dots-architecture]		[I-D.ietf-dots-architecture]
	Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and		Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and
	R. Compton, "Distributed-Denial-of-Service Open Threat		R. Compton, "Distributed-Denial-of-Service Open Threat
	Signaling (DOTS) Architecture", draft-ietf-dots-		Signaling (DOTS) Architecture", draft-ietf-dots-
	architecture-14 (work in progress), May 2019.		architecture-16 (work in progress), January 2020.
	[I-D.ietf-dots-data-channel]		[I-D.ietf-dots-data-channel]
	Boucadair, M. and T. Reddy.K, "Distributed Denial-of-		Boucadair, M. and T. Reddy.K, "Distributed Denial-of-
	Service Open Threat Signaling (DOTS) Data Channel		Service Open Threat Signaling (DOTS) Data Channel
	Specification", draft-ietf-dots-data-channel-31 (work in		Specification", draft-ietf-dots-data-channel-31 (work in
	progress), July 2019.		progress), July 2019.
	[I-D.ietf-dots-multihoming]		[I-D.ietf-dots-multihoming]
	Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing		Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing
	Deployment Considerations for Distributed-Denial-of-		Deployment Considerations for Distributed-Denial-of-
	Service Open Threat Signaling (DOTS)", draft-ietf-dots-		Service Open Threat Signaling (DOTS)", draft-ietf-dots-
	multihoming-02 (work in progress), July 2019.		multihoming-03 (work in progress), January 2020.
	[I-D.ietf-dots-signal-call-home]		[I-D.ietf-dots-signal-call-home]
	Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed		Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed
	Denial-of-Service Open Threat Signaling (DOTS) Signal		Denial-of-Service Open Threat Signaling (DOTS) Signal
	Channel Call Home", draft-ietf-dots-signal-call-home-07		Channel Call Home", draft-ietf-dots-signal-call-home-07
	(work in progress), November 2019.		(work in progress), November 2019.
	[I-D.ietf-dots-signal-channel]		[I-D.ietf-dots-signal-channel]
	Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and		Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and
	N. Teague, "Distributed Denial-of-Service Open Threat		N. Teague, "Distributed Denial-of-Service Open Threat
End of changes. 16 change blocks.
	20 lines changed or deleted		45 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/