idnits 2.17.1 draft-ietf-dots-server-discovery-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 705 has weird spacing: '...minimum lists...' -- The document date (April 17, 2019) is 1835 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) == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-31 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-19 == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-13 == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-28 == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-01 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-17 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 0 errors (**), 0 flaws (~~), 9 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: October 19, 2019 McAfee 6 P. Patil 7 Cisco 8 April 17, 2019 10 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server 11 Discovery 12 draft-ietf-dots-server-discovery-01 14 Abstract 16 It may not be possible for a network to determine the cause for an 17 attack, but instead just realize that some resources seem to be under 18 attack. To fill that gap, Distributed-Denial-of-Service Open Threat 19 Signaling (DOTS) allows a network to inform a DOTS server that it is 20 under a potential attack so that appropriate mitigation actions are 21 undertaken. 23 This document specifies mechanisms to configure DOTS clients with 24 DOTS servers. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 19, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Why Multiple Discovery Mechanisms? . . . . . . . . . . . . . 4 63 4. Unified DOTS Discovery Procedure . . . . . . . . . . . . . . 5 64 5. DHCP Options for DOTS . . . . . . . . . . . . . . . . . . . . 7 65 5.1. DHCPv6 DOTS Options . . . . . . . . . . . . . . . . . . . 7 66 5.1.1. Format of DOTS Reference Identifier Option . . . . . 7 67 5.1.2. Format of DOTS Address Option . . . . . . . . . . . . 8 68 5.1.3. DHCPv6 Client Behavior . . . . . . . . . . . . . . . 9 69 5.2. DHCPv4 DOTS Options . . . . . . . . . . . . . . . . . . . 10 70 5.2.1. Format of DOTS Reference Identifier Option . . . . . 10 71 5.2.2. Format Format of DOTS Address Option . . . . . . . . 11 72 5.2.3. DHCPv4 Client Behavior . . . . . . . . . . . . . . . 12 73 6. Discovery using Service Resolution . . . . . . . . . . . . . 13 74 7. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 15 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 8.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 8.2. Service Resolution . . . . . . . . . . . . . . . . . . . 15 78 8.3. DNS Service Discovery . . . . . . . . . . . . . . . . . . 15 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 9.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 16 81 9.2. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . 16 82 9.3. Application Service & Application Protocol Tags . . . . . 16 83 9.3.1. DOTS Application Service Tag Registration . . . . . . 16 84 9.3.2. signal.udp Application Protocol Tag Registration . . 17 85 9.3.3. signal.tcp Application Protocol Tag Registration . . 17 86 9.3.4. data.tcp Application Protocol Tag Registration . . . 17 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 90 11.2. Informative References . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 DDoS Open Threat Signaling (DOTS) [I-D.ietf-dots-architecture] 96 specifies an architecture, in which a DOTS client can inform a DOTS 97 server that the network is under a potential attack and that 98 appropriate mitigation actions are required. Indeed, because the 99 lack of a common method to coordinate a real-time response among 100 involved actors and network domains inhibits the effectiveness of 101 DDoS attack mitigation, DOTS signal channel protocol 102 [I-D.ietf-dots-signal-channel] is meant to carry requests for DDoS 103 attack mitigation, thereby reducing the impact of an attack and 104 leading to more efficient defensive actions in various deployment 105 scenarios such as those discussed in [I-D.ietf-dots-use-cases]. 106 Moreover, DOTS clients can instruct a DOTS server to install 107 filtering rules by means of DOTS data channel 108 [I-D.ietf-dots-data-channel]. 110 The basic high-level DOTS architecture is illustrated in Figure 1 111 ([I-D.ietf-dots-architecture]): 113 +-----------+ +-------------+ 114 | Mitigator | ~~~~~~~~~~ | DOTS Server | 115 +-----------+ +-------------+ 116 | 117 | 118 | 119 +---------------+ +-------------+ 120 | Attack Target | ~~~~~~ | DOTS Client | 121 +---------------+ +-------------+ 123 Figure 1: Basic DOTS Architecture 125 [I-D.ietf-dots-architecture] specifies that the DOTS client may be 126 provided with a list of DOTS servers; each associated with one or 127 more IP addresses. These addresses may or may not be of the same 128 address family. The DOTS client establishes one or more DOTS 129 sessions by connecting to the provided DOTS server addresses. 131 This document specifies methods for DOTS clients to discover their 132 DOTS server(s). The rationale for specifying multiple discovery 133 mechanisms is discussed in Section 3. 135 Considerations for the selection of DOTS server(s) by multi-homed 136 DOTS clients is out of scope; the reader should refer to 137 [I-D.ietf-dots-multihoming] for more details. 139 Likewise, happy eyeballs considerations for DOTS signal channel 140 protocol are out of scope. The reader should refer to Section 4 of 141 [I-D.ietf-dots-signal-channel]. 143 This document assumes that security credentials to authenticate DOTS 144 server(s) are provisioned to a DOTS client using a variety of means 145 such as (but not limited to) those discussed in 146 [I-D.ietf-netconf-zerotouch] or 147 [I-D.ietf-anima-bootstrapping-keyinfra]. DOTS clients use those 148 credentials for authentication purposes following the rules 149 documented in [I-D.ietf-dots-signal-channel]. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119][RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 The reader should be familiar with the terms defined in 160 [I-D.ietf-dots-architecture] and [RFC3958]. 162 DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC8415]. 164 3. Why Multiple Discovery Mechanisms? 166 It is tempting to specify one single discovery mechanism for DOTS. 167 Nevertheless, the analysis of the various use cases sketched in 168 [I-D.ietf-dots-use-cases] reveals that it is unlikely that one single 169 discovery method can be suitable for all the sample deployments. 170 Concretely: 172 o Many use cases discussed in [I-D.ietf-dots-use-cases] do involve a 173 CPE device. Multiple CPEs, connected to distinct network 174 providers may even be considered. It is intuitive to leverage on 175 existing mechanisms such as discovery using service resolution or 176 DHCP to provision the CPE acting as a DOTS client with the DOTS 177 server(s). 179 o Resolving a DOTS server domain name offered by an upstream transit 180 provider provisioned to a DOTS client into IP address(es) require 181 the use of the appropriate DNS resolvers; otherwise, resolving 182 those names will fail. The use of protocols such as DHCP does 183 allow to associate provisioned DOTS server domain names with a 184 list of DNS servers to be used for name resolution. Furthermore, 185 DHCP allows to directly provision IP addresses avoiding therefore 186 the need for extra lookup delays. 188 o Some of the use cases may allow DOTS clients to have direct 189 communications with upstream DOTS servers; that is no DOTS gateway 190 is involved. Leveraging on existing features that do not require 191 specific feature on the node embedding the DOTS client may ease 192 DOTS deployment. Typically, the use of Straightforward-Naming 193 Authority Pointer (S-NAPTR) lookups [RFC3958] allows the DOTS 194 server administrators to provision the preferred DOTS transport 195 protocol between the DOTS client and the DOTS server and allows 196 the DOTS client to discover this preference. 198 o The upstream network provider is not the DDoS mitigation provider 199 for some of these use cases. It is safe to assume that for such 200 deployments, the DOTS server(s) domain name is provided during the 201 service subscription (i.e., manual/local configuration). 203 o Multiple DOTS clients may be enabled within a network (e.g., 204 enterprise network). Dynamic means to discover DOTS servers in a 205 deterministic manner are interesting from an operational 206 standpoint. 208 o Some of the use cases may involve a DOTS gateway that is 209 responsible for selecting the appropriate DOTS server(s) to relay 210 requests received from DOTS clients. 212 Consequently, this document describes a unified discovery logic 213 (Section 4) which involves the following mechanisms: 215 o Dynamic discovery using DHCP (Section 5). 217 o A resolution mechanism based on straightforward Naming Authority 218 Pointer (S-NAPTR) resource records in the Domain Name System (DNS) 219 (Section 6). 221 o DNS Service Discovery (Section 7). 223 4. Unified DOTS Discovery Procedure 225 A key point in the deployment of DOTS is the ability of network 226 operators to be able to configure DOTS clients with the correct DOTS 227 server(s) information consistently. To accomplish this, operators 228 will need a consistent set of ways in which DOTS clients can discover 229 this information, and a consistent priority among these options. If 230 some devices prefer manual configuration over dynamic discovery, 231 while others prefer dynamic discovery over manual configuration, the 232 result will be a process of "whack-a-mole", where the operator must 233 find devices that are using the wrong DOTS server(s), determine how 234 to ensure the devices are configured properly, and then reconfigure 235 the device through the preferred method. 237 All DOTS clients MUST support at least one of the three mechanisms 238 below to determine a DOTS server list. All DOTS clients SHOULD 239 implement all three, or as many as are practical for any specific 240 device, of these ways to discover DOTS servers, in order to 241 facilitate the deployment of DOTS in large scale environments: 243 1. Explicit configuration: 245 * Local/Manual configuration: A DOTS client, will learn the DOTS 246 server(s) by means of local or manual DOTS configuration 247 (i.e., DOTS servers configured at the system level). 248 Configuration discovered from a DOTS client application is 249 considered as local configuration. 251 An implementation may give the user an opportunity (e.g., by 252 means of configuration file options or menu items) to specify 253 DOTS server(s) for each address family. These MAY be 254 specified either as IP addresses or the DNS name of a DOTS 255 server. When only DOTS server's IP addresses are configured, 256 a reference identifier must also be configured for 257 authentication purposes. 259 * Automatic configuration (e.g., DHCP, an automation system): 260 The DOTS client attempts to discover DOTS server(s) names and/ 261 or addresses from DHCP, as described in Section 5. 263 2. Service Resolution : The DOTS client attempts to discover DOTS 264 server name(s) using service resolution, as specified in 265 Section 6. 267 3. DNS SD: DNS Service Discovery. The DOTS client attempts to 268 discover DOTS server name(s) using DNS service discovery, as 269 specified in Section 7. 271 Some of these mechanisms imply the use of DNS to resolve the IP 272 address(es) of the DOTS server, while others imply an IP address of 273 the relevant DOTS server is obtained directly. Implementation 274 options may vary on a per device basis, as some devices may not have 275 DNS capabilities and/or proper configuration. 277 DOTS clients will prefer information received from the discovery 278 methods in the order listed. 280 On hosts with more than one interface or address family (IPv4/v6), 281 the DOTS server discovery procedure has to be performed for each 282 combination of interface and address family. A client MAY choose to 283 perform the discovery procedure only for a desired interface/address 284 combination if the client does not wish to discover a DOTS server for 285 all combinations of interface and address family. 287 The above procedure MUST also be followed by a DOTS gateway. 289 The discovery method MUST be reiterated upon the following events: 291 o Expiry of a lease associated with a discovered DOTS server. 293 o Expiry of a DOTS server's certificate currently in use. 295 o Attachment to a new network. 297 5. DHCP Options for DOTS 299 As reported in Section 1.7.2 of [RFC6125]: 301 "few certification authorities issue server certificates based on 302 IP addresses, but preliminary evidence indicates that such 303 certificates are a very small percentage (less than 1%) of issued 304 certificates". 306 In order to allow for PKIX-based authentication between a DOTS client 307 and server while accommodating for the current best practices for 308 issuing certificates, this document allows for configuring names to 309 DOTS clients. These names can be used for two purposes: to retrieve 310 the list of IP addresses of a DOTS server or to be presented as a 311 reference identifier for authentication purposes. 313 Defining the option to include a list of IP addresses would avoid a 314 dependency on an underlying name resolution, but that design requires 315 to also supply a name for PKIX-based authentication purposes. 317 The design assumes that the same DOTS server is used for establishing 318 both signal and data channels. For more customized configurations 319 (e.g., transport-specific configuration, distinct DOTS servers for 320 the signal and the data channels), an operator can supply only a DOTS 321 reference identifier that will be then passed to the procedure 322 described in Section 6. 324 5.1. DHCPv6 DOTS Options 326 5.1.1. Format of DOTS Reference Identifier Option 328 The DHCPv6 DOTS option is used to configure a name of the DOTS 329 server. The format of this option is shown in Figure 2. 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | OPTION_V6_DOTS | Option-length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 | dots-server-name (FQDN) | 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 2: DHCPv6 DOTS Reference Identifier option 342 The fields of the option shown in Figure 2 are as follows: 344 o Option-code: OPTION_V6_DOTS_RI (TBA1, see Section 9.1) 345 o Option-length: Length of the dots-server-name field in octets. 346 o dots-server-name: A fully qualified domain name of the DOTS 347 server. This field is formatted as specified in Section 10 of 348 [RFC8415]. 350 An example of the dots-server-name encoding is shown in Figure 3. 351 This example conveys the FQDN "dots.example.com.". 353 +------+------+------+------+------+------+------+------+------+ 354 | 0x04 | d | o | t | s | 0x07 | e | x | a | 355 +------+------+------+------+------+------+------+------+------+ 356 | m | p | l | e | 0x03 | c | o | m | 0x00 | 357 +------+------+------+------+------+------+------+------+------+ 359 Figure 3: An example of the dots-server-name encoding 361 5.1.2. Format of DOTS Address Option 363 The DHCPv6 DOTS option can be used to configure a list of IPv6 364 addresses of a DOTS server. The format of this option is shown in 365 Figure 4. As a reminder, this format follows the guidelines for 366 creating new DHCPv6 options (Section 5.1 of [RFC7227]). 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | OPTION_V6_DOTS | Option-length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 | DOTS ipv6-address | 374 | | 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 | DOTS ipv6-address | 379 | | 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | ... | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 4: DHCPv6 DOTS Address option 387 The fields of the option shown in Figure 4 are as follows: 389 o Option-code: OPTION_V6_DOTS_ADDRESS (TBA2, see Section 9.1) 390 o Option-length: Length of the 'DOTS ipv6-address(es)' field in 391 octets. MUST be a multiple of 16. 392 o DOTS ipv6-address: Includes one or more IPv6 addresses [RFC4291] 393 of the DOTS server to be used by the DOTS client. 395 Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) 396 are allowed to be included in this option. 398 To return more than one DOTS servers to the requesting DHCPv6 client, 399 the DHCPv6 server returns multiple instances of OPTION_V6_DOTS. 401 5.1.3. DHCPv6 Client Behavior 403 DHCP clients MAY request options OPTION_V6_DOTS_RI and 404 OPTION_V6_DOTS_ADDRESS, as defined in [RFC8415], Sections 18.2.1, 405 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. As a convenience to the 406 reader, it is mentioned here that the DHCP client includes the 407 requested option codes in the Option Request Option. 409 If the DHCP client receives more than one instance of 410 OPTION_V6_DOTS_RI (resp. OPTION_V6_DOTS_ADDRESS) option, it MUST use 411 only the first instance of that option. 413 If the DHCP client receives both OPTION_V6_DOTS_RI and 414 OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 415 reference identifier for authentication purposes (e.g., PKIX 416 [RFC6125]), while the addresses included in OPTION_V6_DOTS_ADDRESS 417 are used to reach the DOTS server. In other words, the name conveyed 418 in OPTION_V6_DOTS_RI MUST NOT be passed to underlying resolution 419 library in the presence of OPTION_V6_DOTS_ADDRESS in a response. 421 If the DHCP client receives OPTION_V6_DOTS_RI only, but 422 OPTION_V6_DOTS_RI option contains more than one name, as 423 distinguished by the presence of multiple root labels, the DHCP 424 client MUST use only the first name. Once the name is validated 425 (Section 8 of [RFC8415]), the name is passed to a name resolution 426 library. Moreover, that name is also used as a reference identifier 427 for authentication purposes. 429 If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the 430 address(es) included in OPTION_V6_DOTS_ADDRESS is used to reach the 431 DOTS server. In addition, these addresses can be used as identifiers 432 for authentication. 434 The DHCP client MUST silently discard multicast and host loopback 435 addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS. 437 5.2. DHCPv4 DOTS Options 439 5.2.1. Format of DOTS Reference Identifier Option 441 The DHCPv4 DOTS option is used to configure a name of the DOTS 442 server. The format of this option is illustrated in Figure 5. 444 Code Length DOTS server name 445 +-----+-----+-----+-----+-----+-----+-----+-- 446 |TBA3 | n | s1 | s2 | s3 | s4 | s5 | ... 447 +-----+-----+-----+-----+-----+-----+-----+-- 449 The values s1, s2, s3, etc. represent the domain name labels in the 450 domain name encoding. 452 Figure 5: DHCPv4 DOTS Reference Identifier option 454 The fields of the option shown in Figure 5 are as follows: 456 o Code: OPTION_V4_DOTS_RI (TBA3, see Section 9.2); 457 o Length: Includes the length of the "DOTS server name" field in 458 octets; the maximum length is 255 octets. 459 o DOTS server name: The domain name of the DOTS server. This field 460 is formatted as specified in Section 10 of [RFC8415]. 462 5.2.2. Format Format of DOTS Address Option 464 The DHCPv4 DOTS option can be used to configure a list of IPv4 465 addresses of a DOTS server. The format of this option is illustrated 466 in Figure 6. 468 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Code=TBA4 | Length | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | List-Length | List of | 473 +-+-+-+-+-+-+-+-+ DOTS | 474 / IPv4 Addresses / 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 476 | List-Length | List of | | 477 +-+-+-+-+-+-+-+-+ DOTS | | 478 / IPv4 Addresses / | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 480 . ... . optional 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 482 | List-Length | List of | | 483 +-+-+-+-+-+-+-+-+ DOTS | | 484 / IPv4 Addresses / | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 487 Figure 6: DHCPv4 DOTS Address option 489 The fields of the option shown in Figure 6 are as follows: 491 o Code: OPTION_V4_DOTS_ADDRESS (TBA4, see Section 9.2); 492 o Length: Length of all included data in octets. The minimum length 493 is 5. 494 o List-Length: Length of the "List of DOTS IPv4 Addresses" field in 495 octets; MUST be a multiple of 4. 496 o List of DOTS IPv4 Addresses: Contains one or more IPv4 addresses 497 of the DOTS server to be used by the DOTS client. The format of 498 this field is shown in Figure 7. 499 o OPTION_V4_DOTS can include multiple lists of DOTS IPv4 addresses; 500 each list is treated separately as it corresponds to a given DOTS 501 server. 503 When several lists of DOTS IPv4 addresses are to be included, 504 "List-Length" and "DOTS IPv4 Addresses" fields are repeated. 506 0 8 16 24 32 40 48 507 +-----+-----+-----+-----+-----+-----+-- 508 | a1 | a2 | a3 | a4 | a1 | a2 | ... 509 +-----+-----+-----+-----+-----+-----+-- 510 IPv4 Address 1 IPv4 Address 2 ... 512 This format assumes that an IPv4 address is encoded as a1.a2.a3.a4. 514 Figure 7: Format of the List of DOTS IPv4 Addresses 516 OPTION_V4_DOTS is a concatenation-requiring option. As such, the 517 mechanism specified in [RFC3396] MUST be used if OPTION_V4_DOTS 518 exceeds the maximum DHCPv4 option size of 255 octets. 520 5.2.3. DHCPv4 Client Behavior 522 To discover a DOTS server, the DHCPv4 client MUST include both 523 OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request 524 List Option [RFC2132]. 526 If the DHCP client receives more than one instance of 527 OPTION_V4_DOTS_RI (resp. OPTION_V4_DOTS_ADDRESS) option, it MUST use 528 only the first instance of that option. 530 If the DHCP client receives both OPTION_V4_DOTS_RI and 531 OPTION_V4_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 532 reference identifier for authentication purposes, while the addresses 533 included in OPTION_V4_DOTS_ADDRESS are used to reach the DOTS server. 534 In other words, the name conveyed in OPTION_V4_DOTS_RI MUST NOT be 535 passed to underlying resolution library in the presence of 536 OPTION_V4_DOTS_ADDRESS in a response. 538 If the DHCP client receives OPTION_V4_DOTS_RI only, but 539 OPTION_V4_DOTS_RI option contains more than one name, as 540 distinguished by the presence of multiple root labels, the DHCP 541 client MUST use only the first name. Once the name is validated 542 (Section 10 of [RFC8415]), the name is passed to a name resolution 543 library. Moreover, that name is also used as a reference identifier 544 for authentication purposes. 546 If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the 547 address(es) included in OPTION_V4_DOTS_ADDRESS is used to reach the 548 DOTS server. In addition, these addresses can be used as identifiers 549 for authentication. 551 The DHCP client MUST silently discard multicast and host loopback 552 addresses conveyed in OPTION_V4_DOTS_ADDRESS. 554 6. Discovery using Service Resolution 556 This mechanism is performed in two steps: 558 1. A DNS domain name is retrieved for each combination of interface 559 and address family. A DOTS client has to determine the domain in 560 which it is located relying on dynamic means such as DHCP 561 (Section 5) . Implementations MAY allow the user to specify a 562 default name that is used, if no specific name has been 563 configured. 565 2. Retrieved DNS domain names are then used for S-NAPTR lookups. 566 Further DNS lookups may be necessary to determine DOTS server IP 567 address(es). 569 Once the DOTS client has retrieved client's DNS domain or discovered 570 the DOTS server name that needs to be resolved (e.g., Section 5), an 571 S-NAPTR lookup with 'DOTS' application service and the desired 572 protocol tag is made to obtain information necessary to connect to 573 the authoritative DOTS server within the given domain. 575 This specification defines "DOTS" as an application service tag 576 (Section 9.3.1) and "signal.udp" (Section 9.3.2), "signal.tcp" 577 (Section 9.3.3), and "data.tcp" (Section 9.3.4) as application 578 protocol tags. 580 In the example below, for domain 'example.net', the resolution 581 algorithm will result in IP address(es), port, tag and protocol 582 tuples as follows: 584 example.net. 585 IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. 586 IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. 587 IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net. 589 signal.example.net. 590 IN NAPTR 100 10 S DOTS:signal.udp "" _dots._signal._udp.example.net. 591 IN NAPTR 200 10 S DOTS:signal.tcp "" _dots._signal._tcp.example.net. 593 data.example.net. 594 IN NAPTR 100 10 S DOTS:data.tcp "" _dots._data._tcp.example.net. 596 _dots._signal._udp.example.net. 597 IN SRV 0 0 5000 a.example.net. 599 _dots._signal._tcp.example.net. 600 IN SRV 0 0 5001 a.example.net. 602 _dots._data._tcp.example.net. 603 IN SRV 0 0 5002 a.example.net. 605 a.example.net. 606 IN AAAA 2001:db8::1 608 +-------+----------+-------------+------+--------+ 609 | Order | Protocol | IP address | Port | Tag | 610 +-------+----------+-------------+------+--------+ 611 | 1 | UDP | 2001:db8::1 | 5000 | Signal | 612 | 2 | TCP | 2001:db8::1 | 5001 | Signal | 613 | 3 | TCP | 2001:db8::1 | 5002 | Data | 614 +-------+----------+-------------+------+--------+ 616 If no DOTS-specific S-NAPTR records can be retrieved, the discovery 617 procedure fails for this domain name (and the corresponding interface 618 and IP protocol version). If more domain names are known, the 619 discovery procedure MAY perform the corresponding S-NAPTR lookups 620 immediately. However, before retrying a lookup that has failed, a 621 DOTS client MUST wait a time period that is appropriate for the 622 encountered error (e.g., NXDOMAIN, timeout, etc.). 624 7. DNS Service Discovery 626 DNS-based Service Discovery (DNS-SD) [RFC6763] provides generic 627 solutions for discovering services. DNS-SD defines a set of naming 628 rules for certain DNS record types that they use for advertising and 629 discovering services. 631 Section 4.1 of [RFC6763] specifies that a service instance name in 632 DNS-SD has the following structure: 634 . . 636 The portion specifies the DNS sub-domain where the service 637 instance is registered. It may be "local.", indicating the mDNS 638 local domain, or it may be a conventional domain name such as 639 "example.com.". 641 The portion of the DOTS service instance name MUST be 642 "_dots._signal._udp" or "_dots._signal._tcp" or "_dots._data._tcp". 644 8. Security Considerations 646 DOTS-related security considerations are discussed in Section 4 of 647 [I-D.ietf-dots-architecture] is to be considered. DOTS agents must 648 authenticate each other using (D)TLS before a DOTS session is 649 considered valid according to the [I-D.ietf-dots-signal-channel]. 651 8.1. DHCP 653 The security considerations in [RFC2131] and [RFC8415] are to be 654 considered. 656 8.2. Service Resolution 658 The primary attack against the methods described in Section 6 is one 659 that would lead to impersonation of a DOTS server. An attacker could 660 attempt to compromise the S-NAPTR resolution. The use of mutual 661 authentication makes it difficult to redirect a DOTS client to an 662 illegitimate DOTS server. 664 8.3. DNS Service Discovery 666 Since DNS-SD is just a specification for how to name and use records 667 in the existing DNS system, it has no specific additional security 668 requirements over and above those that already apply to DNS queries 669 and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC) 670 [RFC4033] SHOULD be used where the authenticity of information is 671 important. For DNS updates, secure updates [RFC2136][RFC3007] SHOULD 672 generally be used to control which clients have permission to update 673 DNS records. 675 9. IANA Considerations 677 IANA is requested to allocate the SRV service name of "_dots._signal" 678 for DOTS signal channel over UDP or TCP, and the service name of 679 "_dots._data" for DOTS data channel over TCP. 681 9.1. DHCPv6 Option 683 IANA is requested to assign the following new DHCPv6 Option Code in 684 the registry maintained in http://www.iana.org/assignments/ 685 dhcpv6-parameters: 687 Option Name Value 688 ---------------------- ----- 689 OPTION_V6_DOTS_RI TBA1 690 OPTION_V6_DOTS_ADDRESS TBA2 692 9.2. DHCPv4 Option 694 IANA is requested to assign the following new DHCPv4 Option Code in 695 the registry maintained in http://www.iana.org/assignments/bootp- 696 dhcp-parameters/: 698 Option Name Value Data length Meaning 699 ---------------------- ----- ------------ --------------------------- 700 OPTION_V4_DOTS_RI TBA3 Variable; Includes the name of the 701 the maximum DOTS server. 702 length is 703 255 octets. 704 OPTION_V4_DOTS_ADDRESS TBA4 Variable; Includes one or multiple 705 the minimum lists of DOTS IP addresses; 706 length is 5. each list is treated as a 707 separate DOTS server. 709 9.3. Application Service & Application Protocol Tags 711 This document requests IANA to make the following allocations from 712 the registry available at: https://www.iana.org/assignments/s-naptr- 713 parameters/s-naptr-parameters.xhtml. 715 9.3.1. DOTS Application Service Tag Registration 717 o Application Protocol Tag: DOTS 719 o Intended Usage: See Section 6 720 o Security Considerations: See Section 8 722 o Contact Information: 724 9.3.2. signal.udp Application Protocol Tag Registration 726 o Application Protocol Tag: signal.udp 728 o Intended Usage: See Section 6 730 o Security Considerations: See Section 8 732 o Contact Information: 734 9.3.3. signal.tcp Application Protocol Tag Registration 736 o Application Protocol Tag: signal.tcp 738 o Intended Usage: See Section 6 740 o Security Considerations: See Section 8 742 o Contact Information: 744 9.3.4. data.tcp Application Protocol Tag Registration 746 o Application Protocol Tag: data.tcp 748 o Intended Usage: See Section 6 750 o Security Considerations: See Section 8 752 o Contact Information: 754 10. Acknowledgements 756 Thanks to Brian Carpenter for the review of the BRSKI text. 758 Many thanks to Russ White for the review, comments, and text 759 contribution. 761 Thanks for Dan Wing and Pei Wei for the review and comments. 763 11. References 764 11.1. Normative References 766 [I-D.ietf-dots-signal-channel] 767 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 768 Teague, "Distributed Denial-of-Service Open Threat 769 Signaling (DOTS) Signal Channel Specification", draft- 770 ietf-dots-signal-channel-31 (work in progress), March 771 2019. 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 779 RFC 2131, DOI 10.17487/RFC2131, March 1997, 780 . 782 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 783 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 784 . 786 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 787 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 788 DOI 10.17487/RFC3396, November 2002, 789 . 791 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 792 Service Location Using SRV RRs and the Dynamic Delegation 793 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 794 January 2005, . 796 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 797 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 798 2006, . 800 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 801 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 802 . 804 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 805 "Special-Purpose IP Address Registries", BCP 153, 806 RFC 6890, DOI 10.17487/RFC6890, April 2013, 807 . 809 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 810 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 811 May 2017, . 813 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 814 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 815 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 816 RFC 8415, DOI 10.17487/RFC8415, November 2018, 817 . 819 11.2. Informative References 821 [I-D.ietf-anima-bootstrapping-keyinfra] 822 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 823 S., and K. Watsen, "Bootstrapping Remote Secure Key 824 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 825 keyinfra-19 (work in progress), March 2019. 827 [I-D.ietf-dots-architecture] 828 Mortensen, A., K, R., Andreasen, F., Teague, N., and R. 829 Compton, "Distributed-Denial-of-Service Open Threat 830 Signaling (DOTS) Architecture", draft-ietf-dots- 831 architecture-13 (work in progress), April 2019. 833 [I-D.ietf-dots-data-channel] 834 Boucadair, M. and R. K, "Distributed Denial-of-Service 835 Open Threat Signaling (DOTS) Data Channel Specification", 836 draft-ietf-dots-data-channel-28 (work in progress), March 837 2019. 839 [I-D.ietf-dots-multihoming] 840 Boucadair, M. and R. K, "Multi-homing Deployment 841 Considerations for Distributed-Denial-of-Service Open 842 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 843 (work in progress), January 2019. 845 [I-D.ietf-dots-use-cases] 846 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 847 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 848 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 849 in progress), January 2019. 851 [I-D.ietf-netconf-zerotouch] 852 Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero 853 Touch Provisioning (SZTP)", draft-ietf-netconf- 854 zerotouch-29 (work in progress), January 2019. 856 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 857 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 858 RFC 2136, DOI 10.17487/RFC2136, April 1997, 859 . 861 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 862 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 863 . 865 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 866 Rose, "DNS Security Introduction and Requirements", 867 RFC 4033, DOI 10.17487/RFC4033, March 2005, 868 . 870 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 871 Verification of Domain-Based Application Service Identity 872 within Internet Public Key Infrastructure Using X.509 873 (PKIX) Certificates in the Context of Transport Layer 874 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 875 2011, . 877 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 878 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 879 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 880 . 882 Authors' Addresses 884 Mohamed Boucadair 885 Orange 886 Rennes 35000 887 France 889 Email: mohamed.boucadair@orange.com 891 Tirumaleswar Reddy 892 McAfee, Inc. 893 Embassy Golf Link Business Park 894 Bangalore, Karnataka 560071 895 India 897 Email: TirumaleswarReddy_Konda@McAfee.com 899 Prashanth Patil 900 Cisco Systems, Inc. 902 Email: praspati@cisco.com