diff options
Diffstat (limited to 'doc/rfc/rfc8973.txt')
| -rw-r--r-- | doc/rfc/rfc8973.txt | 1176 |
1 files changed, 1176 insertions, 0 deletions
diff --git a/doc/rfc/rfc8973.txt b/doc/rfc/rfc8973.txt new file mode 100644 index 0000000..46485a9 --- /dev/null +++ b/doc/rfc/rfc8973.txt @@ -0,0 +1,1176 @@ + + + + +Internet Engineering Task Force (IETF) M. Boucadair +Request for Comments: 8973 Orange +Category: Standards Track T. Reddy.K +ISSN: 2070-1721 McAfee + January 2021 + + + DDoS Open Threat Signaling (DOTS) Agent Discovery + +Abstract + + This document specifies mechanisms to configure DDoS Open Threat + Signaling (DOTS) clients with their DOTS servers. The discovery + procedure also covers the DOTS signal channel Call Home. It can be + useful to know the appropriate DOTS server for a given location in + order to engage mitigation actions. This is true even in cases where + the DOTS client cannot localize the attack: cases where it only knows + that some resources are under attack and that help is needed. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8973. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Why Multiple Discovery Mechanisms? + 4. DOTS Discovery Procedure + 5. DHCP Options for DOTS Agent Discovery + 5.1. DHCPv6 DOTS Options + 5.1.1. Format of DOTS Reference Identifier Option + 5.1.2. Format of DOTS Address Option + 5.1.3. DHCPv6 Client Behavior + 5.2. DHCPv4 DOTS Options + 5.2.1. Format of DOTS Reference Identifier Option + 5.2.2. Format of DOTS Address Option + 5.2.3. DHCPv4 Client Behavior + 6. Discovery Using Service Resolution + 7. DNS Service Discovery + 8. Security Considerations + 8.1. DHCP + 8.2. Service Resolution + 8.3. DNS Service Discovery + 9. IANA Considerations + 9.1. Service Name and Transport Protocol Port Number Registry + 9.2. DHCPv6 Options + 9.3. DHCPv4 Options + 9.4. Application Service & Application Protocol Tags + 9.4.1. DOTS Application Service Tag Registration + 9.4.2. DOTS Call Home Application Service Tag Registration + 9.4.3. signal.udp Application Protocol Tag Registration + 9.4.4. signal.tcp Application Protocol Tag Registration + 9.4.5. data.tcp Application Protocol Tag Registration + 10. References + 10.1. Normative References + 10.2. Informative References + Acknowledgements + Contributors + Authors' Addresses + +1. Introduction + + DDoS Open Threat Signaling (DOTS) [RFC8811] specifies an architecture + in which a DOTS client can inform a DOTS server that the network is + under a potential attack and that appropriate mitigation actions are + required. Indeed, because the lack of a common method to coordinate + a real-time response among involved actors and network domains + inhibits the effectiveness of DDoS attack mitigation, the DOTS signal + channel protocol [RFC8782] is meant to carry requests for DDoS attack + mitigation. With this approach, DOTS can reduce the impact of an + attack and lead to more efficient defensive actions in various + deployment scenarios, such as those discussed in [DOTS-USE-CASES]. + Moreover, DOTS clients can instruct a DOTS server to install named + filtering rules by means of the DOTS data channel protocol [RFC8783]. + + The basic high-level DOTS architecture is illustrated in Figure 1. + + +-----------+ +-------------+ + | Mitigator | ~~~~~~~~~~ | DOTS Server | + +-----------+ +------+------+ + | + | + | + +---------------+ +------+------+ + | Attack Target | ~~~~~~ | DOTS Client | + +---------------+ +-------------+ + + Figure 1: Basic DOTS Architecture + + [RFC8811] specifies that the DOTS client may be provided with a list + of DOTS servers, each associated with one or more IP addresses. + These addresses may or may not be of the same address family. The + DOTS client establishes one or more DOTS sessions by connecting to + the provided DOTS server addresses. + + This document specifies methods for DOTS clients to discover their + DOTS server(s). The rationale for specifying multiple discovery + mechanisms is discussed in Section 3. + + The discovery methods can also be used by a DOTS server to locate a + DOTS client in the context of DOTS signal channel Call Home + [DOTS-SIG-CALL-HOME]. The basic high-level DOTS Call Home + architecture is illustrated in Figure 2. + + +---------------+ +-------------+ + | Alert | ~~~~~~ | Call Home | + | | | DOTS Client | + +---------------+ +------+------+ + | + | + | + +---------------+ +------+------+ + | Attack | ~~~~~~ | Call Home | + | Source(s) | | DOTS Server | + +---------------+ +-------------+ + + Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture + + A DOTS agent may be used to establish base DOTS channels, DOTS Call + Home, or both. This specification accommodates all these deployment + cases. + + Considerations for the selection of DOTS server(s) by multihomed DOTS + clients are out of this document's scope; readers should refer to + [DOTS-MULTIHOMING] for more details. + + This document assumes that security credentials to authenticate DOTS + server(s) are pre-provisioned to a DOTS client using a mechanism such + as (but not limited to) those discussed in [RFC8572] or + [BTSRP-KEYINFR]. DOTS clients use those credentials for + authentication purposes following the rules documented in [RFC8782]. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + The reader should be familiar with the terms defined in [RFC3958]. + + This document makes use of the following terms: + + DHCP: refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC8415]. + + DOTS client: refers to a DOTS-aware software module responsible for + requesting attack response coordination with other DOTS-aware + elements. + + DOTS server: is a DOTS-aware software module handling and responding + to messages from DOTS clients. The DOTS server enables mitigation + on behalf of the DOTS client, if requested, by communicating the + DOTS client's request to the mitigator and returning selected + mitigator feedback to the requesting DOTS client. + + Call Home DOTS client or server: refers to a DOTS client or server + deployed in a Call Home scenario (Figure 2). + + DOTS agent: is any DOTS-aware software module capable of + participating in a DOTS channel. + + Peer DOTS agent: refers to the peer DOTS server (base DOTS + operation) or to a peer Call Home DOTS client (for DOTS signal + channel Call Home). + +3. Why Multiple Discovery Mechanisms? + + Analysis of the various use cases sketched in [DOTS-USE-CASES] + reveals that it is unlikely that one single discovery method can be + suitable for all the sample deployments. Concretely: + + * Many of the use cases discussed in [DOTS-USE-CASES] do involve + Customer Premises Equipment (CPE). Multiple CPEs connected to + distinct network providers may even be considered. It is + intuitive to leverage existing mechanisms, such as discovery using + service resolution or DHCP, to provision the CPE acting as a DOTS + client with the DOTS server(s). + + * Resolving a DOTS server domain name offered by an upstream transit + provider provisioned to a DOTS client into IP address(es) requires + the use of the appropriate DNS resolvers; otherwise, resolving + those names will fail. The use of protocols, such as DHCP, does + allow associating provisioned DOTS server domain names with a list + of DNS servers to be used for name resolution. Furthermore, DHCP + allows for directly providing IP addresses, therefore, avoiding + the need for extra lookup delays. + + * Some of the use cases may allow DOTS clients to have direct + communications with upstream DOTS servers, that is, no DOTS + gateway is involved. Leveraging existing protocol behaviors that + do not require specific features on the node embedding the DOTS + client may ease DOTS deployment. Typically, the use of + Straightforward-Naming Authority Pointer (S-NAPTR) lookups + [RFC3958] allows the DOTS server administrators to provision the + preferred DOTS transport protocol between the DOTS client and the + DOTS server and allows the DOTS client to discover this + preference. + + * The upstream network provider is not the DDoS mitigation provider + for some of these use cases. It is safe to assume that, for such + deployments, the DOTS server(s) domain name is provided during the + service subscription (i.e., manual/local configuration). + + * Multiple DOTS clients may be enabled within a network (e.g., an + enterprise network). Dynamic discovery needs to be deterministic + from an operational standpoint. + + * Some of the use cases may involve a DOTS gateway that is + responsible for selecting the appropriate DOTS server(s) to relay + requests received from DOTS clients. + + Consequently, this document describes a unified discovery logic + (Section 4) that involves the following mechanisms: + + * dynamic discovery using DHCP (Section 5) + + * a resolution mechanism based on S-NAPTR resource records in the + DNS (Section 6) + + * DNS Service Discovery (Section 7) + +4. DOTS Discovery Procedure + + Operators will need a consistent set of ways in which DOTS clients + can discover this information and a consistent priority among these + options. If some devices prefer manual configuration over dynamic + discovery while others prefer dynamic discovery over manual + configuration, the result will be a process where the operator must + find devices that are using the wrong DOTS server(s), determine how + to 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 + below to determine a DOTS server list. All DOTS clients SHOULD + implement all three, or as many as are practical for any specific + device, of the following ways to discover DOTS servers in order to + facilitate the deployment of DOTS in large-scale environments. For + example, a CPE will support the first two mechanisms, a host within a + LAN will support the last two mechanisms, or an application server + will support a local configuration. More examples are discussed in + Section 3. DOTS clients will prefer information received from the + discovery methods in the order listed below. + + 1. Explicit Configuration: + + Local/Manual Configuration: A DOTS client will learn the DOTS + server(s) by means of local or manual DOTS configuration + (i.e., DOTS servers configured at the system level). + Configuration discovered from a DOTS client application is + considered a local configuration. + + An implementation may give the user an opportunity (e.g., by + means of configuration file options or menu items) to specify + DOTS server(s) for each address family. These may be + specified either as a list of IP addresses or the DNS name of + a DOTS server. When only DOTS server IP addresses are + configured, a reference identifier must also be configured for + authentication purposes. + + Automatic Configuration (e.g., DHCP): The DOTS client attempts + to discover DOTS server(s) names and/or addresses from DHCP, + as described in Section 5. + + 2. Service Resolution: The DOTS client attempts to discover DOTS + server name(s) using service resolution, as specified in + Section 6. + + 3. DNS-SD: DNS-based Service Discovery. The DOTS client attempts to + discover DOTS server name(s) using DNS service discovery, as + specified in Section 7. + + 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 + the relevant DOTS server is obtained directly. Implementation + options may vary on a per-device basis, as some devices may not have + DNS capabilities and/or suitable DNS configuration. + + On hosts with more than one interface or address family (IPv4/IPv6), + the DOTS server discovery procedure has to be performed for each + interface-/address-family combination. A DOTS client may choose to + perform the discovery procedure only for a desired interface/address + combination if the client does not wish to discover a DOTS server for + all interface-/address-family combinations. + + This procedure is also followed by a Call Home DOTS server to + discover its Call Home DOTS client in the context of + [DOTS-SIG-CALL-HOME]. + + The discovery method is performed upon the bootstrapping of a DOTS + agent and is reiterated by the DOTS agent upon the following events: + + * expiry of a validity timer (e.g., DHCP lease, DHCP information + refresh time, or DNS TTL) associated with a discovered DOTS agent + + * expiry of the certificate of a peer DOTS agent currently in use + + * attachment to a new network + +5. DHCP Options for DOTS Agent Discovery + + As reported in Section 1.7.2 of [RFC6125]: + + | Some certification authorities issue server certificates based on + | IP addresses, but preliminary evidence indicates that such + | certificates are a very small percentage (less than 1%) of issued + | certificates. + + In order to allow for PKIX-based authentication between a DOTS client + and server while accommodating the current best practices for issuing + certificates, this document allows DOTS agents to retrieve the names + of their peer DOTS agents. These names can be used for two purposes: + (1) to retrieve the list of IP addresses of a peer DOTS agent or (2) + to be presented as a reference identifier for authentication + purposes. + + Defining the option to include a list of IP addresses would avoid + depending on an underlying name resolution, but that design requires + also supplying a name for PKIX-based authentication purposes. + + Given that DOTS gateways can be involved in a DOTS session, a peer + DOTS agent can be reachable using a link-local address. Such + addresses can also be discovered using the options defined in + Section 5.1. + + The list of the IP addresses returned by DHCP servers is typically + used to feed the DOTS server selection procedure, including when DOTS + agents are provided with primary and backup IP addresses of their + peer DOTS agents. An example of the DOTS server selection procedure + is specified in Section 4.3 of [RFC8782]. + + The design assumes that the same peer DOTS agent is used for + establishing both signal and data channels. For more customized + configurations (e.g., transport-specific configuration and distinct + DOTS servers for the signal and data channels), an operator can + supply only a DOTS reference identifier that will be then passed to + the procedure described in Section 6. + + The design allows terminating the base DOTS channels and DOTS Call + 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 + 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 + for the DOTS Call Home. The DOTS client (or Call Home DOTS server) + will then use the address selection procedure specified in + Section 4.3 of [RFC8782] to identify the IP address of the peer DOTS + server (or Call Home DOTS client). + + For example, let's consider that the DOTS server is reachable at + 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 + reference identifier and a list that includes both + 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 + server), which will try to establish connections to the addresses of + that list and destination port number 4646 (or the Call Home port + number). As a 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 Call Home DOTS client). + +5.1. DHCPv6 DOTS Options + +5.1.1. Format of DOTS Reference Identifier Option + + The DHCPv6 DOTS Reference Identifier option is used to configure the + name of the DOTS server (or the name of the Call Home DOTS client). + The format of this option is shown in Figure 3. + + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_V6_DOTS_RI | Option-length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | dots-agent-name (FQDN) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: DHCPv6 DOTS Reference Identifier Option + + The fields of the option shown in Figure 3 are as follows: + + Option-code: OPTION_V6_DOTS_RI (141, see Section 9.2). + Option-length: Length of the dots-agent-name field in octets. + dots-agent-name: A fully qualified domain name of the peer DOTS + agent. This field is formatted as specified in Section 10 of + [RFC8415]. + + An example of the dots-agent-name encoding is shown in Figure 4. + This example conveys the FQDN "dots.example.com", and the resulting + Option-length field is 18. + + +------+------+------+------+------+------+------+------+------+ + | 0x04 | d | o | t | s | 0x07 | e | x | a | + +------+------+------+------+------+------+------+------+------+ + | m | p | l | e | 0x03 | c | o | m | 0x00 | + +------+------+------+------+------+------+------+------+------+ + + Figure 4: An Example of the dots-agent-name Encoding + + +5.1.2. Format of DOTS Address Option + + The DHCPv6 DOTS Address option can be used to configure a list of + IPv6 addresses of a DOTS server (or a Call Home DOTS client). The + format of this option is shown in Figure 5. + + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_V6_DOTS_ADDRESS | Option-length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | DOTS ipv6-address | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | DOTS ipv6-address | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: DHCPv6 DOTS Address Option + + The fields of the option shown in Figure 5 are as follows: + + Option-code: OPTION_V6_DOTS_ADDRESS (142, see Section 9.2). + Option-length: Length of the DOTS ipv6-address fields in octets. + This MUST be a multiple of 16. + DOTS ipv6-address: Includes one or more IPv6 addresses [RFC4291] of + the peer DOTS agent to be used by a DOTS agent for establishing a + DOTS session. The addresses are listed in the order of preference + for use by the DOTS agent. + + Note that IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) + may be included in this option when there is no DHCPv4 server able to + advertise the DHCPv4 DOTS options (Section 5.2) and when only IPv4 + connectivity is possible to the peer DOTS agent. + + +5.1.3. DHCPv6 Client Behavior + + DHCP clients MAY request options OPTION_V6_DOTS_RI and + OPTION_V6_DOTS_ADDRESS, as defined in Sections 18.2.1, 18.2.2, + 18.2.4, 18.2.5, 18.2.6, and 21.7 of [RFC8415]. As a convenience to + the reader, it is mentioned here that the DHCP client includes the + requested option codes in the Option Request option. + + If the DHCP client receives more than one instance of option + OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS), it MUST use only the + first instance of that option. + + 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 + the reference identifier for authentication purposes (e.g., PKIX + [RFC6125]), while the valid addresses included in + OPTION_V6_DOTS_ADDRESS are used to reach the peer DOTS agent. In + other words, the name conveyed in OPTION_V6_DOTS_RI MUST NOT be + passed to an underlying resolution library in the presence of a valid + OPTION_V6_DOTS_ADDRESS in a response. + + If the DHCP client receives OPTION_V6_DOTS_RI only, but + OPTION_V6_DOTS_RI contains more than one name, the DHCP client MUST + use only the first name. Once the name is validated (Section 10 of + [RFC8415]), the name is passed to a name resolution library. + Moreover, that name is also used as a reference identifier for + authentication purposes. + + If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, 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 + identifiers for authentication. + +5.2. DHCPv4 DOTS Options + +5.2.1. Format of DOTS Reference Identifier Option + + The DHCPv4 [RFC2132] DOTS Reference Identifier option is used to + configure a name of the peer DOTS agent. The format of this option + is illustrated in Figure 6. + + Code Length Peer DOTS agent name + +-----+-----+-----+-----+-----+-----+-----+-- + | 147 | n | s1 | s2 | s3 | s4 | s5 | ... + +-----+-----+-----+-----+-----+-----+-----+-- + + Figure 6: DHCPv4 DOTS Reference Identifier Option + + The values s1, s2, s3, etc. represent the domain name labels in the + domain name encoding. + + The fields of the option shown in Figure 6 are as follows: + + Code: OPTION_V4_DOTS_RI (147, see Section 9.3). + Length: Includes the length of the "Peer DOTS agent name" field in + octets. + Peer DOTS agent name: The domain name of the peer DOTS agent. This + field is formatted as specified in Section 10 of [RFC8415]. + +5.2.2. Format of DOTS Address Option + + The DHCPv4 DOTS Address option can be used to configure a list of + IPv4 addresses of a peer DOTS agent. The format of this option is + illustrated in Figure 7. + + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code=148 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | DOTS IPv4 Address | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- + | | | + | DOTS IPv4 Address | | + | | optional + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + . ... . | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- + + Figure 7: DHCPv4 DOTS Address Option + + The fields of the option shown in Figure 7 are as follows: + + Code: OPTION_V4_DOTS_ADDRESS (148, see Section 9.3). + Length: Set to 4*N, where N is the number of IPv4 addresses included + in the option. + DOTS IPv4 Address(es): Contains one or more IPv4 addresses of the + peer DOTS agent to be used by a DOTS agent. The addresses are + listed in the order of preference for use by the DOTS agent. + + OPTION_V4_DOTS_ADDRESS is a concatenation-requiring option. As such, + the mechanism specified in [RFC3396] MUST be used if + OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255 + octets. + +5.2.3. DHCPv4 Client Behavior + + 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 + List option [RFC2132]. + + 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. + + 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 + the reference identifier for authentication purposes (e.g., PKIX + [RFC6125]), while the valid addresses included in + OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS agent. In + other words, the name conveyed in OPTION_V4_DOTS_RI MUST NOT be + passed to an underlying resolution library in the presence of valid + OPTION_V4_DOTS_ADDRESS in a response. + + If the DHCP client receives OPTION_V4_DOTS_RI only, but + OPTION_V4_DOTS_RI option contains more than one name, as + distinguished by the presence of multiple root labels, the DHCP + client MUST use only the first name. Once the name is validated + (Section 10 of [RFC8415]), the name is passed to a name resolution + library. Moreover, that name is also used as a reference identifier + for authentication purposes. + + If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, 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 + identifiers for authentication. + +6. Discovery Using Service Resolution + + This mechanism is performed in two steps: + + 1. A DNS domain name is retrieved for each combination of interface + and address family. A DOTS agent has to determine the domain in + which it is located relying on dynamic means, such as DHCP + (Section 5). Implementations may allow the user to specify a + default name that is used if no specific name has been + configured. + + 2. Retrieved DNS domain names are then used for S-NAPTR lookups + [RFC3958]. Further DNS lookups may be necessary to determine the + peer DOTS agent IP address(es). + + Once the DOTS agent has retrieved its DNS domain or discovered the + peer DOTS agent name that needs to be resolved, an S-NAPTR lookup + with the appropriate application service and the desired protocol tag + is made to obtain information necessary to connect to the + authoritative peer DOTS agent within the given domain. + + This specification defines "DOTS" and "DOTS-CALL-HOME" as application + service tags (Sections 9.4.1 and 9.4.2). It also defines + "signal.udp" (Section 9.4.3), "signal.tcp" (Section 9.4.4), and + "data.tcp" (Section 9.4.5) as application protocol tags. An example + is provided in Figure 8. + + In the example below, for domain "example.net", the resolution + algorithm will result in IP address, port, tag, and protocol tuples + listed in Table 1. + + example.net. + IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. + IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. + IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net. + + signal.example.net. + IN NAPTR 100 10 "s" DOTS:signal.udp "" _dots-signal._udp.example.net. + IN NAPTR 200 10 "s" DOTS:signal.tcp "" _dots-signal._tcp.example.net. + + data.example.net. + IN NAPTR 100 10 "s" DOTS:data.tcp "" _dots-data._tcp.example.net. + IN NAPTR 200 10 "a" DOTS:data.tcp "" b.example.net. + + _dots-signal._udp.example.net. + IN SRV 0 0 5000 a.example.net. + + _dots-signal._tcp.example.net. + IN SRV 0 0 5001 a.example.net. + + _dots-data._tcp.example.net. + IN SRV 0 0 5002 a.example.net. + + a.example.net. + IN AAAA 2001:db8::1 + + b.example.net. + IN AAAA 2001:db8::2 + + Figure 8: Example of Discovery of DOTS Servers Using Service + Resolution + + +=======+==========+=============+======+========+ + | Order | Protocol | IP address | Port | Tag | + +=======+==========+=============+======+========+ + | 1 | UDP | 2001:db8::1 | 5000 | Signal | + +-------+----------+-------------+------+--------+ + | 2 | TCP | 2001:db8::1 | 5001 | Signal | + +-------+----------+-------------+------+--------+ + | 3 | TCP | 2001:db8::1 | 5002 | Data | + +-------+----------+-------------+------+--------+ + | 4 | TCP | 2001:db8::2 | 443 | Data | + +-------+----------+-------------+------+--------+ + + Table 1: Resolution Results + + An example is provided in Figure 9 for the Call Home case. In this + example, the resolution algorithm will result in IP address, port, + and protocol tuples listed in Table 2 for domain "example.net". + + example.net. + IN NAPTR 100 10 "" DOTS-CALL-HOME:signal.udp "" signal.example.net. + IN NAPTR 200 10 "" DOTS-CALL-HOME:signal.tcp "" signal.example.net. + + signal.example.net. + IN NAPTR 100 10 "s" DOTS-CALL-HOME:signal.udp "" + _dots-call-home._udp.example.net. + IN NAPTR 200 10 "s" DOTS-CALL-HOME:signal.tcp "" + _dots-call-home._tcp.example.net. + + _dots-call-home._udp.example.net. + IN SRV 0 0 6000 b.example.net. + + _dots-call-home._tcp.example.net. + IN SRV 0 0 6001 b.example.net. + + b.example.net. + IN AAAA 2001:db8::2 + + Figure 9: Example of Discovery of DOTS Call Home Client Using Service + Resolution + + +=======+==========+=============+======+ + | Order | Protocol | IP address | Port | + +=======+==========+=============+======+ + | 1 | UDP | 2001:db8::2 | 6000 | + +-------+----------+-------------+------+ + | 2 | TCP | 2001:db8::2 | 6001 | + +-------+----------+-------------+------+ + + Table 2: Resolution Results (Call Home) + + 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 4646 (DOTS signal channel) and 443 (DOTS data + channel) as DOTS service port numbers. + + If no DOTS-specific S-NAPTR records can be retrieved, the discovery + procedure fails for this domain name (and the corresponding interface + and IP protocol version). If more domain names are known, the + discovery procedure MAY perform the corresponding S-NAPTR lookups + immediately. However, before retrying a lookup that has failed, a + DOTS client MUST wait a time period that is appropriate for the + encountered error (e.g., NXDOMAIN, timeout, etc.). + +7. DNS Service Discovery + + DNS-based Service Discovery (DNS-SD) [RFC6763] provides generic + solutions for discovering services. DNS-SD defines a set of naming + rules for certain DNS record types that they use for advertising and + discovering services. + + Section 4.1 of [RFC6763] specifies that a service instance name in + DNS-SD has the following structure: + + <Instance> . <Service> . <Domain> + + The <Domain> portion specifies the DNS subdomain where the service + instance is registered. It is a conventional domain name, such as + "example.com". + + The <Service> portion of the DOTS service instance name MUST be + "_dots-signal._udp", "_dots-signal._tcp", "_dots-data._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 + + DOTS-related security considerations are discussed in Section 5 of + [RFC8811]. As a reminder, DOTS agents must authenticate each other + using (D)TLS before a DOTS session is considered valid according to + the [RFC8782]. + + An attacker may block some protocol messages (e.g., DHCP) to force + the client to use a discovery mechanism with a lower priority. The + security implications of such attack are those inherent to the + fallback discovery mechanism discussed in the following subsections. + + The results of the discovery procedure are a function of the + interface/address family. Contacting a discovered DOTS server via an + interface to which it is not bound may exacerbate the delay required + to establish a DOTS channel. Moreover, such behavior may reveal that + a DOTS service is enabled by a DOTS client domain and exposes the + identity of the DOTS service provider (which can be inferred from the + name and the destination IP address) to external networks. + + Security considerations related to how security credentials to + authenticate DOTS server(s) are provisioned to a DOTS client are + those inherent to the mechanism used for that purpose (for example, + see [RFC8572]). + +8.1. DHCP + + The security considerations in [RFC2131] and [RFC8415] are to be + considered. In particular, issues related to rogue DHCP servers and + means to mitigate many of these attacks are discussed in Section 22 + of [RFC8415]. + + An attacker can get a domain name, get a domain-validated public + certificate from a certification authority (CA), and host a DOTS + agent. An active attacker can then spoof DHCP responses to include + the attacker's DOTS agent. Such an attacker can also launch other + attacks, as discussed in Section 22 of [RFC8415]. In addition to the + mitigations listed in Section 22 of [RFC8415], a DOTS agent may be + preconfigured with a list of trusted DOTS domain names. If such a + list is preconfigured, a DOTS agent 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 within subjectAltName in the + server certificate matches a preconfigured name. If the DOTS agent + is instructed to trust subdomains of the names in that list as well + (e.g., "*.example.com"), a DOTS agent will accept a DHCP-discovered + name that matches a name in the preconfigured list (e.g., "dots- + 1.example.com" or "dots-2.example.com"). + + Relying on an underlying resolution library to resolve a supplied + reference identifier has similar security issues as those discussed + 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 + an attacker server). + + Supplying both an IP address and the reference identifier makes it + easier to use a mis-issued certificate. + +8.2. Service Resolution + + The primary attack against the methods described in Section 6 is one + that would lead to impersonation of a peer DOTS agent. An attacker + could attempt to compromise the S-NAPTR resolution. + + The DOTS client (or a Call Home DOTS server) constructs one reference + identifier for the DOTS server (or a Call Home DOTS client) based on + the domain name that is used for S-NAPTR lookup: DNS-ID. If the + reference identifier is found (as described in Section 6 of + [RFC6125]) in the PKIX certificate's subjectAltName extension, the + DOTS client should accept the certificate for the server. + + DNS Security Extensions (DNSSEC) [RFC4033] uses cryptographic keys + and digital signatures to provide authentication of DNS data. The + information that is retrieved from the S-NAPTR lookup and that is + validated using DNSSEC is thereby proved to be the authoritative + data. + +8.3. DNS Service Discovery + + Since DNS-SD is a specification for how to name and use records in + the existing DNS system, it has no specific additional security + requirements over and above those that already apply to DNS queries + and DNS updates. For DNS queries, DNSSEC SHOULD be used where the + authenticity of information is important. For DNS updates, secure + updates [RFC2136] [RFC3007] SHOULD generally be used to control which + clients have permission to update DNS records. + + Note that means such as DNS over TLS (DoT) [RFC7858] or DNS over + HTTPS (DoH) [RFC8484] can be used to prevent eavesdroppers from + accessing DNS messages. + +9. IANA Considerations + + +9.1. Service Name and Transport Protocol Port Number Registry + + IANA has allocated the following service names from the registry + available at: <https://www.iana.org/assignments/service-names-port- + numbers/>. + + Service Name: dots-data + Port Number: N/A + Transport Protocol(s): TCP + Description: DOTS Data Channel Protocol. The service + name is used to construct the SRV service + name "_dots-data._tcp" for discovering DOTS + servers used to establish DOTS data channel. + Assignee: IESG: iesg@ietf.org + Contact: IETF Chair: chair@ietf.org + Reference: [RFC8973] + + Service Name: dots-call-home + Transport Protocol(s): TCP/UDP + Description: DOTS Signal Channel Call Home Protocol. The + service name is used to construct the SRV + service names "_dots-call-home._udp" and + "_dots-call-home._tcp" for discovering Call + Home DOTS clients used to establish DOTS + signal channel Call Home. + Assignee: IESG: iesg@ietf.org + Contact: IETF Chair: chair@ietf.org + Reference: [RFC8973] + + IANA has updated the following entry from the registry available at: + <https://www.iana.org/assignments/service-names-port-numbers/>. + + Port Number: 4646 + Transport Protocol(s): TCP/UDP + Description: DOTS Signal Channel Protocol. The service + name is used to construct the SRV service + names "_dots-signal._udp" and "_dots- + signal._tcp" for discovering DOTS servers + used to establish DOTS signal channel. + Assignee: IESG: iesg@ietf.org + Contact: IETF Chair: chair@ietf.org + Reference: [RFC8782][RFC8973] + +9.2. DHCPv6 Options + + IANA has assigned the following new DHCPv6 Option Codes in the + registry maintained in <https://www.iana.org/assignments/ + dhcpv6-parameters/>. + + +=======+========================+============+==================+ + | Value | Description | Client ORO | Singleton Option | + +=======+========================+============+==================+ + | 141 | OPTION_V6_DOTS_RI | Yes | Yes | + +-------+------------------------+------------+------------------+ + | 142 | OPTION_V6_DOTS_ADDRESS | Yes | Yes | + +-------+------------------------+------------+------------------+ + + Table 3: DHCPv6 Options + +9.3. DHCPv4 Options + + IANA has assigned the following new DHCPv4 Option Codes in the + registry maintained in <https://www.iana.org/assignments/bootp-dhcp- + parameters/>. + + +========================+=====+=========+==============+===========+ + | Name | Tag | Data | Meaning | Reference | + | | | Length | | | + +========================+=====+=========+==============+===========+ + | OPTION_V4_DOTS_RI | 147 | N | The name | [RFC8973] | + | | | | of the | | + | | | | peer DOTS | | + | | | | agent. | | + +------------------------+-----+---------+--------------+-----------+ + | OPTION_V4_DOTS_ADDRESS | 148 | N (the | N/4 IPv4 | [RFC8973] | + | | | minimal | addresses | | + | | | length | of peer | | + | | | is 4) | DOTS | | + | | | | agent(s). | | + +------------------------+-----+---------+--------------+-----------+ + + Table 4: DHCPv4 Options + + +9.4. Application Service & Application Protocol Tags + + IANA has made the following allocations from the registries available + at <https://www.iana.org/assignments/s-naptr-parameters/> for + application service tags and application protocol tags. + +9.4.1. DOTS Application Service Tag Registration + + Application Service Tag: DOTS + Intended Usage: See Section 6 + Security Considerations: See Section 8 + Interoperability Considerations: None + Relevant Publications: RFC 8973 + +9.4.2. DOTS Call Home Application Service Tag Registration + + Application Service Tag: DOTS-CALL-HOME + Intended Usage: See Section 6 + Security Considerations: See Section 8 + Interoperability Considerations: None + Relevant Publications: RFC 8973 + +9.4.3. signal.udp Application Protocol Tag Registration + + Application Protocol Tag: signal.udp + Intended Usage: See Section 6 + Security Considerations: See Section 8 + Interoperability Considerations: None + Relevant Publications: RFC 8973 + +9.4.4. signal.tcp Application Protocol Tag Registration + + Application Protocol Tag: signal.tcp + Intended Usage: See Section 6 + Security Considerations: See Section 8 + Interoperability Considerations: None + Relevant Publications: RFC 8973 + +9.4.5. data.tcp Application Protocol Tag Registration + + Application Protocol Tag: data.tcp + Intended Usage: See Section 6 + Security Considerations: See Section 8 + Interoperability Considerations: None + Relevant Publications: RFC 8973 + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, DOI 10.17487/RFC2131, March 1997, + <https://www.rfc-editor.org/info/rfc2131>. + + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, + <https://www.rfc-editor.org/info/rfc2132>. + + [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the + Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, + DOI 10.17487/RFC3396, November 2002, + <https://www.rfc-editor.org/info/rfc3396>. + + [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application + Service Location Using SRV RRs and the Dynamic Delegation + Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, + January 2005, <https://www.rfc-editor.org/info/rfc3958>. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, <https://www.rfc-editor.org/info/rfc4291>. + + [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, + <https://www.rfc-editor.org/info/rfc6763>. + + [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, + "Special-Purpose IP Address Registries", BCP 153, + RFC 6890, DOI 10.17487/RFC6890, April 2013, + <https://www.rfc-editor.org/info/rfc6890>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., + Richardson, M., Jiang, S., Lemon, T., and T. Winters, + "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 8415, DOI 10.17487/RFC8415, November 2018, + <https://www.rfc-editor.org/info/rfc8415>. + +10.2. Informative References + + [BTSRP-KEYINFR] + Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M. + H., and K. Watsen, "Bootstrapping Remote Secure Key + Infrastructures (BRSKI)", Work in Progress, Internet- + Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11 + November 2020, <https://tools.ietf.org/html/draft-ietf- + anima-bootstrapping-keyinfra-45>. + + [DOTS-MULTIHOMING] + Boucadair, M., Reddy, T., and W. Pan, "Multi-homing + Deployment Considerations for Distributed-Denial-of- + Service Open Threat Signaling (DOTS)", Work in Progress, + Internet-Draft, draft-ietf-dots-multihoming-05, 23 + November 2020, <https://tools.ietf.org/html/draft-ietf- + dots-multihoming-05>. + + [DOTS-SIG-CALL-HOME] + Reddy, T., Boucadair, M., and J. Shallow, "Distributed + Denial-of-Service Open Threat Signaling (DOTS) Signal + Channel Call Home", Work in Progress, Internet-Draft, + draft-ietf-dots-signal-call-home-13, 11 January 2021, + <https://tools.ietf.org/html/draft-ietf-dots-signal-call- + home-13>. + + [DOTS-USE-CASES] + Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, + L., and K. Nishizuka, "Use cases for DDoS Open Threat + Signaling", Work in Progress, Internet-Draft, draft-ietf- + dots-use-cases-25, 5 July 2020, + <https://tools.ietf.org/html/draft-ietf-dots-use-cases- + 25>. + + [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, DOI 10.17487/RFC2136, April 1997, + <https://www.rfc-editor.org/info/rfc2136>. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, + <https://www.rfc-editor.org/info/rfc3007>. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, + <https://www.rfc-editor.org/info/rfc4033>. + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March + 2011, <https://www.rfc-editor.org/info/rfc6125>. + + [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., + and P. Hoffman, "Specification for DNS over Transport + Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May + 2016, <https://www.rfc-editor.org/info/rfc7858>. + + [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS + (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, + <https://www.rfc-editor.org/info/rfc8484>. + + [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero + Touch Provisioning (SZTP)", RFC 8572, + DOI 10.17487/RFC8572, April 2019, + <https://www.rfc-editor.org/info/rfc8572>. + + [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., + Mortensen, A., and N. Teague, "Distributed Denial-of- + Service Open Threat Signaling (DOTS) Signal Channel + Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, + <https://www.rfc-editor.org/info/rfc8782>. + + [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed + Denial-of-Service Open Threat Signaling (DOTS) Data + Channel Specification", RFC 8783, DOI 10.17487/RFC8783, + May 2020, <https://www.rfc-editor.org/info/rfc8783>. + + [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., + Teague, N., and R. Compton, "DDoS Open Threat Signaling + (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, + August 2020, <https://www.rfc-editor.org/info/rfc8811>. + +Acknowledgements + + Thanks to Brian Carpenter for the review of the Bootstrapping Remote + Secure Key Infrastructure (BRSKI) text used in previous draft + versions of the specification. + + Many thanks to Russ White for the review, comments, and text + contribution. + + Thanks to Dan Wing, Pei Wei, Valery Smyslov, and Jon Shallow for the + review and comments. + + Thanks to Bernie Volz for the review of the DHCP section. + + Many thanks to Benjamin Kaduk for the detailed AD review. + + Thanks to Zhen Cao, Kyle Rose, Nagendra Nainar, and Peter Yee for the + directorate reviews. + + Thanks to Barry Leiba, Martin Duke, Roman Danyliw, Éric Vyncke, and + Magnus Westerlund for the IESG review. + +Contributors + + Prashanth Patil + Cisco Systems, Inc. + + Email: praspati@cisco.com + + +Authors' Addresses + + Mohamed Boucadair + Orange + 35000 Rennes + France + + Email: mohamed.boucadair@orange.com + + + Tirumaleswar Reddy.K + McAfee, Inc. + Embassy Golf Link Business Park + Bangalore 560071 + Karnataka + India + + Email: TirumaleswarReddy_Konda@McAfee.com |