idnits 2.17.1 draft-ietf-dots-server-discovery-02.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 709 has weird spacing: '...minimum lists...' -- The document date (May 6, 2019) is 1818 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 (-14) exists of draft-ietf-dots-signal-call-home-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 (~~), 10 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: November 7, 2019 McAfee 6 P. Patil 7 Cisco 8 May 6, 2019 10 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server 11 Discovery 12 draft-ietf-dots-server-discovery-02 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 November 7, 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 . . . . . . . . . . . . . . . . . . . 8 66 5.1.1. Format of DOTS Reference Identifier Option . . . . . 8 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 18 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 The discovery methods can also used by a DOTS server to locate a DOTS 136 client in the context of DOTS Call Home 137 [I-D.ietf-dots-signal-call-home]. 139 Considerations for the selection of DOTS server(s) by multi-homed 140 DOTS clients is out of scope; the reader should refer to 141 [I-D.ietf-dots-multihoming] for more details. 143 Likewise, happy eyeballs considerations for DOTS signal channel 144 protocol are out of scope. The reader should refer to Section 4 of 145 [I-D.ietf-dots-signal-channel]. 147 This document assumes that security credentials to authenticate DOTS 148 server(s) are provisioned to a DOTS client using a variety of means 149 such as (but not limited to) those discussed in 150 [I-D.ietf-netconf-zerotouch] or 151 [I-D.ietf-anima-bootstrapping-keyinfra]. DOTS clients use those 152 credentials for authentication purposes following the rules 153 documented in [I-D.ietf-dots-signal-channel]. 155 2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in BCP 160 14 [RFC2119][RFC8174] when, and only when, they appear in all 161 capitals, as shown here. 163 The reader should be familiar with the terms defined in 164 [I-D.ietf-dots-architecture] and [RFC3958]. 166 DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC8415]. 168 3. Why Multiple Discovery Mechanisms? 170 It is tempting to specify one single discovery mechanism for DOTS. 171 Nevertheless, the analysis of the various use cases sketched in 172 [I-D.ietf-dots-use-cases] reveals that it is unlikely that one single 173 discovery method can be suitable for all the sample deployments. 174 Concretely: 176 o Many use cases discussed in [I-D.ietf-dots-use-cases] do involve a 177 CPE device. Multiple CPEs, connected to distinct network 178 providers may even be considered. It is intuitive to leverage on 179 existing mechanisms such as discovery using service resolution or 180 DHCP to provision the CPE acting as a DOTS client with the DOTS 181 server(s). 183 o Resolving a DOTS server domain name offered by an upstream transit 184 provider provisioned to a DOTS client into IP address(es) require 185 the use of the appropriate DNS resolvers; otherwise, resolving 186 those names will fail. The use of protocols such as DHCP does 187 allow to associate provisioned DOTS server domain names with a 188 list of DNS servers to be used for name resolution. Furthermore, 189 DHCP allows to directly provision IP addresses avoiding therefore 190 the need for extra lookup delays. 192 o Some of the use cases may allow DOTS clients to have direct 193 communications with upstream DOTS servers; that is no DOTS gateway 194 is involved. Leveraging on existing features that do not require 195 specific feature on the node embedding the DOTS client may ease 196 DOTS deployment. Typically, the use of Straightforward-Naming 197 Authority Pointer (S-NAPTR) lookups [RFC3958] allows the DOTS 198 server administrators to provision the preferred DOTS transport 199 protocol between the DOTS client and the DOTS server and allows 200 the DOTS client to discover this preference. 202 o The upstream network provider is not the DDoS mitigation provider 203 for some of these use cases. It is safe to assume that for such 204 deployments, the DOTS server(s) domain name is provided during the 205 service subscription (i.e., manual/local configuration). 207 o Multiple DOTS clients may be enabled within a network (e.g., 208 enterprise network). Dynamic means to discover DOTS servers in a 209 deterministic manner are interesting from an operational 210 standpoint. 212 o Some of the use cases may involve a DOTS gateway that is 213 responsible for selecting the appropriate DOTS server(s) to relay 214 requests received from DOTS clients. 216 Consequently, this document describes a unified discovery logic 217 (Section 4) which involves the following mechanisms: 219 o Dynamic discovery using DHCP (Section 5). 221 o A resolution mechanism based on straightforward Naming Authority 222 Pointer (S-NAPTR) resource records in the Domain Name System (DNS) 223 (Section 6). 225 o DNS Service Discovery (Section 7). 227 4. Unified DOTS Discovery Procedure 229 A key point in the deployment of DOTS is the ability of network 230 operators to be able to configure DOTS clients with the correct DOTS 231 server(s) information consistently. To accomplish this, operators 232 will need a consistent set of ways in which DOTS clients can discover 233 this information, and a consistent priority among these options. If 234 some devices prefer manual configuration over dynamic discovery, 235 while others prefer dynamic discovery over manual configuration, the 236 result will be a process of "whack-a-mole", where the operator must 237 find devices that are using the wrong DOTS server(s), determine how 238 to ensure the devices are configured properly, and then reconfigure 239 the device through the preferred method. 241 All DOTS clients MUST support at least one of the three mechanisms 242 below to determine a DOTS server list. All DOTS clients SHOULD 243 implement all three, or as many as are practical for any specific 244 device, of these ways to discover DOTS servers, in order to 245 facilitate the deployment of DOTS in large scale environments: 247 1. Explicit configuration: 249 * Local/Manual configuration: A DOTS client, will learn the DOTS 250 server(s) by means of local or manual DOTS configuration 251 (i.e., DOTS servers configured at the system level). 252 Configuration discovered from a DOTS client application is 253 considered as local configuration. 255 An implementation may give the user an opportunity (e.g., by 256 means of configuration file options or menu items) to specify 257 DOTS server(s) for each address family. These MAY be 258 specified either as IP addresses or the DNS name of a DOTS 259 server. When only DOTS server's IP addresses are configured, 260 a reference identifier must also be configured for 261 authentication purposes. 263 * Automatic configuration (e.g., DHCP, an automation system): 264 The DOTS client attempts to discover DOTS server(s) names and/ 265 or addresses from DHCP, as described in Section 5. 267 2. Service Resolution : The DOTS client attempts to discover DOTS 268 server name(s) using service resolution, as specified in 269 Section 6. 271 3. DNS SD: DNS Service Discovery. The DOTS client attempts to 272 discover DOTS server name(s) using DNS service discovery, as 273 specified in Section 7. 275 Some of these mechanisms imply the use of DNS to resolve the IP 276 address(es) of the DOTS server, while others imply an IP address of 277 the relevant DOTS server is obtained directly. Implementation 278 options may vary on a per device basis, as some devices may not have 279 DNS capabilities and/or proper configuration. 281 DOTS clients will prefer information received from the discovery 282 methods in the order listed. 284 On hosts with more than one interface or address family (IPv4/v6), 285 the DOTS server discovery procedure has to be performed for each 286 combination of interface and address family. A client MAY choose to 287 perform the discovery procedure only for a desired interface/address 288 combination if the client does not wish to discover a DOTS server for 289 all combinations of interface and address family. 291 The above procedure MUST also be followed by a DOTS gateway. 293 The discovery method MUST be reiterated upon the following events: 295 o Expiry of a lease associated with a discovered DOTS server. 297 o Expiry of a DOTS server's certificate currently in use. 299 o Attachment to a new network. 301 5. DHCP Options for DOTS 303 As reported in Section 1.7.2 of [RFC6125]: 305 "few certification authorities issue server certificates based on 306 IP addresses, but preliminary evidence indicates that such 307 certificates are a very small percentage (less than 1%) of issued 308 certificates". 310 In order to allow for PKIX-based authentication between a DOTS client 311 and server while accommodating for the current best practices for 312 issuing certificates, this document allows for configuring names to 313 DOTS clients. These names can be used for two purposes: to retrieve 314 the list of IP addresses of a DOTS server or to be presented as a 315 reference identifier for authentication purposes. 317 Defining the option to include a list of IP addresses would avoid a 318 dependency on an underlying name resolution, but that design requires 319 to also supply a name for PKIX-based authentication purposes. 321 The design assumes that the same DOTS server is used for establishing 322 both signal and data channels. For more customized configurations 323 (e.g., transport-specific configuration, distinct DOTS servers for 324 the signal and the data channels), an operator can supply only a DOTS 325 reference identifier that will be then passed to the procedure 326 described in Section 6. 328 5.1. DHCPv6 DOTS Options 330 5.1.1. Format of DOTS Reference Identifier Option 332 The DHCPv6 DOTS option is used to configure a name of the DOTS 333 server. The format of this option is shown in Figure 2. 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | OPTION_V6_DOTS_RI | Option-length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 | dots-server-name (FQDN) | 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 2: DHCPv6 DOTS Reference Identifier Option 346 The fields of the option shown in Figure 2 are as follows: 348 o Option-code: OPTION_V6_DOTS_RI (TBA1, see Section 9.1) 349 o Option-length: Length of the dots-server-name field in octets. 350 o dots-server-name: A fully qualified domain name of the DOTS 351 server. This field is formatted as specified in Section 10 of 352 [RFC8415]. 354 An example of the dots-server-name encoding is shown in Figure 3. 355 This example conveys the FQDN "dots.example.com.". 357 +------+------+------+------+------+------+------+------+------+ 358 | 0x04 | d | o | t | s | 0x07 | e | x | a | 359 +------+------+------+------+------+------+------+------+------+ 360 | m | p | l | e | 0x03 | c | o | m | 0x00 | 361 +------+------+------+------+------+------+------+------+------+ 363 Figure 3: An example of the dots-server-name Encoding 365 5.1.2. Format of DOTS Address Option 367 The DHCPv6 DOTS option can be used to configure a list of IPv6 368 addresses of a DOTS server. The format of this option is shown in 369 Figure 4. As a reminder, this format follows the guidelines for 370 creating new DHCPv6 options (Section 5.1 of [RFC7227]). 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | OPTION_V6_DOTS_ADDRESS | Option-length | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 | DOTS ipv6-address | 378 | | 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | | 382 | DOTS ipv6-address | 383 | | 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | ... | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Figure 4: DHCPv6 DOTS Address Option 391 The fields of the option shown in Figure 4 are as follows: 393 o Option-code: OPTION_V6_DOTS_ADDRESS (TBA2, see Section 9.1) 394 o Option-length: Length of the 'DOTS ipv6-address(es)' field in 395 octets. MUST be a multiple of 16. 396 o DOTS ipv6-address: Includes one or more IPv6 addresses [RFC4291] 397 of the DOTS server to be used by the DOTS client. 399 Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) 400 are allowed to be included in this option. 402 To return more than one DOTS servers to the requesting DHCPv6 client, 403 the DHCPv6 server returns multiple instances of OPTION_V6_DOTS. 405 5.1.3. DHCPv6 Client Behavior 407 DHCP clients MAY request options OPTION_V6_DOTS_RI and 408 OPTION_V6_DOTS_ADDRESS, as defined in [RFC8415], Sections 18.2.1, 409 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. As a convenience to the 410 reader, it is mentioned here that the DHCP client includes the 411 requested option codes in the Option Request Option. 413 If the DHCP client receives more than one instance of 414 OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use 415 only the first instance of that option. 417 If the DHCP client receives both OPTION_V6_DOTS_RI and 418 OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 419 reference identifier for authentication purposes (e.g., PKIX 420 [RFC6125]), while the addresses included in OPTION_V6_DOTS_ADDRESS 421 are used to reach the DOTS server. In other words, the name conveyed 422 in OPTION_V6_DOTS_RI MUST NOT be passed to underlying resolution 423 library in the presence of OPTION_V6_DOTS_ADDRESS in a response. 425 If the DHCP client receives OPTION_V6_DOTS_RI only, but 426 OPTION_V6_DOTS_RI option contains more than one name, as 427 distinguished by the presence of multiple root labels, the DHCP 428 client MUST use only the first name. Once the name is validated 429 (Section 8 of [RFC8415]), the name is passed to a name resolution 430 library. Moreover, that name is also used as a reference identifier 431 for authentication purposes. 433 If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the 434 address(es) included in OPTION_V6_DOTS_ADDRESS is used to reach the 435 DOTS server. In addition, these addresses can be used as identifiers 436 for authentication. 438 The DHCP client MUST silently discard multicast and host loopback 439 addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS. 441 5.2. DHCPv4 DOTS Options 443 5.2.1. Format of DOTS Reference Identifier Option 445 The DHCPv4 DOTS option is used to configure a name of the DOTS 446 server. The format of this option is illustrated in Figure 5. 448 Code Length DOTS server name 449 +-----+-----+-----+-----+-----+-----+-----+-- 450 |TBA3 | n | s1 | s2 | s3 | s4 | s5 | ... 451 +-----+-----+-----+-----+-----+-----+-----+-- 453 The values s1, s2, s3, etc. represent the domain name labels in the 454 domain name encoding. 456 Figure 5: DHCPv4 DOTS Reference Identifier Option 458 The fields of the option shown in Figure 5 are as follows: 460 o Code: OPTION_V4_DOTS_RI (TBA3, see Section 9.2); 461 o Length: Includes the length of the "DOTS server name" field in 462 octets; the maximum length is 255 octets. 463 o DOTS server name: The domain name of the DOTS server. This field 464 is formatted as specified in Section 10 of [RFC8415]. 466 5.2.2. Format of DOTS Address Option 468 The DHCPv4 DOTS option can be used to configure a list of IPv4 469 addresses of a DOTS server. The format of this option is illustrated 470 in Figure 6. 472 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Code=TBA4 | Length | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | List-Length | List of | 477 +-+-+-+-+-+-+-+-+ DOTS | 478 / IPv4 Addresses / 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 480 | List-Length | List of | | 481 +-+-+-+-+-+-+-+-+ DOTS | | 482 / IPv4 Addresses / | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 484 . ... . optional 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 486 | List-Length | List of | | 487 +-+-+-+-+-+-+-+-+ DOTS | | 488 / IPv4 Addresses / | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 491 Figure 6: DHCPv4 DOTS Address Option 493 The fields of the option shown in Figure 6 are as follows: 495 o Code: OPTION_V4_DOTS_ADDRESS (TBA4, see Section 9.2); 496 o Length: Length of all included data in octets. The minimum length 497 is 5. 498 o List-Length: Length of the "List of DOTS IPv4 Addresses" field in 499 octets; MUST be a multiple of 4. 500 o List of DOTS IPv4 Addresses: Contains one or more IPv4 addresses 501 of the DOTS server to be used by the DOTS client. The format of 502 this field is shown in Figure 7. 503 o OPTION_V4_DOTS_ADDRESS can include multiple lists of DOTS IPv4 504 addresses; each list is treated separately as it corresponds to a 505 given DOTS server. 507 When several lists of DOTS IPv4 addresses are to be included, 508 "List-Length" and "DOTS IPv4 Addresses" fields are repeated. 510 0 8 16 24 32 40 48 511 +-----+-----+-----+-----+-----+-----+-- 512 | a1 | a2 | a3 | a4 | a1 | a2 | ... 513 +-----+-----+-----+-----+-----+-----+-- 514 IPv4 Address 1 IPv4 Address 2 ... 516 This format assumes that an IPv4 address is encoded as a1.a2.a3.a4. 518 Figure 7: Format of the List of DOTS IPv4 Addresses 520 OPTION_V4_DOTS_ADDRESS is a concatenation-requiring option. As such, 521 the mechanism specified in [RFC3396] MUST be used if 522 OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255 523 octets. 525 5.2.3. DHCPv4 Client Behavior 527 To discover a DOTS server, the DHCPv4 client MUST include both 528 OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request 529 List Option [RFC2132]. 531 If the DHCP client receives more than one instance of 532 OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST use 533 only the first instance of that option. 535 If the DHCP client receives both OPTION_V4_DOTS_RI and 536 OPTION_V4_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 537 reference identifier for authentication purposes, while the addresses 538 included in OPTION_V4_DOTS_ADDRESS are used to reach the DOTS server. 539 In other words, the name conveyed in OPTION_V4_DOTS_RI MUST NOT be 540 passed to underlying resolution library in the presence of 541 OPTION_V4_DOTS_ADDRESS in a response. 543 If the DHCP client receives OPTION_V4_DOTS_RI only, but 544 OPTION_V4_DOTS_RI option contains more than one name, as 545 distinguished by the presence of multiple root labels, the DHCP 546 client MUST use only the first name. Once the name is validated 547 (Section 10 of [RFC8415]), the name is passed to a name resolution 548 library. Moreover, that name is also used as a reference identifier 549 for authentication purposes. 551 If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the 552 address(es) included in OPTION_V4_DOTS_ADDRESS is used to reach the 553 DOTS server. In addition, these addresses can be used as identifiers 554 for authentication. 556 The DHCP client MUST silently discard multicast and host loopback 557 addresses conveyed in OPTION_V4_DOTS_ADDRESS. 559 6. Discovery using Service Resolution 561 This mechanism is performed in two steps: 563 1. A DNS domain name is retrieved for each combination of interface 564 and address family. A DOTS client has to determine the domain in 565 which it is located relying on dynamic means such as DHCP 566 (Section 5) . Implementations MAY allow the user to specify a 567 default name that is used, if no specific name has been 568 configured. 570 2. Retrieved DNS domain names are then used for S-NAPTR lookups. 571 Further DNS lookups may be necessary to determine DOTS server IP 572 address(es). 574 Once the DOTS client has retrieved client's DNS domain or discovered 575 the DOTS server name that needs to be resolved (e.g., Section 5), an 576 S-NAPTR lookup with 'DOTS' application service and the desired 577 protocol tag is made to obtain information necessary to connect to 578 the authoritative DOTS server within the given domain. 580 This specification defines "DOTS" as an application service tag 581 (Section 9.3.1) and "signal.udp" (Section 9.3.2), "signal.tcp" 582 (Section 9.3.3), and "data.tcp" (Section 9.3.4) as application 583 protocol tags. 585 In the example below, for domain 'example.net', the resolution 586 algorithm will result in IP address(es), port, tag and protocol 587 tuples as follows: 589 example.net. 590 IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. 591 IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. 592 IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net. 594 signal.example.net. 595 IN NAPTR 100 10 S DOTS:signal.udp "" _dots._signal._udp.example.net. 596 IN NAPTR 200 10 S DOTS:signal.tcp "" _dots._signal._tcp.example.net. 598 data.example.net. 599 IN NAPTR 100 10 S DOTS:data.tcp "" _dots._data._tcp.example.net. 601 _dots._signal._udp.example.net. 602 IN SRV 0 0 5000 a.example.net. 604 _dots._signal._tcp.example.net. 605 IN SRV 0 0 5001 a.example.net. 607 _dots._data._tcp.example.net. 608 IN SRV 0 0 5002 a.example.net. 610 a.example.net. 611 IN AAAA 2001:db8::1 613 +-------+----------+-------------+------+--------+ 614 | Order | Protocol | IP address | Port | Tag | 615 +-------+----------+-------------+------+--------+ 616 | 1 | UDP | 2001:db8::1 | 5000 | Signal | 617 | 2 | TCP | 2001:db8::1 | 5001 | Signal | 618 | 3 | TCP | 2001:db8::1 | 5002 | Data | 619 +-------+----------+-------------+------+--------+ 621 If no DOTS-specific S-NAPTR records can be retrieved, the discovery 622 procedure fails for this domain name (and the corresponding interface 623 and IP protocol version). If more domain names are known, the 624 discovery procedure MAY perform the corresponding S-NAPTR lookups 625 immediately. However, before retrying a lookup that has failed, a 626 DOTS client MUST wait a time period that is appropriate for the 627 encountered error (e.g., NXDOMAIN, timeout, etc.). 629 7. DNS Service Discovery 631 DNS-based Service Discovery (DNS-SD) [RFC6763] provides generic 632 solutions for discovering services. DNS-SD defines a set of naming 633 rules for certain DNS record types that they use for advertising and 634 discovering services. 636 Section 4.1 of [RFC6763] specifies that a service instance name in 637 DNS-SD has the following structure: 639 . . 641 The portion specifies the DNS sub-domain where the service 642 instance is registered. It may be "local.", indicating the mDNS 643 local domain, or it may be a conventional domain name such as 644 "example.com.". 646 The portion of the DOTS service instance name MUST be 647 "_dots._signal._udp" or "_dots._signal._tcp" or "_dots._data._tcp". 649 8. Security Considerations 651 DOTS-related security considerations are discussed in Section 4 of 652 [I-D.ietf-dots-architecture] is to be considered. DOTS agents must 653 authenticate each other using (D)TLS before a DOTS session is 654 considered valid according to the [I-D.ietf-dots-signal-channel]. 656 8.1. DHCP 658 The security considerations in [RFC2131] and [RFC8415] are to be 659 considered. 661 8.2. Service Resolution 663 The primary attack against the methods described in Section 6 is one 664 that would lead to impersonation of a DOTS server. An attacker could 665 attempt to compromise the S-NAPTR resolution. The use of mutual 666 authentication makes it difficult to redirect a DOTS client to an 667 illegitimate DOTS server. 669 8.3. DNS Service Discovery 671 Since DNS-SD is just a specification for how to name and use records 672 in the existing DNS system, it has no specific additional security 673 requirements over and above those that already apply to DNS queries 674 and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC) 675 [RFC4033] SHOULD be used where the authenticity of information is 676 important. For DNS updates, secure updates [RFC2136][RFC3007] SHOULD 677 generally be used to control which clients have permission to update 678 DNS records. 680 9. IANA Considerations 682 IANA is requested to allocate the SRV service name of "_dots._signal" 683 for DOTS signal channel over UDP or TCP, and the service name of 684 "_dots._data" for DOTS data channel over TCP. 686 9.1. DHCPv6 Option 688 IANA is requested to assign the following new DHCPv6 Option Code in 689 the registry maintained in: http://www.iana.org/assignments/ 690 dhcpv6-parameters. 692 Value Description Client ORO Singleton Option 693 TBD1 OPTION_V6_DOTS_RI Yes Yes 694 TBD2 OPTION_V6_DOTS_ADDRESS Yes No 696 9.2. DHCPv4 Option 698 IANA is requested to assign the following new DHCPv4 Option Code in 699 the registry maintained in: http://www.iana.org/assignments/bootp- 700 dhcp-parameters/. 702 Option Name Value Data length Meaning 703 ---------------------- ----- ------------ --------------------------- 704 OPTION_V4_DOTS_RI TBA3 Variable; Includes the name of the 705 the maximum DOTS server. 706 length is 707 255 octets. 708 OPTION_V4_DOTS_ADDRESS TBA4 Variable; Includes one or multiple 709 the minimum lists of DOTS IP addresses; 710 length is 5. each list is treated as a 711 separate DOTS server. 713 9.3. Application Service & Application Protocol Tags 715 This document requests IANA to make the following allocations from 716 the registry available at: https://www.iana.org/assignments/s-naptr- 717 parameters/s-naptr-parameters.xhtml. 719 9.3.1. DOTS Application Service Tag Registration 721 o Application Protocol Tag: DOTS 723 o Intended Usage: See Section 6 724 o Security Considerations: See Section 8 726 o Contact Information: 728 9.3.2. signal.udp Application Protocol Tag Registration 730 o Application Protocol Tag: signal.udp 732 o Intended Usage: See Section 6 734 o Security Considerations: See Section 8 736 o Contact Information: 738 9.3.3. signal.tcp Application Protocol Tag Registration 740 o Application Protocol Tag: signal.tcp 742 o Intended Usage: See Section 6 744 o Security Considerations: See Section 8 746 o Contact Information: 748 9.3.4. data.tcp Application Protocol Tag Registration 750 o Application Protocol Tag: data.tcp 752 o Intended Usage: See Section 6 754 o Security Considerations: See Section 8 756 o Contact Information: 758 10. Acknowledgements 760 Thanks to Brian Carpenter for the review of the BRSKI text. 762 Many thanks to Russ White for the review, comments, and text 763 contribution. 765 Thanks for Dan Wing and Pei Wei for the review and comments. 767 Thanks to Bernie Volz for the review of the DHCP section. 769 11. References 771 11.1. Normative References 773 [I-D.ietf-dots-signal-channel] 774 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 775 Teague, "Distributed Denial-of-Service Open Threat 776 Signaling (DOTS) Signal Channel Specification", draft- 777 ietf-dots-signal-channel-31 (work in progress), March 778 2019. 780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 781 Requirement Levels", BCP 14, RFC 2119, 782 DOI 10.17487/RFC2119, March 1997, 783 . 785 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 786 RFC 2131, DOI 10.17487/RFC2131, March 1997, 787 . 789 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 790 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 791 . 793 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 794 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 795 DOI 10.17487/RFC3396, November 2002, 796 . 798 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 799 Service Location Using SRV RRs and the Dynamic Delegation 800 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 801 January 2005, . 803 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 804 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 805 2006, . 807 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 808 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 809 . 811 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 812 "Special-Purpose IP Address Registries", BCP 153, 813 RFC 6890, DOI 10.17487/RFC6890, April 2013, 814 . 816 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 817 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 818 May 2017, . 820 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 821 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 822 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 823 RFC 8415, DOI 10.17487/RFC8415, November 2018, 824 . 826 11.2. Informative References 828 [I-D.ietf-anima-bootstrapping-keyinfra] 829 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 830 S., and K. Watsen, "Bootstrapping Remote Secure Key 831 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 832 keyinfra-19 (work in progress), March 2019. 834 [I-D.ietf-dots-architecture] 835 Mortensen, A., K, R., Andreasen, F., Teague, N., and R. 836 Compton, "Distributed-Denial-of-Service Open Threat 837 Signaling (DOTS) Architecture", draft-ietf-dots- 838 architecture-13 (work in progress), April 2019. 840 [I-D.ietf-dots-data-channel] 841 Boucadair, M. and R. K, "Distributed Denial-of-Service 842 Open Threat Signaling (DOTS) Data Channel Specification", 843 draft-ietf-dots-data-channel-28 (work in progress), March 844 2019. 846 [I-D.ietf-dots-multihoming] 847 Boucadair, M. and R. K, "Multi-homing Deployment 848 Considerations for Distributed-Denial-of-Service Open 849 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 850 (work in progress), January 2019. 852 [I-D.ietf-dots-signal-call-home] 853 K, R., Boucadair, M., and J. Shallow, "Distributed Denial- 854 of-Service Open Threat Signaling (DOTS) Signal Channel 855 Call Home", draft-ietf-dots-signal-call-home-01 (work in 856 progress), April 2019. 858 [I-D.ietf-dots-use-cases] 859 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 860 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 861 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 862 in progress), January 2019. 864 [I-D.ietf-netconf-zerotouch] 865 Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero 866 Touch Provisioning (SZTP)", draft-ietf-netconf- 867 zerotouch-29 (work in progress), January 2019. 869 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 870 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 871 RFC 2136, DOI 10.17487/RFC2136, April 1997, 872 . 874 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 875 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 876 . 878 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 879 Rose, "DNS Security Introduction and Requirements", 880 RFC 4033, DOI 10.17487/RFC4033, March 2005, 881 . 883 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 884 Verification of Domain-Based Application Service Identity 885 within Internet Public Key Infrastructure Using X.509 886 (PKIX) Certificates in the Context of Transport Layer 887 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 888 2011, . 890 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 891 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 892 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 893 . 895 Authors' Addresses 897 Mohamed Boucadair 898 Orange 899 Rennes 35000 900 France 902 Email: mohamed.boucadair@orange.com 904 Tirumaleswar Reddy 905 McAfee, Inc. 906 Embassy Golf Link Business Park 907 Bangalore, Karnataka 560071 908 India 910 Email: TirumaleswarReddy_Konda@McAfee.com 911 Prashanth Patil 912 Cisco Systems, Inc. 914 Email: praspati@cisco.com