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/ |