idnits 2.17.00 (12 Aug 2021) /tmp/idnits2908/draft-ietf-dots-server-discovery-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 929 has weird spacing: '...minimal add...' == Line 930 has weird spacing: '...ngth is peer ...' -- The document date (November 15, 2020) is 545 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ThisDocument' is mentioned on line 928, but not defined == Outdated reference: draft-ietf-anima-bootstrapping-keyinfra has been published as RFC 8995 == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-04 == Outdated reference: draft-ietf-dots-signal-call-home has been published as RFC 9066 == Outdated reference: draft-ietf-dots-use-cases has been published as RFC 8903 -- Obsolete informational reference (is this intentional?): RFC 8782 (Obsoleted by RFC 9132) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy 5 Expires: May 19, 2021 McAfee 6 November 15, 2020 8 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent 9 Discovery 10 draft-ietf-dots-server-discovery-15 12 Abstract 14 This document specifies mechanisms to configure Distributed Denial of 15 Service Open Threat Signaling (DOTS) clients with their DOTS servers. 16 The discovery procedure also covers the DOTS Signal Channel Call 17 Home. Knowing the appropriate DOTS server for a given location can 18 be useful to engage mitigation actions even in cases where the DOTS 19 client cannot localize the attack, but only knows that some resources 20 are under attack and that help is needed. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 19, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Why Multiple Discovery Mechanisms? . . . . . . . . . . . . . 5 59 4. DOTS Discovery Procedure . . . . . . . . . . . . . . . . . . 6 60 5. DHCP Options for DOTS Agent Discovery . . . . . . . . . . . . 8 61 5.1. DHCPv6 DOTS Options . . . . . . . . . . . . . . . . . . . 9 62 5.1.1. Format of DOTS Reference Identifier Option . . . . . 9 63 5.1.2. Format of DOTS Address Option . . . . . . . . . . . . 10 64 5.1.3. DHCPv6 Client Behavior . . . . . . . . . . . . . . . 11 65 5.2. DHCPv4 DOTS Options . . . . . . . . . . . . . . . . . . . 11 66 5.2.1. Format of DOTS Reference Identifier Option . . . . . 11 67 5.2.2. Format of DOTS Address Option . . . . . . . . . . . . 12 68 5.2.3. DHCPv4 Client Behavior . . . . . . . . . . . . . . . 13 69 6. Discovery using Service Resolution . . . . . . . . . . . . . 14 70 7. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 17 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 72 8.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 8.2. Service Resolution . . . . . . . . . . . . . . . . . . . 19 74 8.3. DNS Service Discovery . . . . . . . . . . . . . . . . . . 19 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 76 9.1. The Service Name and Transport Protocol Port Number 77 Registry . . . . . . . . . . . . . . . . . . . . . . . . 19 78 9.2. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 20 79 9.3. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . 21 80 9.4. Application Service & Application Protocol Tags . . . . . 21 81 9.4.1. DOTS Application Service Tag Registration . . . . . . 21 82 9.4.2. DOTS Call Home Application Service Tag Registration . 21 83 9.4.3. signal.udp Application Protocol Tag Registration . . 22 84 9.4.4. signal.tcp Application Protocol Tag Registration . . 22 85 9.4.5. data.tcp Application Protocol Tag Registration . . . 22 86 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 90 12.2. Informative References . . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 93 1. Introduction 95 DDoS Open Threat Signaling (DOTS) [RFC8811] specifies an 96 architecture, in which a DOTS client can inform a DOTS server that 97 the network is under a potential attack and that appropriate 98 mitigation actions are required. Indeed, because the lack of a 99 common method to coordinate a real-time response among involved 100 actors and network domains inhibits the effectiveness of DDoS attack 101 mitigation, the DOTS signal channel protocol [RFC8782] is meant to 102 carry requests for DDoS attack mitigation. With this approach, DOTS 103 can reduce the impact of an attack and lead to more efficient 104 defensive actions in various deployment scenarios such as those 105 discussed in [I-D.ietf-dots-use-cases]. Moreover, DOTS clients can 106 instruct a DOTS server to install named filtering rules by means of 107 the DOTS data channel protocol [RFC8783]. 109 The basic high-level DOTS architecture is illustrated in Figure 1. 111 +-----------+ +-------------+ 112 | Mitigator | ~~~~~~~~~~ | DOTS Server | 113 +-----------+ +------+------+ 114 | 115 | 116 | 117 +---------------+ +------+------+ 118 | Attack Target | ~~~~~~ | DOTS Client | 119 +---------------+ +-------------+ 121 Figure 1: Basic DOTS Architecture 123 [RFC8811] specifies that the DOTS client may be provided with a list 124 of DOTS servers, each associated with one or more IP addresses. 125 These addresses may or may not be of the same address family. The 126 DOTS client establishes one or more DOTS sessions by connecting to 127 the provided DOTS server addresses. 129 This document specifies methods for DOTS clients to discover their 130 DOTS server(s). The rationale for specifying multiple discovery 131 mechanisms is discussed in Section 3. 133 The discovery methods can also be used by a DOTS server to locate a 134 DOTS client in the context of DOTS Signal Channel Call Home 135 [I-D.ietf-dots-signal-call-home]. The basic high-level DOTS Call 136 Home architecture is illustrated in Figure 2. 138 +---------------+ +-------------+ 139 | Alert | ~~~~~~ | Call Home | 140 | | | DOTS client | 141 +---------------+ +------+------+ 142 | 143 | 144 | 145 +---------------+ +------+------+ 146 | Attack | ~~~~~~ | Call Home | 147 | Source(s) | | DOTS server | 148 +---------------+ +-------------+ 150 Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture 152 A DOTS agent may be used to establish base DOTS channels, DOTS Call 153 Home, or both. This specification accommodates all these deployment 154 cases. 156 Considerations for the selection of DOTS server(s) by multi-homed 157 DOTS clients are out of this document scope; readers should refer to 158 [I-D.ietf-dots-multihoming] for more details. 160 This document assumes that security credentials to authenticate DOTS 161 server(s) are pre-provisioned to a DOTS client using a mechanism such 162 as (but not limited to) those discussed in [RFC8572] or 163 [I-D.ietf-anima-bootstrapping-keyinfra]. DOTS clients use those 164 credentials for authentication purposes following the rules 165 documented in [RFC8782]. 167 2. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in BCP 172 14 [RFC2119][RFC8174] when, and only when, they appear in all 173 capitals, as shown here. 175 The reader should be familiar with the terms defined in [RFC3958]. 177 DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC8415]. 179 "DOTS client" refers to a DOTS-aware software module responsible for 180 requesting attack response coordination with other DOTS-aware 181 elements. 183 "DOTS server" is a DOTS-aware software module handling and responding 184 to messages from DOTS clients. The DOTS server enables mitigation on 185 behalf of the DOTS client, if requested, by communicating the DOTS 186 client's request to the mitigator and returning selected mitigator 187 feedback to the requesting DOTS client. 189 "Call Home DOTS client" (or "Call Home DOTS server") refers to a DOTS 190 client (or DOTS server) deployed in a Call Home scenario (Figure 2). 192 "DOTS agent" is any DOTS-aware software module capable of 193 participating in a DOTS channel. 195 "Peer DOTS agent" refers to the peer DOTS server (base DOTS 196 operation) or to a peer Call Home DOTS client (for DOTS Signal 197 Channel Call Home). 199 3. Why Multiple Discovery Mechanisms? 201 Analysis of the various use cases sketched in 202 [I-D.ietf-dots-use-cases] reveals that it is unlikely that one single 203 discovery method can be suitable for all the sample deployments. 204 Concretely: 206 o Many of the use cases discussed in [I-D.ietf-dots-use-cases] do 207 involve a Customer Premises Equipment (CPE) device. Multiple 208 CPEs, connected to distinct network providers, may even be 209 considered. It is intuitive to leverage existing mechanisms such 210 as discovery using service resolution or DHCP to provision the CPE 211 acting as a DOTS client with the DOTS server(s). 213 o Resolving a DOTS server domain name offered by an upstream transit 214 provider provisioned to a DOTS client into IP address(es) requires 215 the use of the appropriate DNS resolvers; otherwise, resolving 216 those names will fail. The use of protocols such as DHCP does 217 allow associating provisioned DOTS server domain names with a list 218 of DNS servers to be used for name resolution. Furthermore, DHCP 219 allows directly providing IP addresses therefore avoiding the need 220 for extra lookup delays. 222 o Some of the use cases may allow DOTS clients to have direct 223 communications with upstream DOTS servers, that is, no DOTS 224 gateway is involved. Leveraging existing protocol behaviors that 225 do not require specific features on the node embedding the DOTS 226 client may ease DOTS deployment. Typically, the use of 227 Straightforward-Naming Authority Pointer (S-NAPTR) lookups 228 [RFC3958] allows the DOTS server administrators to provision the 229 preferred DOTS transport protocol between the DOTS client and the 230 DOTS server and allows the DOTS client to discover this 231 preference. 233 o The upstream network provider is not the DDoS mitigation provider 234 for some of these use cases. It is safe to assume that for such 235 deployments, the DOTS server(s) domain name is provided during the 236 service subscription (i.e., manual/local configuration). 238 o Multiple DOTS clients may be enabled within a network (e.g., 239 enterprise network). Dynamic discovery needs to be deterministic 240 from an operational standpoint. 242 o Some of the use cases may involve a DOTS gateway that is 243 responsible for selecting the appropriate DOTS server(s) to relay 244 requests received from DOTS clients. 246 Consequently, this document describes a unified discovery logic 247 (Section 4) which involves the following mechanisms: 249 o Dynamic discovery using DHCP (Section 5). 251 o A resolution mechanism based on Straightforward Naming Authority 252 Pointer (S-NAPTR) resource records in the Domain Name System (DNS) 253 (Section 6). 255 o DNS Service Discovery (Section 7). 257 4. DOTS Discovery Procedure 259 Operators will need a consistent set of ways in which DOTS clients 260 can discover this information and a consistent priority among these 261 options. If some devices prefer manual configuration over dynamic 262 discovery, while others prefer dynamic discovery over manual 263 configuration, the result will be a process where the operator must 264 find devices that are using the wrong DOTS server(s), determine how 265 to ensure the devices are configured properly, and then reconfigure 266 the device through the preferred method. 268 All DOTS clients MUST support at least one of the three mechanisms 269 below to determine a DOTS server list. All DOTS clients SHOULD 270 implement all three, or as many as are practical for any specific 271 device, of the following ways to discover DOTS servers in order to 272 facilitate the deployment of DOTS in large scale environments. For 273 example, a CPE will support the first two mechanisms, a host within a 274 LAN will support the last two mechanisms, or an application server 275 will support a local configuration. More examples are discussed in 276 Section 3. DOTS clients will prefer information received from the 277 discovery methods in the order listed below. 279 1. Explicit configuration: 281 * Local/Manual configuration: A DOTS client will learn the DOTS 282 server(s) by means of local or manual DOTS configuration 283 (i.e., DOTS servers configured at the system level). 284 Configuration discovered from a DOTS client application is 285 considered as local configuration. 287 An implementation may give the user an opportunity (e.g., by 288 means of configuration file options or menu items) to specify 289 DOTS server(s) for each address family. These may be 290 specified either as a list of IP addresses or the DNS name of 291 a DOTS server. When only DOTS server IP addresses are 292 configured, a reference identifier must also be configured for 293 authentication purposes. 295 * Automatic configuration (e.g., DHCP): The DOTS client attempts 296 to discover DOTS server(s) names and/or addresses from DHCP, 297 as described in Section 5. 299 2. Service Resolution : The DOTS client attempts to discover DOTS 300 server name(s) using service resolution, as specified in 301 Section 6. 303 3. DNS SD: DNS Service Discovery. The DOTS client attempts to 304 discover DOTS server name(s) using DNS service discovery, as 305 specified in Section 7. 307 Some of these mechanisms imply the use of DNS to resolve the IP 308 address(es) of the DOTS server, while others imply an IP address of 309 the relevant DOTS server is obtained directly. Implementation 310 options may vary on a per device basis, as some devices may not have 311 DNS capabilities and/or suitable DNS configuration. 313 On hosts with more than one interface or address family (IPv4/IPv6), 314 the DOTS server discovery procedure has to be performed for each 315 interface/address-family combination. A DOTS client may choose to 316 perform the discovery procedure only for a desired interface/address 317 combination if the client does not wish to discover a DOTS server for 318 all interface/address-family combinations. 320 This procedure is also followed by a Call Home DOTS server to 321 discover its Call Home DOTS client in the context of 322 [I-D.ietf-dots-signal-call-home]. 324 The discovery method is performed upon bootstrapping of a DOTS agent, 325 and is reiterated by the DOTS agent upon the following events: 327 o Expiry of a validity timer (e.g., DHCP lease, DHCP information 328 refresh time, DNS TTL) associated with a discovered DOTS agent. 330 o Expiry of the certificate of a peer DOTS agent currently in use. 332 o Attachment to a new network. 334 5. DHCP Options for DOTS Agent Discovery 336 As reported in Section 1.7.2 of [RFC6125]: 338 "Some certification authorities issue server certificates based on 339 IP addresses, but preliminary evidence indicates that such 340 certificates are a very small percentage (less than 1%) of issued 341 certificates". 343 In order to allow for PKIX-based authentication between a DOTS client 344 and server while accommodating the current best practices for issuing 345 certificates, this document allows DOTS agents to retrieve the names 346 of their peer DOTS agents. These names can be used for two purposes: 347 to retrieve the list of IP addresses of a peer DOTS agent or to be 348 presented as a reference identifier for authentication purposes. 350 Defining the option to include a list of IP addresses would avoid a 351 dependency on an underlying name resolution, but that design requires 352 also supplying a name for PKIX-based authentication purposes. 354 Given that DOTS gateways can be involved in a DOTS session, a peer 355 DOTS agent can be reachable using a link-local address. Such 356 addresses can also be discovered using the options defined in 357 Section 5.1. 359 The list of the IP addresses returned by DHCP servers is typically 360 used to feed the DOTS server selection procedure including when DOTS 361 agents are provided with primary and backup IP addresses of their 362 peer DOTS agents. An example of DOTS server selection procedure is 363 specified in Section 4.3 of [RFC8782]. 365 The design assumes that the same peer DOTS agent is used for 366 establishing both signal and data channels. For more customized 367 configurations (e.g., transport-specific configuration, distinct DOTS 368 servers for the signal and the data channels), an operator can supply 369 only a DOTS reference identifier that will be then passed to the 370 procedure described in Section 6. 372 The design allows terminating the base DOTS channels and DOTS Call 373 Home on the same or distinct peer DOTS agents. If distinct peer DOTS 374 agents are deployed, the DHCP option can return, for example, a list 375 of IP addresses to a requesting DOTS agent. This list includes the 376 IP address to be used for the base DOTS channels and the IP address 377 for the DOTS Call Home. The DOTS client (or Call Home DOTS server) 378 will then use the address selection procedure specified in 379 Section 4.3 of [RFC8782] to identify the IP address of the peer DOTS 380 server (or Call Home DOTS client). For example: 382 Let's consider that the DOTS server is reachable at 383 2001:db8:122:300::1 while the Call Home DOTS client is reachable 384 at 2001:db8:122:300::2. The DHCP server will then return one DOTS 385 reference identifier and a list that includes both 386 2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP 387 client. That list is passed to the DOTS client (or Call Home DOTS 388 server) which will try to establish connections to the addresses 389 of that list and destination port number 4646 (or the Call Home 390 port number). As a result, the DOTS client (or Call Home DOTS 391 server) will select 2001:db8:122:300::1 (or 2001:db8:122:300::2) 392 as a DOTS server (or Call Home DOTS client). 394 5.1. DHCPv6 DOTS Options 396 5.1.1. Format of DOTS Reference Identifier Option 398 The DHCPv6 DOTS Reference Identifier option is used to configure a 399 name of the DOTS server (or the name of the Call Home DOTS client). 400 The format of this option is shown in Figure 3. 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | OPTION_V6_DOTS_RI | Option-length | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | | 407 | dots-agent-name (FQDN) | 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 3: DHCPv6 DOTS Reference Identifier Option 413 The fields of the option shown in Figure 3 are as follows: 415 o Option-code: OPTION_V6_DOTS_RI (TBA1, see Section 9.2) 416 o Option-length: Length of the dots-agent-name field in octets. 417 o dots-agent-name: A fully qualified domain name of the peer DOTS 418 agent. This field is formatted as specified in Section 10 of 419 [RFC8415]. 421 An example of the dots-agent-name encoding is shown in Figure 4. 422 This example conveys the FQDN "dots.example.com.", and the resulting 423 Option-length field is 18. 425 +------+------+------+------+------+------+------+------+------+ 426 | 0x04 | d | o | t | s | 0x07 | e | x | a | 427 +------+------+------+------+------+------+------+------+------+ 428 | m | p | l | e | 0x03 | c | o | m | 0x00 | 429 +------+------+------+------+------+------+------+------+------+ 431 Figure 4: An example of the dots-agent-name Encoding 433 5.1.2. Format of DOTS Address Option 435 The DHCPv6 DOTS Address option can be used to configure a list of 436 IPv6 addresses of a DOTS server (or a Call Home DOTS client). The 437 format of this option is shown in Figure 5. 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | OPTION_V6_DOTS_ADDRESS | Option-length | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | | 444 | DOTS ipv6-address | 445 | | 446 | | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 | DOTS ipv6-address | 450 | | 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | ... | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Figure 5: DHCPv6 DOTS Address Option 458 The fields of the option shown in Figure 5 are as follows: 460 o Option-code: OPTION_V6_DOTS_ADDRESS (TBA2, see Section 9.2) 461 o Option-length: Length of the 'DOTS ipv6-address(es)' field in 462 octets. MUST be a multiple of 16. 463 o DOTS ipv6-address(es): Includes one or more IPv6 addresses 464 [RFC4291] of the peer DOTS agent to be used by a DOTS agent for 465 establishing a DOTS session. The addresses are listed in the 466 order of preference for use by the DOTS agent. 468 Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) 469 may be included in this option when there is no DHCPv4 server able 470 to advertise the DHCPv4 DOTS options (Section 5.2) and when only 471 IPv4 connectivity is possible to the peer DOTS agent. 473 5.1.3. DHCPv6 Client Behavior 475 DHCP clients MAY request options OPTION_V6_DOTS_RI and 476 OPTION_V6_DOTS_ADDRESS, as defined in [RFC8415], Sections 18.2.1, 477 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. As a convenience to the 478 reader, it is mentioned here that the DHCP client includes the 479 requested option codes in the Option Request Option. 481 If the DHCP client receives more than one instance of 482 OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use 483 only the first instance of that option. 485 The DHCP client MUST silently discard multicast and host loopback 486 addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS. 488 If the DHCP client receives and validates both OPTION_V6_DOTS_RI and 489 OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 490 the reference identifier for authentication purposes (e.g., PKIX 491 [RFC6125]), while the valid addresses included in 492 OPTION_V6_DOTS_ADDRESS are used to reach the peer DOTS agent. In 493 other words, the name conveyed in OPTION_V6_DOTS_RI MUST NOT be 494 passed to an underlying resolution library in the presence of valid 495 OPTION_V6_DOTS_ADDRESS in a response. 497 If the DHCP client receives OPTION_V6_DOTS_RI only, but 498 OPTION_V6_DOTS_RI contains more than one name, the DHCP client MUST 499 use only the first name. Once the name is validated (Section 10 of 500 [RFC8415]), the name is passed to a name resolution library. 501 Moreover, that name is also used as a reference identifier for 502 authentication purposes. 504 If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the 505 address(es) included in OPTION_V6_DOTS_ADDRESS are used to reach the 506 peer DOTS agent. In addition, these addresses can be used as 507 identifiers for authentication. 509 5.2. DHCPv4 DOTS Options 511 5.2.1. Format of DOTS Reference Identifier Option 513 The DHCPv4 [RFC2132] DOTS Reference Identifier option is used to 514 configure a name of the peer DOTS agent. The format of this option 515 is illustrated in Figure 6. 517 Code Length Peer DOTS agent name 518 +-----+-----+-----+-----+-----+-----+-----+-- 519 |TBA3 | n | s1 | s2 | s3 | s4 | s5 | ... 520 +-----+-----+-----+-----+-----+-----+-----+-- 522 The values s1, s2, s3, etc. represent the domain name labels in the 523 domain name encoding. 525 Figure 6: DHCPv4 DOTS Reference Identifier Option 527 The fields of the option shown in Figure 6 are as follows: 529 o Code: OPTION_V4_DOTS_RI (TBA3, see Section 9.3). 530 o Length: Includes the length of the "Peer DOTS agent name" field in 531 octets. 532 o Peer DOTS agent name: The domain name of the peer DOTS agent. 533 This field is formatted as specified in Section 10 of [RFC8415]. 535 5.2.2. Format of DOTS Address Option 537 The DHCPv4 DOTS Address option can be used to configure a list of 538 IPv4 addresses of a peer DOTS agent. The format of this option is 539 illustrated in Figure 7. 541 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Code=TBA4 | Length | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | | 546 + DOTS IPv4 Address | 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 549 | | | 550 + DOTS IPv4 Address | | 551 | | optional 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 553 . ... . | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 556 Figure 7: DHCPv4 DOTS Address Option 558 The fields of the option shown in Figure 7 are as follows: 560 o Code: OPTION_V4_DOTS_ADDRESS (TBA4, see Section 9.3). 561 o Length: is set to 4*N, where N is the number of IPv4 addresses 562 included in the option. 564 o DOTS IPv4 Address(es): Contains one or more IPv4 addresses of the 565 peer DOTS agent to be used by a DOTS agent. The addresses are 566 listed in the order of preference for use by the DOTS agent. 568 OPTION_V4_DOTS_ADDRESS is a concatenation-requiring option. As such, 569 the mechanism specified in [RFC3396] MUST be used if 570 OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255 571 octets. 573 5.2.3. DHCPv4 Client Behavior 575 To discover a peer DOTS agent, the DHCPv4 client MUST include both 576 OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request 577 List Option [RFC2132]. 579 If the DHCP client receives more than one instance of 580 OPTION_V4_DOTS_RI option, it MUST use only the first instance of that 581 option. 583 The DHCP client MUST silently discard multicast and host loopback 584 addresses [RFC6890] conveyed in OPTION_V4_DOTS_ADDRESS. 586 If the DHCP client receives and validates both OPTION_V4_DOTS_RI and 587 OPTION_V4_DOTS_ADDRESS, the content of OPTION_V4_DOTS_RI is used as 588 the reference identifier for authentication purposes (e.g., PKIX 589 [RFC6125]), while the valid addresses included in 590 OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS agent. In 591 other words, the name conveyed in OPTION_V4_DOTS_RI MUST NOT be 592 passed to underlying resolution library in the presence of valid 593 OPTION_V4_DOTS_ADDRESS in a response. 595 If the DHCP client receives OPTION_V4_DOTS_RI only, but 596 OPTION_V4_DOTS_RI option contains more than one name, as 597 distinguished by the presence of multiple root labels, the DHCP 598 client MUST use only the first name. Once the name is validated 599 (Section 10 of [RFC8415]), the name is passed to a name resolution 600 library. Moreover, that name is also used as a reference identifier 601 for authentication purposes. 603 If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the 604 address(es) included in OPTION_V4_DOTS_ADDRESS are used to reach the 605 peer DOTS server. In addition, these addresses can be used as 606 identifiers for authentication. 608 6. Discovery using Service Resolution 610 This mechanism is performed in two steps: 612 1. A DNS domain name is retrieved for each combination of interface 613 and address family. A DOTS agent has to determine the domain in 614 which it is located relying on dynamic means such as DHCP 615 (Section 5). Implementations may allow the user to specify a 616 default name that is used, if no specific name has been 617 configured. 619 2. Retrieved DNS domain names are then used for S-NAPTR lookups 620 [RFC3958]. Further DNS lookups may be necessary to determine the 621 peer DOTS agent IP address(es). 623 Once the DOTS agent has retrieved its DNS domain or discovered the 624 peer DOTS agent name that needs to be resolved, an S-NAPTR lookup 625 with the appropriate application service and the desired protocol tag 626 is made to obtain information necessary to connect to the 627 authoritative peer DOTS agent within the given domain. 629 This specification defines 'DOTS' and 'DOTS-CALL-HOME' as application 630 service tags (Sections 9.4.1 and 9.4.2). It also defines 631 "signal.udp" (Section 9.4.3), "signal.tcp" (Section 9.4.4), and 632 "data.tcp" (Section 9.4.5) as application protocol tags. An example 633 is provided in Figure 8. 635 In the example below, for domain 'example.net', the resolution 636 algorithm will result in IP address(es), port, tag, and protocol 637 tuples listed in Table 1. 639 example.net. 640 IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. 641 IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. 642 IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net. 644 signal.example.net. 645 IN NAPTR 100 10 "s" DOTS:signal.udp "" _dots-signal._udp.example.net. 646 IN NAPTR 200 10 "s" DOTS:signal.tcp "" _dots-signal._tcp.example.net. 648 data.example.net. 649 IN NAPTR 100 10 "s" DOTS:data.tcp "" _dots-data._tcp.example.net. 650 IN NAPTR 200 10 "a" DOTS:data.tcp "" b.example.net. 652 _dots-signal._udp.example.net. 653 IN SRV 0 0 5000 a.example.net. 655 _dots-signal._tcp.example.net. 656 IN SRV 0 0 5001 a.example.net. 658 _dots-data._tcp.example.net. 659 IN SRV 0 0 5002 a.example.net. 661 a.example.net. 662 IN AAAA 2001:db8::1 664 b.example.net. 665 IN AAAA 2001:db8::2 667 Figure 8: Example of Discovery of DOTS Servers using Service 668 Resolution 670 +-------+----------+-------------+------+--------+ 671 | Order | Protocol | IP address | Port | Tag | 672 +-------+----------+-------------+------+--------+ 673 | 1 | UDP | 2001:db8::1 | 5000 | Signal | 674 | 2 | TCP | 2001:db8::1 | 5001 | Signal | 675 | 3 | TCP | 2001:db8::1 | 5002 | Data | 676 | 4 | TCP | 2001:db8::2 | 443 | Data | 677 +-------+----------+-------------+------+--------+ 678 Table 1: Resolution Results 680 An example is provided in Figure 9 for the Call Home case. In this 681 example, the resolution algorithm will result in IP address(es), 682 port, and protocol listed in Table 2 for domain 'example.net'. 684 example.net. 685 IN NAPTR 100 10 "" DOTS-CALL-HOME:signal.udp "" signal.example.net. 686 IN NAPTR 200 10 "" DOTS-CALL-HOME:signal.tcp "" signal.example.net. 688 signal.example.net. 689 IN NAPTR 100 10 "s" DOTS-CALL-HOME:signal.udp "" 690 _dots-call-home._udp.example.net. 691 IN NAPTR 200 10 "s" DOTS-CALL-HOME:signal.tcp "" 692 _dots-call-home._tcp.example.net. 694 _dots-call-home._udp.example.net. 695 IN SRV 0 0 6000 b.example.net. 697 _dots-call-home._tcp.example.net. 698 IN SRV 0 0 6001 b.example.net. 700 b.example.net. 701 IN AAAA 2001:db8::2 703 Figure 9: Example of Discovery of DOTS Call Home Client using Service 704 Resolution 706 +-------+----------+-------------+------+ 707 | Order | Protocol | IP address | Port | 708 +-------+----------+-------------+------+ 709 | 1 | UDP | 2001:db8::2 | 6000 | 710 | 2 | TCP | 2001:db8::2 | 6001 | 711 +-------+----------+-------------+------+ 712 Table 2: Resolution Results (Call Home) 714 Note that customized port numbers are used for the DOTS signal 715 channel, DOTS data channel, and DOTS signal channel call home in the 716 examples shown in Figures 8 and 9 for illustration purposes. If 717 default port numbers are used in a deployment, the discovery 718 procedure will return 4646 (DOTS signal channel) and 443 (DOTS data 719 channel) as DOTS service port numbers. 721 If no DOTS-specific S-NAPTR records can be retrieved, the discovery 722 procedure fails for this domain name (and the corresponding interface 723 and IP protocol version). If more domain names are known, the 724 discovery procedure MAY perform the corresponding S-NAPTR lookups 725 immediately. However, before retrying a lookup that has failed, a 726 DOTS client MUST wait a time period that is appropriate for the 727 encountered error (e.g., NXDOMAIN, timeout, etc.). 729 7. DNS Service Discovery 731 DNS-based Service Discovery (DNS-SD) [RFC6763] provides generic 732 solutions for discovering services. DNS-SD defines a set of naming 733 rules for certain DNS record types that they use for advertising and 734 discovering services. 736 Section 4.1 of [RFC6763] specifies that a service instance name in 737 DNS-SD has the following structure: 739 . . 741 The portion specifies the DNS sub-domain where the service 742 instance is registered. It is a conventional domain name such as 743 "example.com.". 745 The portion of the DOTS service instance name MUST be 746 "_dots-signal._udp" or "_dots-signal._tcp" or "_dots-data._tcp" or 747 "_dots-call-home._udp" or "_dots-call-home._tcp". 749 This document does not define any keys; the TXT record of a DNS-SD 750 service is thus empty (Section 6 of [RFC6763]). 752 Figure 10 depicts an excerpt of the DNS zone configuration file 753 listing record examples to discover two DOTS signal channel servers. 754 In this example, only UDP is supported as transport for the 755 establishment of the DOTS signal channel. 757 _dots-signal._udp.example.net. PTR a._dots-signal._udp.example.net. 758 _dots-signal._udp.example.net. PTR b._dots-signal._udp.example.net. 759 a._dots-signal._udp.example.net. SRV 0 0 4646 a.example.net. 760 b._dots-signal._udp.example.net. SRV 0 0 4646 b.example.net. 761 a._dots-signal._udp.example.net. TXT "" 762 b._dots-signal._udp.example.net. TXT "" 764 Figure 10: An Example of DNS-SD Records for the UDP DOTS Signal 765 Channel involving Two Servers with the Same Priority. 767 8. Security Considerations 769 DOTS-related security considerations are discussed in Section 4 of 770 [RFC8811]. As a reminder, DOTS agents must authenticate each other 771 using (D)TLS before a DOTS session is considered valid according to 772 the [RFC8782]. 774 An attacker may block some protocol messages (e.g., DHCP) to force 775 the client to use a discovery mechanism with a lower priority. The 776 security implications of such attack are those inherent to the 777 fallback discovery mechanism discussed in the following subsections. 779 The results of the discovery procedure are a function of the 780 interface/address family. Contacting a discovered DOTS server via an 781 interface to which it is not bound may exacerbate the delay required 782 to establish a DOTS channel. Moreover, such behavior may reveal that 783 a DOTS service is enabled by a DOTS client domain and exposes the 784 identity of the DOTS service provider (that can be inferred from the 785 name and the destination IP address) to external networks. 787 Security considerations related to how security credentials to 788 authenticate DOTS server(s) are provisioned to a DOTS client are 789 those inherent to the mechanism used for that purpose (see for 790 example, [RFC8572]). 792 8.1. DHCP 794 The security considerations in [RFC2131] and [RFC8415] are to be 795 considered. In particular, issues related to rogue DHCP servers and 796 means to mitigate many of these attacks are discussed in Section 22 797 of [RFC8415]. 799 An attacker can get a domain name, domain-validated public 800 certificate from a CA, and host a DOTS agent. An active attacker can 801 then spoof DHCP responses to include the attacker's DOTS agent. Such 802 an attacker can also launch other attacks as discussed in Section 22 803 of [RFC8415]. In addition to the mitigations listed in Section 22 of 804 [RFC8415], a DOTS agent may be pre-configured with a list of trusted 805 DOTS domain names. If such a list is pre-configured, a DOTS agent 806 will accept a DHCP-discovered name if it matches a name in that list. 807 Also, the DOTS agent has to check that the 'DNS-ID' identifier type 808 within subjectAltName in the server certificate matches a pre- 809 configured name. If the DOTS agent is instructed to trust subdomains 810 of the names in that list as well (e.g., "*.example.com"), a DOTS 811 agent will accept a DHCP-discovered name that matches a name in the 812 pre-configured list (e.g., "dots-1.example.com" or "dots- 813 2.example.com"). 815 Relying on an underlying resolution library to resolve a supplied 816 reference identifier has similar security issues as those discussed 817 in Section 8.2 (e.g., an active attacker may modify DNS messages used 818 to resolve the supplied reference identifier and point the client to 819 an attacker server). 821 Supplying both an IP address and the reference identifier makes it 822 easier to use a mis-issued certificate. 824 8.2. Service Resolution 826 The primary attack against the methods described in Section 6 is one 827 that would lead to impersonation of a peer DOTS agent. An attacker 828 could attempt to compromise the S-NAPTR resolution. 830 The DOTS client (or a Call Home DOTS server) constructs one reference 831 identifier for the DOTS server (or a Call Home DOTS client) based on 832 the domain name which is used for S-NAPTR lookup: DNS-ID. If the 833 reference identifier is found (as described in Section 6 of 834 [RFC6125]) in the PKIX certificate's subjectAltName extension, the 835 DOTS client should accept the certificate for the server. 837 DNS Security Extensions (DNSSEC) [RFC4033] uses cryptographic keys 838 and digital signatures to provide authentication of DNS data. The 839 information that is retrieved from the S-NAPTR lookup and that is 840 validated using DNSSEC is thereby proved to be the authoritative 841 data. 843 8.3. DNS Service Discovery 845 Since DNS-SD is a specification for how to name and use records in 846 the existing DNS system, it has no specific additional security 847 requirements over and above those that already apply to DNS queries 848 and DNS updates. For DNS queries, DNSSEC SHOULD be used where the 849 authenticity of information is important. For DNS updates, secure 850 updates [RFC2136][RFC3007] SHOULD generally be used to control which 851 clients have permission to update DNS records. 853 Note that means such as DNS over TLS (DoT) [RFC7858] or DNS over 854 HTTPS (DoH) [RFC8484] can be used to prevent eavesdroppers from 855 accessing DNS messages. 857 9. IANA Considerations 859 9.1. The Service Name and Transport Protocol Port Number Registry 861 IANA is requested to allocate the following service names from the 862 registry available at: https://www.iana.org/assignments/service- 863 names-port-numbers/service-names-port-numbers.xhtml. 865 Service Name: dots-data 866 Port Number: N/A 867 Transport Protocol(s): TCP 868 Description: DOTS Data Channel Protocol 869 The service name is used to construct the 870 SRV service name "_dots-data._tcp" for 871 discovering DOTS servers used to establish 872 DOTS data channel. 873 Assignee: IESG 874 Contact: IETF Chair 875 Reference: [ThisDocument] 877 Service Name: dots-call-home 878 Transport Protocol(s): TCP/UDP 879 Description: DOTS Signal Channel Call Home Protocol. 880 The service name is used to construct the 881 SRV service names "_dots-call-home._udp" 882 and "_dots-call-home._tcp" for discovering 883 Call Home DOTS clients used to establish 884 DOTS signal channel call home. 885 Assignee: IESG 886 Contact: IETF Chair 887 Reference: [ThisDocument] 889 IANA is requested to update the following entry from the registry 890 available at: https://www.iana.org/assignments/service-names-port- 891 numbers/service-names-port-numbers.xhtml. 893 Service Name: dots-signal 894 Port Number: 4646 895 Transport Protocol(s): TCP/UDP 896 Description: DOTS Signal Channel Protocol. 897 The service name is used to construct the 898 SRV service names "_dots-signal._udp" and 899 "_dots-signal._tcp" for discovering DOTS 900 servers used to establish DOTS signal 901 channel. 902 Assignee: IESG 903 Contact: IETF Chair 904 Reference: [RFC8782][ThisDocument] 906 9.2. DHCPv6 Options 908 IANA is requested to assign the following new DHCPv6 Option Codes in 909 the registry maintained in: https://www.iana.org/assignments/dhcpv6- 910 parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. 912 Value Description Client ORO Singleton Option 913 TBA1 OPTION_V6_DOTS_RI Yes Yes 914 TBA2 OPTION_V6_DOTS_ADDRESS Yes Yes 916 9.3. DHCPv4 Options 918 IANA is requested to assign the following new DHCPv4 Option Codes in 919 the registry maintained in: https://www.iana.org/assignments/bootp- 920 dhcp-parameters/bootp-dhcp-parameters.xhtml#options. 922 Name Tag Data Meaning Reference 923 Length 924 ---------------------- ---- ---------- --------------- -------------- 925 OPTION_V4_DOTS_RI TBA3 N The name of the [ThisDocument] 926 peer DOTS 927 agent. 928 OPTION_V4_DOTS_ADDRESS TBA4 N (the N/4 IPv4 [ThisDocument] 929 minimal addresses of 930 length is peer DOTS 931 4) agent(s). 933 9.4. Application Service & Application Protocol Tags 935 This document requests IANA to make the following allocations from 936 the registries available at: https://www.iana.org/assignments/s- 937 naptr-parameters/s-naptr-parameters.xhtml#s-naptr-parameters-1 for 938 Application Service Tags and https://www.iana.org/assignments/s- 939 naptr-parameters/s-naptr-parameters.xhtml#s-naptr-parameters-2 for 940 Application Protocol Tags. 942 9.4.1. DOTS Application Service Tag Registration 944 o Application Service Tag: DOTS 946 o Intended Usage: See Section 6 948 o Security Considerations: See Section 8 950 o Interoperability considerations: None 952 o Relevant publications: This document 954 9.4.2. DOTS Call Home Application Service Tag Registration 956 o Application Service Tag: DOTS-CALL-HOME 958 o Intended Usage: See Section 6 959 o Security Considerations: See Section 8 961 o Interoperability considerations: None 963 o Relevant publications: This document 965 9.4.3. signal.udp Application Protocol Tag Registration 967 o Application Protocol Tag: signal.udp 969 o Intended Usage: See Section 6 971 o Security Considerations: See Section 8 973 o Interoperability considerations: None 975 o Relevant publications: This document 977 9.4.4. signal.tcp Application Protocol Tag Registration 979 o Application Protocol Tag: signal.tcp 981 o Intended Usage: See Section 6 983 o Security Considerations: See Section 8 985 o Interoperability considerations: None 987 o Relevant publications: This document 989 9.4.5. data.tcp Application Protocol Tag Registration 991 o Application Protocol Tag: data.tcp 993 o Intended Usage: See Section 6 995 o Security Considerations: See Section 8 997 o Interoperability considerations: None 999 o Relevant publications: This document 1001 10. Contributors 1003 Prashanth Patil 1004 Cisco Systems, Inc. 1006 Email: praspati@cisco.com 1008 11. Acknowledgements 1010 Thanks to Brian Carpenter for the review of the BRSKI text used be in 1011 previous versions of the specification. 1013 Many thanks to Russ White for the review, comments, and text 1014 contribution. 1016 Thanks to Dan Wing, Pei Wei, Valery Smyslov, and Jon Shallow for the 1017 review and comments. 1019 Thanks to Bernie Volz for the review of the DHCP section. 1021 Many thanks to Benjamin Kaduk for the detailed AD review. 1023 Thanks to Zhen Cao, Kyle Rose, Nagendra Nainar, and Peter Yee for the 1024 directorate reviews. 1026 Thanks to Barry Leiba, Martin Duke, Roman Danyliw, Eric Vyncke, and 1027 Magnus Westerlund for the IESG review. 1029 12. References 1031 12.1. Normative References 1033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1034 Requirement Levels", BCP 14, RFC 2119, 1035 DOI 10.17487/RFC2119, March 1997, 1036 . 1038 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1039 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1040 . 1042 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1043 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1044 . 1046 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 1047 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 1048 DOI 10.17487/RFC3396, November 2002, 1049 . 1051 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 1052 Service Location Using SRV RRs and the Dynamic Delegation 1053 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 1054 January 2005, . 1056 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1057 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1058 2006, . 1060 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1061 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1062 . 1064 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1065 "Special-Purpose IP Address Registries", BCP 153, 1066 RFC 6890, DOI 10.17487/RFC6890, April 2013, 1067 . 1069 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1070 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1071 May 2017, . 1073 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1074 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1075 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1076 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1077 . 1079 12.2. Informative References 1081 [I-D.ietf-anima-bootstrapping-keyinfra] 1082 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1083 and K. Watsen, "Bootstrapping Remote Secure Key 1084 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1085 keyinfra-45 (work in progress), November 2020. 1087 [I-D.ietf-dots-multihoming] 1088 Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing 1089 Deployment Considerations for Distributed-Denial-of- 1090 Service Open Threat Signaling (DOTS)", draft-ietf-dots- 1091 multihoming-04 (work in progress), May 2020. 1093 [I-D.ietf-dots-signal-call-home] 1094 Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed 1095 Denial-of-Service Open Threat Signaling (DOTS) Signal 1096 Channel Call Home", draft-ietf-dots-signal-call-home-11 1097 (work in progress), October 2020. 1099 [I-D.ietf-dots-use-cases] 1100 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 1101 L., and K. Nishizuka, "Use cases for DDoS Open Threat 1102 Signaling", draft-ietf-dots-use-cases-25 (work in 1103 progress), July 2020. 1105 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1106 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1107 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1108 . 1110 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1111 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 1112 . 1114 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1115 Rose, "DNS Security Introduction and Requirements", 1116 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1117 . 1119 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1120 Verification of Domain-Based Application Service Identity 1121 within Internet Public Key Infrastructure Using X.509 1122 (PKIX) Certificates in the Context of Transport Layer 1123 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1124 2011, . 1126 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1127 and P. Hoffman, "Specification for DNS over Transport 1128 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1129 2016, . 1131 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1132 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1133 . 1135 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1136 Touch Provisioning (SZTP)", RFC 8572, 1137 DOI 10.17487/RFC8572, April 2019, 1138 . 1140 [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., 1141 Mortensen, A., and N. Teague, "Distributed Denial-of- 1142 Service Open Threat Signaling (DOTS) Signal Channel 1143 Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, 1144 . 1146 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 1147 Denial-of-Service Open Threat Signaling (DOTS) Data 1148 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 1149 May 2020, . 1151 [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., 1152 Teague, N., and R. Compton, "DDoS Open Threat Signaling 1153 (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, 1154 August 2020, . 1156 Authors' Addresses 1158 Mohamed Boucadair 1159 Orange 1160 Rennes 35000 1161 France 1163 Email: mohamed.boucadair@orange.com 1165 Tirumaleswar Reddy 1166 McAfee, Inc. 1167 Embassy Golf Link Business Park 1168 Bangalore, Karnataka 560071 1169 India 1171 Email: TirumaleswarReddy_Konda@McAfee.com