draft-ietf-dots-server-discovery-12.txt   draft-ietf-dots-server-discovery-12.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: April 16, 2021 McAfee Expires: April 21, 2021 McAfee
October 13, 2020 October 18, 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-12 draft-ietf-dots-server-discovery-12
Abstract Abstract
This document specifies mechanisms to configure Distributed Denial of This document specifies mechanisms to configure Distributed Denial of
Service Open Threat Signaling (DOTS) clients with their DOTS servers. Service Open Threat Signaling (DOTS) clients with their DOTS servers.
The discovery procedure also covers the DOTS Signal Channel Call The discovery procedure also covers the DOTS Signal Channel Call
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 April 16, 2021. This Internet-Draft will expire on April 21, 2021.
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 15 skipping to change at page 2, line 15
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Why Multiple Discovery Mechanisms? . . . . . . . . . . . . . 5 3. Why Multiple Discovery Mechanisms? . . . . . . . . . . . . . 5
4. Unified DOTS Discovery Procedure . . . . . . . . . . . . . . 6 4. Unified DOTS Discovery Procedure . . . . . . . . . . . . . . 6
5. DHCP Options for DOTS Agent Discovery . . . . . . . . . . . . 8 5. DHCP Options for DOTS Agent Discovery . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . 17 7. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Service Resolution . . . . . . . . . . . . . . . . . . . 19 8.2. Service Resolution . . . . . . . . . . . . . . . . . . . 18
8.3. DNS Service Discovery . . . . . . . . . . . . . . . . . . 19 8.3. DNS Service Discovery . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. The Service Name and Transport Protocol Port Number 9.1. The Service Name and Transport Protocol Port Number
Registry . . . . . . . . . . . . . . . . . . . . . . . . 19 Registry . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 20 9.2. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 20
9.3. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . 21 9.3. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . 20
9.4. Application Service & Application Protocol Tags . . . . . 21 9.4. Application Service & Application Protocol Tags . . . . . 20
9.4.1. DOTS Application Service Tag Registration . . . . . . 21 9.4.1. DOTS Application Service Tag Registration . . . . . . 20
9.4.2. DOTS Call Home Application Service Tag Registration . 21 9.4.2. DOTS Call Home Application Service Tag Registration . 21
9.4.3. signal.udp Application Protocol Tag Registration . . 22 9.4.3. signal.udp Application Protocol Tag Registration . . 21
9.4.4. signal.tcp Application Protocol Tag Registration . . 22 9.4.4. signal.tcp Application Protocol Tag Registration . . 21
9.4.5. data.tcp Application Protocol Tag Registration . . . 22 9.4.5. data.tcp Application Protocol Tag Registration . . . 21
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
DDoS Open Threat Signaling (DOTS) [RFC8811] specifies an DDoS Open Threat Signaling (DOTS) [RFC8811] specifies an
architecture, in which a DOTS client can inform a DOTS server that architecture, in which a DOTS client can inform a DOTS server that
the network is under a potential attack and that appropriate the network is under a potential attack and that appropriate
mitigation actions are required. Indeed, because the lack of a mitigation actions are required. Indeed, because the lack of a
common method to coordinate a real-time response among involved common method to coordinate a real-time response among involved
actors and network domains inhibits the effectiveness of DDoS attack actors and network domains inhibits the effectiveness of DDoS attack
mitigation, the DOTS signal channel protocol [RFC8782] is meant to mitigation, the DOTS signal channel protocol [RFC8782] is meant to
carry requests for DDoS attack mitigation. This appraoch allows to carry requests for DDoS attack mitigation. This approach allows to
reduce the impact of an attack and leads to more efficient defensive reduce the impact of an attack and leads to more efficient defensive
actions in various deployment scenarios such as those discussed in actions in various deployment scenarios such as those discussed in
[I-D.ietf-dots-use-cases]. Moreover, DOTS clients can instruct a [I-D.ietf-dots-use-cases]. Moreover, DOTS clients can instruct a
DOTS server to install named filtering rules by means of the DOTS DOTS server to install named filtering rules by means of the DOTS
data channel protocol [RFC8782]. data channel protocol [RFC8782].
The basic high-level DOTS architecture is illustrated in Figure 1. The basic high-level DOTS architecture is illustrated in Figure 1.
+-----------+ +-------------+ +-----------+ +-------------+
| Mitigator | ~~~~~~~~~~ | DOTS Server | | Mitigator | ~~~~~~~~~~ | DOTS Server |
skipping to change at page 4, line 28 skipping to change at page 4, line 28
A DOTS agent may be used to establish base DOTS channels, DOTS Call A DOTS agent may be used to establish base DOTS channels, DOTS Call
Home, or both. This specification accommodates all these deployment Home, or both. This specification accommodates all these deployment
cases. cases.
Considerations for the selection of DOTS server(s) by multi-homed Considerations for the selection of DOTS server(s) by multi-homed
DOTS clients are out of scope; readers should refer to DOTS clients are out of scope; readers should refer to
[I-D.ietf-dots-multihoming] for more details. [I-D.ietf-dots-multihoming] for more details.
This document assumes that security credentials to authenticate DOTS This document assumes that security credentials to authenticate DOTS
server(s) are provisioned to a DOTS client using a mechanism such as server(s) are pre-provisioned to a DOTS client using a mechanism such
(but not limited to) those discussed in [RFC8572] or as (but not limited to) those discussed in [RFC8572] or
[I-D.ietf-anima-bootstrapping-keyinfra]. DOTS clients use those [I-D.ietf-anima-bootstrapping-keyinfra]. DOTS clients use those
credentials for authentication purposes following the rules credentials for authentication purposes following the rules
documented in [RFC8782]. documented in [RFC8782].
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
skipping to change at page 5, line 24 skipping to change at page 5, line 24
involve a CPE device. Multiple CPEs, connected to distinct involve a CPE device. Multiple CPEs, connected to distinct
network providers, may even be considered. It is intuitive to network providers, may even be considered. It is intuitive to
leverage existing mechanisms such as discovery using service leverage existing mechanisms such as discovery using service
resolution or DHCP to provision the CPE acting as a DOTS client resolution or DHCP to provision the CPE acting as a DOTS client
with the DOTS server(s). with the DOTS server(s).
o Resolving a DOTS server domain name offered by an upstream transit o Resolving a DOTS server domain name offered by an upstream transit
provider provisioned to a DOTS client into IP address(es) requires provider provisioned to a DOTS client into IP address(es) requires
the use of the appropriate DNS resolvers; otherwise, resolving the use of the appropriate DNS resolvers; otherwise, resolving
those names will fail. The use of protocols such as DHCP does those names will fail. The use of protocols such as DHCP does
allow to associate provisioned DOTS server domain names with a allow associating provisioned DOTS server domain names with a list
list of DNS servers to be used for name resolution. Furthermore, of DNS servers to be used for name resolution. Furthermore, DHCP
DHCP allows to directly provision IP addresses avoiding therefore allows directly provisioning IP addresses therefore avoiding the
the need for extra lookup delays. need for extra lookup delays.
o Some of the use cases may allow DOTS clients to have direct o Some of the use cases may allow DOTS clients to have direct
communications with upstream DOTS servers, that is, no DOTS communications with upstream DOTS servers, that is, no DOTS
gateway is involved. Leveraging existing protocol behaviors that gateway is involved. Leveraging existing protocol behaviors that
do not require specific features on the node embedding the DOTS do not require specific features on the node embedding the DOTS
client may ease DOTS deployment. Typically, the use of client may ease DOTS deployment. Typically, the use of
Straightforward-Naming Authority Pointer (S-NAPTR) lookups Straightforward-Naming Authority Pointer (S-NAPTR) lookups
[RFC3958] allows the DOTS server administrators to provision the [RFC3958] allows the DOTS server administrators to provision the
preferred DOTS transport protocol between the DOTS client and the preferred DOTS transport protocol between the DOTS client and the
DOTS server and allows the DOTS client to discover this DOTS server and allows the DOTS client to discover this
skipping to change at page 6, line 18 skipping to change at page 6, line 18
o Dynamic discovery using DHCP (Section 5). o Dynamic discovery using DHCP (Section 5).
o A resolution mechanism based on straightforward Naming Authority o A resolution mechanism based on straightforward Naming Authority
Pointer (S-NAPTR) resource records in the Domain Name System (DNS) Pointer (S-NAPTR) resource records in the Domain Name System (DNS)
(Section 6). (Section 6).
o DNS Service Discovery (Section 7). o DNS Service Discovery (Section 7).
4. Unified DOTS Discovery Procedure 4. Unified DOTS Discovery Procedure
A key point in the deployment of DOTS is the ability of network Operators will need a consistent set of ways in which DOTS clients
operators to configure DOTS clients with the correct DOTS server(s) can discover this information and a consistent priority among these
information consistently. To accomplish this, operators will need a options. If some devices prefer manual configuration over dynamic
consistent set of ways in which DOTS clients can discover this discovery, while others prefer dynamic discovery over manual
information, and a consistent priority among these options. If some configuration, the result will be a process of "whack-a-mole", where
devices prefer manual configuration over dynamic discovery, while the operator must find devices that are using the wrong DOTS
others prefer dynamic discovery over manual configuration, the result server(s), determine how to ensure the devices are configured
will be a process of "whack-a-mole", where the operator must find properly, and then reconfigure the device through the preferred
devices that are using the wrong DOTS server(s), determine how to method.
ensure the devices are configured properly, and then reconfigure the
device through the preferred method.
All DOTS clients MUST support at least one of the three mechanisms All DOTS clients MUST support at least one of the three mechanisms
below to determine a DOTS server list. All DOTS clients SHOULD below to determine a DOTS server list. All DOTS clients SHOULD
implement all three, or as many as are practical for any specific implement all three, or as many as are practical for any specific
device, of the following ways to discover DOTS servers in order to device, of the following ways to discover DOTS servers in order to
facilitate the deployment of DOTS in large scale environments. For facilitate the deployment of DOTS in large scale environments. For
example, a CPE will support the first two mechanisms, a host within a example, a CPE will support the first two mechanisms, a host within a
LAN will support the last two mechanisms, or an application server LAN will support the last two mechanisms, or an application server
will support a local configuration. More samples are discussed in will support a local configuration. More examples are discussed in
Section 3: Section 3:
1. Explicit configuration: 1. Explicit configuration:
* Local/Manual configuration: A DOTS client, will learn the DOTS * Local/Manual configuration: A DOTS client will learn the DOTS
server(s) by means of local or manual DOTS configuration server(s) by means of local or manual DOTS configuration
(i.e., DOTS servers configured at the system level). (i.e., DOTS servers configured at the system level).
Configuration discovered from a DOTS client application is Configuration discovered from a DOTS client application is
considered as local configuration. considered as local configuration.
An implementation may give the user an opportunity (e.g., by An implementation may give the user an opportunity (e.g., by
means of configuration file options or menu items) to specify means of configuration file options or menu items) to specify
DOTS server(s) for each address family. These may be DOTS server(s) for each address family. These may be
specified either as IP addresses or the DNS name of a DOTS specified either as IP addresses or the DNS name of a DOTS
server. When only DOTS server's IP addresses are configured, server. When only DOTS server IP addresses are configured, a
a reference identifier must also be configured for reference identifier must also be configured for
authentication purposes. authentication purposes.
* Automatic configuration (e.g., DHCP): The DOTS client attempts * Automatic configuration (e.g., DHCP): The DOTS client attempts
to discover DOTS server(s) names and/or addresses from DHCP, to discover DOTS server(s) names and/or addresses from DHCP,
as described in Section 5. as described in Section 5.
2. Service Resolution : The DOTS client attempts to discover DOTS 2. Service Resolution : The DOTS client attempts to discover DOTS
server name(s) using service resolution, as specified in server name(s) using service resolution, as specified in
Section 6. Section 6.
3. DNS SD: DNS Service Discovery. The DOTS client attempts to 3. DNS SD: DNS Service Discovery. The DOTS client attempts to
discover DOTS server name(s) using DNS service discovery, as discover DOTS server name(s) using DNS service discovery, as
specified in Section 7. specified in Section 7.
Some of these mechanisms imply the use of DNS to resolve the IP Some of these mechanisms imply the use of DNS to resolve the IP
address(es) of the DOTS server, while others imply an IP address of address(es) of the DOTS server, while others imply an IP address of
the relevant DOTS server is obtained directly. Implementation the relevant DOTS server is obtained directly. Implementation
options may vary on a per device basis, as some devices may not have options may vary on a per device basis, as some devices may not have
DNS capabilities and/or proper DNS configuration. DNS capabilities and/or suitable DNS configuration.
DOTS clients will prefer information received from the discovery DOTS clients will prefer information received from the discovery
methods in the order listed. methods in the order listed.
On hosts with more than one interface or address family (IPv4/IPv6), On hosts with more than one interface or address family (IPv4/IPv6),
the DOTS server discovery procedure has to be performed for each the DOTS server discovery procedure has to be performed for each
interface/address-family combination. A DOTS client may choose to interface/address-family combination. A DOTS client may choose to
perform the discovery procedure only for a desired interface/address perform the discovery procedure only for a desired interface/address
combination if the client does not wish to discover a DOTS server for combination if the client does not wish to discover a DOTS server for
all interface/address-family combinations. all interface/address-family combinations.
skipping to change at page 8, line 23 skipping to change at page 8, line 16
In order to allow for PKIX-based authentication between a DOTS client In order to allow for PKIX-based authentication between a DOTS client
and server while accommodating for the current best practices for and server while accommodating for the current best practices for
issuing certificates, this document allows for configuring names to issuing certificates, this document allows for configuring names to
DOTS clients. These names can be used for two purposes: to retrieve DOTS clients. These names can be used for two purposes: to retrieve
the list of IP addresses of a DOTS server or to be presented as a the list of IP addresses of a DOTS server or to be presented as a
reference identifier for authentication purposes. reference identifier for authentication purposes.
Defining the option to include a list of IP addresses would avoid a Defining the option to include a list of IP addresses would avoid a
dependency on an underlying name resolution, but that design requires dependency on an underlying name resolution, but that design requires
to also supply a name for PKIX-based authentication purposes. also supplying a name for PKIX-based authentication purposes.
Given that DOTS gateways can be involved in a DOTS session, a peer Given that DOTS gateways can be involved in a DOTS session, a peer
DOTS agent can be reachable using a link-local address. Such DOTS agent can be reachable using a link-local address. Such
addresses can also be discovered using the options defined in addresses can also be discovered using the options defined in
Section 5.1. Section 5.1.
The list of the IP addresses returned by DHCP servers is typically The list of the IP addresses returned by DHCP servers is typically
used to feed the DOTS server selection procedure including when DOTS used to feed the DOTS server selection procedure including when DOTS
agents are provided with primary and backup IP addresses of their agents are provided with primary and backup IP addresses of their
peer DOTS agents. An example of DOTS server selection procedure is peer DOTS agents. An example of DOTS server selection procedure is
specified in Section 4.3 of [RFC8782]. specified in Section 4.3 of [RFC8782].
The design assumes that the same peer DOTS agent is used for The design assumes that the same peer DOTS agent is used for
establishing both signal and data channels. For more customized establishing both signal and data channels. For more customized
configurations (e.g., transport-specific configuration, distinct DOTS configurations (e.g., transport-specific configuration, distinct DOTS
servers for the signal and the data channels), an operator can supply servers for the signal and the data channels), an operator can supply
only a DOTS reference identifier that will be then passed to the only a DOTS reference identifier that will be then passed to the
procedure described in Section 6. procedure described in Section 6.
The design allows to terminate the base DOTS channels and DOTS Call The design allows terminating the base DOTS channels and DOTS Call
Home on the same or distinct peer DOTS agents. If distinct peer DOTS Home on the same or distinct peer DOTS agents. If distinct peer DOTS
agents are deployed, the DHCP option can return, for example, a list agents are deployed, the DHCP option can return, for example, a list
of IP addresses to a requesting DOTS agent. This list includes the of IP addresses to a requesting DOTS agent. This list includes the
IP address to be used for the base DOTS channels and the IP address IP address to be used for the base DOTS channels and the IP address
for the DOTS Call Home. The DOTS client (or Call Home DOTS server) for the DOTS Call Home. The DOTS client (or Call Home DOTS server)
will then use the address selection procedure specified in will then use the address selection procedure specified in
Section 4.3 of [RFC8782] to identify the IP address of the peer DOTS Section 4.3 of [RFC8782] to identify the IP address of the peer DOTS
server (or Call Home DOTS client). For example: 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
skipping to change at page 11, line 17 skipping to change at page 11, line 9
DHCP clients MAY request options OPTION_V6_DOTS_RI and DHCP clients MAY request options OPTION_V6_DOTS_RI and
OPTION_V6_DOTS_ADDRESS, as defined in [RFC8415], Sections 18.2.1, OPTION_V6_DOTS_ADDRESS, as defined in [RFC8415], Sections 18.2.1,
18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. As a convenience to the 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. As a convenience to the
reader, it is mentioned here that the DHCP client includes the reader, it is mentioned here that the DHCP client includes the
requested option codes in the Option Request Option. requested option codes in the Option Request Option.
If the DHCP client receives more than one instance of If the DHCP client receives more than one instance of
OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use
only the first instance of that option. only the first instance of that option.
If the DHCP client receives both OPTION_V6_DOTS_RI and The DHCP client MUST silently discard multicast and host loopback
addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS.
If the DHCP client receives and validates both OPTION_V6_DOTS_RI and
OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as
reference identifier for authentication purposes (e.g., PKIX the reference identifier for authentication purposes (e.g., PKIX
[RFC6125]), while the addresses included in OPTION_V6_DOTS_ADDRESS [RFC6125]), while the valid addresses included in
are used to reach the peer DOTS agent. In other words, the name OPTION_V6_DOTS_ADDRESS are used to reach the peer DOTS agent. In
conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying other words, the name conveyed in OPTION_V6_DOTS_RI MUST NOT be
resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a passed to an underlying resolution library in the presence of valid
response. OPTION_V6_DOTS_ADDRESS in a response.
If the DHCP client receives OPTION_V6_DOTS_RI only, but If the DHCP client receives OPTION_V6_DOTS_RI only, but
OPTION_V6_DOTS_RI contains more than one name, as distinguished by OPTION_V6_DOTS_RI contains more than one name, as distinguished by
the presence of multiple root labels, the DHCP client MUST use only the presence of multiple root labels, the DHCP client MUST use only
the first name. Once the name is validated (Section 10 of the first name. Once the name is validated (Section 10 of
[RFC8415]), the name is passed to a name resolution library. [RFC8415]), the name is passed to a name resolution library.
Moreover, that name is also used as a reference identifier for Moreover, that name is also used as a reference identifier for
authentication purposes. authentication purposes.
If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the
address(es) included in OPTION_V6_DOTS_ADDRESS are used to reach the address(es) included in OPTION_V6_DOTS_ADDRESS are used to reach the
peer DOTS agent. In addition, these addresses can be used as peer DOTS agent. In addition, these addresses can be used as
identifiers for authentication. identifiers for authentication.
The DHCP client MUST silently discard multicast and host loopback
addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS.
5.2. DHCPv4 DOTS Options 5.2. DHCPv4 DOTS Options
5.2.1. Format of DOTS Reference Identifier Option 5.2.1. Format of DOTS Reference Identifier Option
The DHCPv4 [RFC2132] DOTS Reference Identifier option is used to The DHCPv4 [RFC2132] DOTS Reference Identifier option is used to
configure a name of the peer DOTS agent. The format of this option configure a name of the peer DOTS agent. The format of this option
is illustrated in Figure 6. is illustrated in Figure 6.
Code Length Peer DOTS agent name Code Length Peer DOTS agent name
+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+--
skipping to change at page 13, line 4 skipping to change at page 12, line 41
. ... . | . ... . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 7: DHCPv4 DOTS Address Option Figure 7: DHCPv4 DOTS Address Option
The fields of the option shown in Figure 7 are as follows: The fields of the option shown in Figure 7 are as follows:
o Code: OPTION_V4_DOTS_ADDRESS (TBA4, see Section 9.3). o Code: OPTION_V4_DOTS_ADDRESS (TBA4, see Section 9.3).
o Length: is set to 4*N, where N is the number of IPv4 addresses o Length: is set to 4*N, where N is the number of IPv4 addresses
included in the option. included in the option.
o DOTS IPv4 Address(es): Contains one or more IPv4 addresses of the o DOTS IPv4 Address(es): Contains one or more IPv4 addresses of the
peer DOTS agent to be used by a DOTS agent. peer DOTS agent to be used by a DOTS agent.
OPTION_V4_DOTS_ADDRESS is a concatenation-requiring option. As such, OPTION_V4_DOTS_ADDRESS is a concatenation-requiring option. As such,
the mechanism specified in [RFC3396] MUST be used if the mechanism specified in [RFC3396] MUST be used if
OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255 OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255
octets. octets.
5.2.3. DHCPv4 Client Behavior 5.2.3. DHCPv4 Client Behavior
To discover a peer DOTS agent, the DHCPv4 client MUST include both To discover a peer DOTS agent, the DHCPv4 client MUST include both
OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request
List Option [RFC2132]. List Option [RFC2132].
If the DHCP client receives more than one instance of If the DHCP client receives more than one instance of
OPTION_V4_DOTS_RI option, it MUST use only the first instance of that OPTION_V4_DOTS_RI option, it MUST use only the first instance of that
option. option.
If the DHCP client receives both OPTION_V4_DOTS_RI and The DHCP client MUST silently discard multicast and host loopback
addresses [RFC6890] conveyed in OPTION_V4_DOTS_ADDRESS.
If the DHCP client receives and validates both OPTION_V4_DOTS_RI and
OPTION_V4_DOTS_ADDRESS, the content of OPTION_V4_DOTS_RI is used as OPTION_V4_DOTS_ADDRESS, the content of OPTION_V4_DOTS_RI is used as
reference identifier for authentication purposes (e.g., PKIX the reference identifier for authentication purposes (e.g., PKIX
[RFC6125]), while the addresses included in OPTION_V4_DOTS_ADDRESS [RFC6125]), while the valid addresses included in
are used to reach the peer DOTS agent. In other words, the name OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS agent. In
conveyed in OPTION_V4_DOTS_RI MUST NOT be passed to underlying other words, the name conveyed in OPTION_V4_DOTS_RI MUST NOT be
resolution library in the presence of OPTION_V4_DOTS_ADDRESS in a passed to underlying resolution library in the presence of valid
response. OPTION_V4_DOTS_ADDRESS in a response.
If the DHCP client receives OPTION_V4_DOTS_RI only, but If the DHCP client receives OPTION_V4_DOTS_RI only, but
OPTION_V4_DOTS_RI option contains more than one name, as OPTION_V4_DOTS_RI option contains more than one name, as
distinguished by the presence of multiple root labels, the DHCP distinguished by the presence of multiple root labels, the DHCP
client MUST use only the first name. Once the name is validated client MUST use only the first name. Once the name is validated
(Section 10 of [RFC8415]), the name is passed to a name resolution (Section 10 of [RFC8415]), the name is passed to a name resolution
library. Moreover, that name is also used as a reference identifier library. Moreover, that name is also used as a reference identifier
for authentication purposes. for authentication purposes.
If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the
address(es) included in OPTION_V4_DOTS_ADDRESS are used to reach the address(es) included in OPTION_V4_DOTS_ADDRESS are used to reach the
peer DOTS server. In addition, these addresses can be used as peer DOTS server. In addition, these addresses can be used as
identifiers for authentication. identifiers for authentication.
The DHCP client MUST silently discard multicast and host loopback
addresses [RFC6890] conveyed in OPTION_V4_DOTS_ADDRESS.
6. Discovery using Service Resolution 6. Discovery using Service Resolution
This mechanism is performed in two steps: This mechanism is performed in two steps:
1. A DNS domain name is retrieved for each combination of interface 1. A DNS domain name is retrieved for each combination of interface
and address family. A DOTS agent has to determine the domain in and address family. A DOTS agent has to determine the domain in
which it is located relying on dynamic means such as DHCP which it is located relying on dynamic means such as DHCP
(Section 5). Implementations may allow the user to specify a (Section 5). Implementations may allow the user to specify a
default name that is used, if no specific name has been default name that is used, if no specific name has been
configured. configured.
skipping to change at page 15, line 29 skipping to change at page 14, line 49
_dots-signal._tcp.example.net. _dots-signal._tcp.example.net.
IN SRV 0 0 5001 a.example.net. IN SRV 0 0 5001 a.example.net.
_dots-data._tcp.example.net. _dots-data._tcp.example.net.
IN SRV 0 0 5002 a.example.net. IN SRV 0 0 5002 a.example.net.
a.example.net. a.example.net.
IN AAAA 2001:db8::1 IN AAAA 2001:db8::1
Figure 8: Sample Example of Discovery of DOTS Servers using Service Figure 8: Example of Discovery of DOTS Servers using Service
Resolution Resolution
+-------+----------+-------------+------+--------+ +-------+----------+-------------+------+--------+
| Order | Protocol | IP address | Port | Tag | | Order | Protocol | IP address | Port | Tag |
+-------+----------+-------------+------+--------+ +-------+----------+-------------+------+--------+
| 1 | UDP | 2001:db8::1 | 5000 | Signal | | 1 | UDP | 2001:db8::1 | 5000 | Signal |
| 2 | TCP | 2001:db8::1 | 5001 | Signal | | 2 | TCP | 2001:db8::1 | 5001 | Signal |
| 3 | TCP | 2001:db8::1 | 5002 | Data | | 3 | TCP | 2001:db8::1 | 5002 | Data |
+-------+----------+-------------+------+--------+ +-------+----------+-------------+------+--------+
Table 1: Resolution Results Table 1: Resolution Results
skipping to change at page 16, line 24 skipping to change at page 15, line 37
_dots-call-home._udp.example.net. _dots-call-home._udp.example.net.
IN SRV 0 0 6000 b.example.net. IN SRV 0 0 6000 b.example.net.
_dots-call-home._tcp.example.net. _dots-call-home._tcp.example.net.
IN SRV 0 0 6001 b.example.net. IN SRV 0 0 6001 b.example.net.
b.example.net. b.example.net.
IN AAAA 2001:db8::2 IN AAAA 2001:db8::2
Figure 9: Sample Example of Discovery of DOTS Call Home Client using Figure 9: Example of Discovery of DOTS Call Home Client using Service
Service Resolution 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: Resolution Results (Call Home) Table 2: Resolution Results (Call Home)
Note that customized port numbers are used for the DOTS signal Note that customized port numbers are used for the DOTS signal
skipping to change at page 18, line 32 skipping to change at page 17, line 52
The security considerations in [RFC2131] and [RFC8415] are to be The security considerations in [RFC2131] and [RFC8415] are to be
considered. In particular, issues related to rogue DHCP servers and considered. In particular, issues related to rogue DHCP servers and
means to mitigate many of these attacks are discussed in Section 22 means to mitigate many of these attacks are discussed in Section 22
of [RFC8415]. of [RFC8415].
An attacker can get a domain name, domain-validated public An attacker can get a domain name, domain-validated public
certificate from a CA, and host a DOTS agent. An active attacker can certificate from a CA, and host a DOTS agent. An active attacker can
then spoof DHCP responses to include the attacker's DOTS agent. Such then spoof DHCP responses to include the attacker's DOTS agent. Such
an attacker can also launch other attacks as discussed in Section 22 an attacker can also launch other attacks as discussed in Section 22
of [RFC8415]. In addition to the mitigations listed in Section 22 of of [RFC8415]. In addition to the mitigations listed in Section 22 of
[RFC8415], a DOTS agent may be pe-configured with a list of trusted [RFC8415], a DOTS agent may be pre-configured with a list of trusted
DOTS domain names. If such list is pre-configured, a DOTS agent will DOTS domain names. If such a list is pre-configured, a DOTS agent
accept a DHCP discovered name if it matches a name in that list. will accept a DHCP-discovered name if it matches a name in that list.
Also, the DOTS agent has to check that the 'DNS-ID' identifier type Also, the DOTS agent has to check that the 'DNS-ID' identifier type
within subjectAltName in the server certificate matches a pre- within subjectAltName in the server certificate matches a pre-
configured name. If the DOTS agent is instructed to trust subdomains configured name. If the DOTS agent is instructed to trust subdomains
of the names in that list as well, a DOTS agent will also accept a of the names in that list as well, a DOTS agent will also accept a
DHCP discovered name if the left-most label of the discovered name is DHCP-discovered name if the left-most label of the discovered name is
matching a name in the pre-configured list. matching a name in the pre-configured list.
Relying on an underlying resolution library to resolve a supplied Relying on an underlying resolution library to resolve a supplied
reference identifier has similar security issues as those discussed reference identifier has similar security issues as those discussed
in Section 8.2 (e.g., an active attacker may modify DNS messages used in Section 8.2 (e.g., an active attacker may modify DNS messages used
to resolve the supplied reference identifier and point the client to to resolve the supplied reference identifier and point the client to
an attacker server). an attacker server).
Supplying both an IP address and the reference identifier makes it Supplying both an IP address and the reference identifier makes it
easier to use a mis-issued certificate. easier to use a mis-issued certificate.
skipping to change at page 23, line 19 skipping to change at page 22, line 26
Many thanks to Russ White for the review, comments, and text Many thanks to Russ White for the review, comments, and text
contribution. contribution.
Thanks for Dan Wing, Pei Wei, Valery Smyslov, and Jon Shallow for the Thanks for Dan Wing, Pei Wei, Valery Smyslov, and Jon Shallow for the
review and comments. review and comments.
Thanks to Bernie Volz for the review of the DHCP section. Thanks to Bernie Volz for the review of the DHCP section.
Many thanks to Benjamin Kaduk for the detailed AD review. Many thanks to Benjamin Kaduk for the detailed AD review.
Thanks to Zhen Cao, Kyle Rose, and Nagendra Nainar for the Thanks to Zhen Cao, Kyle Rose, Nagendra Nainar, and Peter Yee for the
directorate reviews. directorate reviews.
12. References 12. References
12.1. Normative References 12.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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 31 change blocks. 
73 lines changed or deleted 70 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/