idnits 2.17.1 draft-ietf-dots-server-discovery-04.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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. == 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 758 has weird spacing: '...minimum lists...' -- The document date (June 26, 2019) is 1765 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-34 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-21 == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-14 == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-29 == 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-02 == 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: 1 error (**), 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: December 28, 2019 McAfee 6 June 26, 2019 8 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server 9 Discovery 10 draft-ietf-dots-server-discovery-04 12 Abstract 14 It may not be possible for a network to determine the cause for an 15 attack, but instead just realize that some resources seem to be under 16 attack. To fill that gap, Distributed-Denial-of-Service Open Threat 17 Signaling (DOTS) allows a network to inform a DOTS server that it is 18 under a potential attack so that appropriate mitigation actions are 19 undertaken. 21 This document specifies mechanisms to configure DOTS clients with 22 DOTS servers. The discovery procedure also covers the DOTS Signal 23 Channel Call Home. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 28, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Why Multiple Discovery Mechanisms? . . . . . . . . . . . . . 4 62 4. Unified DOTS Discovery Procedure . . . . . . . . . . . . . . 5 63 5. DHCP Options for DOTS Agent Discovery . . . . . . . . . . . . 7 64 5.1. DHCPv6 DOTS Options . . . . . . . . . . . . . . . . . . . 8 65 5.1.1. Format of DOTS Reference Identifier Option . . . . . 8 66 5.1.2. Format of DOTS Address Option . . . . . . . . . . . . 8 67 5.1.3. DHCPv6 Client Behavior . . . . . . . . . . . . . . . 9 68 5.2. DHCPv4 DOTS Options . . . . . . . . . . . . . . . . . . . 10 69 5.2.1. Format of DOTS Reference Identifier Option . . . . . 10 70 5.2.2. Format of DOTS Address Option . . . . . . . . . . . . 11 71 5.2.3. DHCPv4 Client Behavior . . . . . . . . . . . . . . . 12 72 6. Discovery using Service Resolution . . . . . . . . . . . . . 13 73 7. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 15 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 8.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 8.2. Service Resolution . . . . . . . . . . . . . . . . . . . 16 77 8.3. DNS Service Discovery . . . . . . . . . . . . . . . . . . 16 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 9.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 17 80 9.2. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . 17 81 9.3. Application Service & Application Protocol Tags . . . . . 17 82 9.3.1. DOTS Application Service Tag Registration . . . . . . 17 83 9.3.2. DOTS Call Home Application Service Tag Registration . 18 84 9.3.3. signal.udp Application Protocol Tag Registration . . 18 85 9.3.4. signal.tcp Application Protocol Tag Registration . . 18 86 9.3.5. data.tcp Application Protocol Tag Registration . . . 18 87 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 91 12.2. Informative References . . . . . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Introduction 96 DDoS Open Threat Signaling (DOTS) [I-D.ietf-dots-architecture] 97 specifies an architecture, in which a DOTS client can inform a DOTS 98 server that the network is under a potential attack and that 99 appropriate mitigation actions are required. Indeed, because the 100 lack of a common method to coordinate a real-time response among 101 involved actors and network domains inhibits the effectiveness of 102 DDoS attack mitigation, DOTS signal channel protocol 103 [I-D.ietf-dots-signal-channel] is meant to carry requests for DDoS 104 attack mitigation, thereby reducing the impact of an attack and 105 leading to more efficient defensive actions in various deployment 106 scenarios such as those discussed in [I-D.ietf-dots-use-cases]. 107 Moreover, DOTS clients can instruct a DOTS server to install 108 filtering rules by means of DOTS data channel 109 [I-D.ietf-dots-data-channel]. 111 The basic high-level DOTS architecture is illustrated in Figure 1 112 ([I-D.ietf-dots-architecture]): 114 +-----------+ +-------------+ 115 | Mitigator | ~~~~~~~~~~ | DOTS Server | 116 +-----------+ +-------------+ 117 | 118 | 119 | 120 +---------------+ +-------------+ 121 | Attack Target | ~~~~~~ | DOTS Client | 122 +---------------+ +-------------+ 124 Figure 1: Basic DOTS Architecture 126 [I-D.ietf-dots-architecture] specifies that the DOTS client may be 127 provided with a list of DOTS servers; each associated with one or 128 more IP addresses. These addresses may or may not be of the same 129 address family. The DOTS client establishes one or more DOTS 130 sessions by connecting to the provided DOTS server addresses. 132 This document specifies methods for DOTS clients to discover their 133 DOTS server(s). The rationale for specifying multiple discovery 134 mechanisms is discussed in Section 3. 136 The discovery methods can also be used by a DOTS server to locate a 137 DOTS client in the context of DOTS Signal Channel Call Home 138 [I-D.ietf-dots-signal-call-home]. 140 Considerations for the selection of DOTS server(s) by multi-homed 141 DOTS clients is out of scope; the reader should refer to 142 [I-D.ietf-dots-multihoming] for more details. 144 This document assumes that security credentials to authenticate DOTS 145 server(s) are provisioned to a DOTS client using a variety of means 146 such as (but not limited to) those discussed in 147 [I-D.ietf-netconf-zerotouch] or 148 [I-D.ietf-anima-bootstrapping-keyinfra]. DOTS clients use those 149 credentials for authentication purposes following the rules 150 documented in [I-D.ietf-dots-signal-channel]. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119][RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 The reader should be familiar with the terms defined in 161 [I-D.ietf-dots-architecture] and [RFC3958]. 163 DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC8415]. 165 "Peer DOTS agent" refers to the peer DOTS server (normal DOTS 166 operation) or to a peer DOTS client (for DOTS Signal Channel Call 167 Home). 169 3. Why Multiple Discovery Mechanisms? 171 It is tempting to specify one single discovery mechanism for DOTS. 172 Nevertheless, the analysis of the various use cases sketched in 173 [I-D.ietf-dots-use-cases] reveals that it is unlikely that one single 174 discovery method can be suitable for all the sample deployments. 175 Concretely: 177 o Many use cases discussed in [I-D.ietf-dots-use-cases] do involve a 178 CPE device. Multiple CPEs, connected to distinct network 179 providers may even be considered. It is intuitive to leverage on 180 existing mechanisms such as discovery using service resolution or 181 DHCP to provision the CPE acting as a DOTS client with the DOTS 182 server(s). 184 o Resolving a DOTS server domain name offered by an upstream transit 185 provider provisioned to a DOTS client into IP address(es) require 186 the use of the appropriate DNS resolvers; otherwise, resolving 187 those names will fail. The use of protocols such as DHCP does 188 allow to associate provisioned DOTS server domain names with a 189 list of DNS servers to be used for name resolution. Furthermore, 190 DHCP allows to directly provision IP addresses avoiding therefore 191 the need for extra lookup delays. 193 o Some of the use cases may allow DOTS clients to have direct 194 communications with upstream DOTS servers; that is no DOTS gateway 195 is involved. Leveraging on existing features that do not require 196 specific feature on the node embedding the DOTS client may ease 197 DOTS deployment. Typically, the use of Straightforward-Naming 198 Authority Pointer (S-NAPTR) lookups [RFC3958] allows the DOTS 199 server administrators to provision the preferred DOTS transport 200 protocol between the DOTS client and the DOTS server and allows 201 the DOTS client to discover this preference. 203 o The upstream network provider is not the DDoS mitigation provider 204 for some of these use cases. It is safe to assume that for such 205 deployments, the DOTS server(s) domain name is provided during the 206 service subscription (i.e., manual/local configuration). 208 o Multiple DOTS clients may be enabled within a network (e.g., 209 enterprise network). Dynamic means to discover DOTS servers in a 210 deterministic manner are interesting from an operational 211 standpoint. 213 o Some of the use cases may involve a DOTS gateway that is 214 responsible for selecting the appropriate DOTS server(s) to relay 215 requests received from DOTS clients. 217 Consequently, this document describes a unified discovery logic 218 (Section 4) which involves the following mechanisms: 220 o Dynamic discovery using DHCP (Section 5). 222 o A resolution mechanism based on straightforward Naming Authority 223 Pointer (S-NAPTR) resource records in the Domain Name System (DNS) 224 (Section 6). 226 o DNS Service Discovery (Section 7). 228 4. Unified DOTS Discovery Procedure 230 A key point in the deployment of DOTS is the ability of network 231 operators to be able to configure DOTS clients with the correct DOTS 232 server(s) information consistently. To accomplish this, operators 233 will need a consistent set of ways in which DOTS clients can discover 234 this information, and a consistent priority among these options. If 235 some devices prefer manual configuration over dynamic discovery, 236 while others prefer dynamic discovery over manual configuration, the 237 result will be a process of "whack-a-mole", where the operator must 238 find devices that are using the wrong DOTS server(s), determine how 239 to ensure the devices are configured properly, and then reconfigure 240 the device through the preferred method. 242 All DOTS clients MUST support at least one of the three mechanisms 243 below to determine a DOTS server list. All DOTS clients SHOULD 244 implement all three, or as many as are practical for any specific 245 device, of these ways to discover DOTS servers, in order to 246 facilitate the deployment of DOTS in large scale environments: 248 1. Explicit configuration: 250 * Local/Manual configuration: A DOTS client, will learn the DOTS 251 server(s) by means of local or manual DOTS configuration 252 (i.e., DOTS servers configured at the system level). 253 Configuration discovered from a DOTS client application is 254 considered as local configuration. 256 An implementation may give the user an opportunity (e.g., by 257 means of configuration file options or menu items) to specify 258 DOTS server(s) for each address family. These MAY be 259 specified either as IP addresses or the DNS name of a DOTS 260 server. When only DOTS server's IP addresses are configured, 261 a reference identifier must also be configured for 262 authentication purposes. 264 * Automatic configuration (e.g., DHCP, an automation system): 265 The DOTS client attempts to discover DOTS server(s) names and/ 266 or addresses from DHCP, as described in Section 5. 268 2. Service Resolution : The DOTS client attempts to discover DOTS 269 server name(s) using service resolution, as specified in 270 Section 6. 272 3. DNS SD: DNS Service Discovery. The DOTS client attempts to 273 discover DOTS server name(s) using DNS service discovery, as 274 specified in Section 7. 276 Some of these mechanisms imply the use of DNS to resolve the IP 277 address(es) of the DOTS server, while others imply an IP address of 278 the relevant DOTS server is obtained directly. Implementation 279 options may vary on a per device basis, as some devices may not have 280 DNS capabilities and/or proper configuration. 282 DOTS clients will prefer information received from the discovery 283 methods in the order listed. 285 On hosts with more than one interface or address family (IPv4/v6), 286 the DOTS server discovery procedure has to be performed for each 287 combination of interface and address family. A client MAY choose to 288 perform the discovery procedure only for a desired interface/address 289 combination if the client does not wish to discover a DOTS server for 290 all combinations of interface and address family. 292 The above procedure MUST also be followed by a DOTS gateway. 293 Likewise, this procedure MUST be followed by a DOTS server in the 294 context of DOTS Signal Channel Call Home 295 [I-D.ietf-dots-signal-call-home]. 297 The discovery method MUST be reiterated upon the following events: 299 o Expiry of a lease associated with a discovered DOTS server. 301 o Expiry of a DOTS server's certificate currently in use. 303 o Attachment to a new network. 305 5. DHCP Options for DOTS Agent Discovery 307 As reported in Section 1.7.2 of [RFC6125]: 309 "few certification authorities issue server certificates based on 310 IP addresses, but preliminary evidence indicates that such 311 certificates are a very small percentage (less than 1%) of issued 312 certificates". 314 In order to allow for PKIX-based authentication between a DOTS client 315 and server while accommodating for the current best practices for 316 issuing certificates, this document allows for configuring names to 317 DOTS clients. These names can be used for two purposes: to retrieve 318 the list of IP addresses of a DOTS server or to be presented as a 319 reference identifier for authentication purposes. 321 Defining the option to include a list of IP addresses would avoid a 322 dependency on an underlying name resolution, but that design requires 323 to also supply a name for PKIX-based authentication purposes. 325 The design assumes that the same peer DOTS agent is used for 326 establishing both signal and data channels. For more customized 327 configurations (e.g., transport-specific configuration, distinct DOTS 328 servers for the signal and the data channels), an operator can supply 329 only a DOTS reference identifier that will be then passed to the 330 procedure described in Section 6. 332 5.1. DHCPv6 DOTS Options 334 5.1.1. Format of DOTS Reference Identifier Option 336 The DHCPv6 DOTS Reference Identifier option is used to configure a 337 name of the DOTS server (or the name of the DOTS client for DOTS 338 Signal Channel Call Home). The format of this option is shown in 339 Figure 2. 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | OPTION_V6_DOTS_RI | Option-length | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 | dots-agent-name (FQDN) | 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Figure 2: DHCPv6 DOTS Reference Identifier Option 352 The fields of the option shown in Figure 2 are as follows: 354 o Option-code: OPTION_V6_DOTS_RI (TBA1, see Section 9.1) 355 o Option-length: Length of the dots-server-name field in octets. 356 o dots-agent-name: A fully qualified domain name of the peer DOTS 357 agent. This field is formatted as specified in Section 10 of 358 [RFC8415]. 360 An example of the dots-agent-name encoding is shown in Figure 3. 361 This example conveys the FQDN "dots.example.com.". 363 +------+------+------+------+------+------+------+------+------+ 364 | 0x04 | d | o | t | s | 0x07 | e | x | a | 365 +------+------+------+------+------+------+------+------+------+ 366 | m | p | l | e | 0x03 | c | o | m | 0x00 | 367 +------+------+------+------+------+------+------+------+------+ 369 Figure 3: An example of the dots-agent-name Encoding 371 5.1.2. Format of DOTS Address Option 373 The DHCPv6 DOTS Address option can be used to configure a list of 374 IPv6 addresses of a DOTS server (or a DOTS client for DOTS Signal 375 Channel Call Home). The format of this option is shown in Figure 4. 376 As a reminder, this format follows the guidelines for creating new 377 DHCPv6 options (Section 5.1 of [RFC7227]). 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | OPTION_V6_DOTS_ADDRESS | Option-length | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 | DOTS ipv6-address | 385 | | 386 | | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | | 389 | DOTS ipv6-address | 390 | | 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | ... | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Figure 4: DHCPv6 DOTS Address Option 398 The fields of the option shown in Figure 4 are as follows: 400 o Option-code: OPTION_V6_DOTS_ADDRESS (TBA2, see Section 9.1) 401 o Option-length: Length of the 'DOTS ipv6-address(es)' field in 402 octets. MUST be a multiple of 16. 403 o DOTS ipv6-address: Includes one or more IPv6 addresses [RFC4291] 404 of the peer DOTS agent to be used by a DOTS agent for establishing 405 a DOTS session. 407 Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) 408 are allowed to be included in this option. 410 To return more than one DOTS agents to the requesting DHCPv6 client, 411 the DHCPv6 server returns multiple instances of 412 OPTION_V6_DOTS_ADDRESS. 414 5.1.3. DHCPv6 Client Behavior 416 DHCP clients MAY request options OPTION_V6_DOTS_RI and 417 OPTION_V6_DOTS_ADDRESS, as defined in [RFC8415], Sections 18.2.1, 418 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. As a convenience to the 419 reader, it is mentioned here that the DHCP client includes the 420 requested option codes in the Option Request Option. 422 If the DHCP client receives more than one instance of 423 OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use 424 only the first instance of that option. 426 If the DHCP client receives both OPTION_V6_DOTS_RI and 427 OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 428 reference identifier for authentication purposes (e.g., PKIX 429 [RFC6125]), while the addresses included in OPTION_V6_DOTS_ADDRESS 430 are used to reach the peer DOTS agent. In other words, the name 431 conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying 432 resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a 433 response. 435 If the DHCP client receives OPTION_V6_DOTS_RI only, but 436 OPTION_V6_DOTS_RI option contains more than one name, as 437 distinguished by the presence of multiple root labels, the DHCP 438 client MUST use only the first name. Once the name is validated 439 (Section 8 of [RFC8415]), the name is passed to a name resolution 440 library. Moreover, that name is also used as a reference identifier 441 for authentication purposes. 443 If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the 444 address(es) included in OPTION_V6_DOTS_ADDRESS is used to reach the 445 peer DOTS agent. In addition, these addresses can be used as 446 identifiers for authentication. 448 The DHCP client MUST silently discard multicast and host loopback 449 addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS. 451 5.2. DHCPv4 DOTS Options 453 5.2.1. Format of DOTS Reference Identifier Option 455 The DHCPv4 DOTS Reference Identifier option is used to configure a 456 name of the peer DOTS agent. The format of this option is 457 illustrated in Figure 5. 459 Code Length Peer DOTS agent name 460 +-----+-----+-----+-----+-----+-----+-----+-- 461 |TBA3 | n | s1 | s2 | s3 | s4 | s5 | ... 462 +-----+-----+-----+-----+-----+-----+-----+-- 464 The values s1, s2, s3, etc. represent the domain name labels in the 465 domain name encoding. 467 Figure 5: DHCPv4 DOTS Reference Identifier Option 469 The fields of the option shown in Figure 5 are as follows: 471 o Code: OPTION_V4_DOTS_RI (TBA3, see Section 9.2); 472 o Length: Includes the length of the "DOTS server name" field in 473 octets; the maximum length is 255 octets. 474 o Peer DOTS agent name: The domain name of the peer DOTS agent. 475 This field is formatted as specified in Section 10 of [RFC8415]. 477 5.2.2. Format of DOTS Address Option 479 The DHCPv4 DOTS Address option can be used to configure a list of 480 IPv4 addresses of a peer DOTS agent. The format of this option is 481 illustrated in Figure 6. 483 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Code=TBA4 | Length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | List-Length | List of | 488 +-+-+-+-+-+-+-+-+ DOTS | 489 / IPv4 Addresses / 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 491 | List-Length | List of | | 492 +-+-+-+-+-+-+-+-+ DOTS | | 493 / IPv4 Addresses / | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 495 . ... . optional 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 497 | List-Length | List of | | 498 +-+-+-+-+-+-+-+-+ DOTS | | 499 / IPv4 Addresses / | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 502 Figure 6: DHCPv4 DOTS Address Option 504 The fields of the option shown in Figure 6 are as follows: 506 o Code: OPTION_V4_DOTS_ADDRESS (TBA4, see Section 9.2); 507 o Length: Length of all included data in octets. The minimum length 508 is 5. 509 o List-Length: Length of the "List of DOTS IPv4 Addresses" field in 510 octets; MUST be a multiple of 4. 511 o List of DOTS IPv4 Addresses: Contains one or more IPv4 addresses 512 of the peer DOTS agent to be used by a DOTS agent. The format of 513 this field is shown in Figure 7. 514 o OPTION_V4_DOTS_ADDRESS can include multiple lists of DOTS IPv4 515 addresses; each list is treated separately as it corresponds to a 516 given peer DOTS agent. 518 When several lists of DOTS IPv4 addresses are to be included, 519 "List-Length" and "DOTS IPv4 Addresses" fields are repeated. 521 0 8 16 24 32 40 48 522 +-----+-----+-----+-----+-----+-----+-- 523 | a1 | a2 | a3 | a4 | a1 | a2 | ... 524 +-----+-----+-----+-----+-----+-----+-- 525 IPv4 Address 1 IPv4 Address 2 ... 527 This format assumes that an IPv4 address is encoded as a1.a2.a3.a4. 529 Figure 7: Format of the List of DOTS IPv4 Addresses 531 OPTION_V4_DOTS_ADDRESS is a concatenation-requiring option. As such, 532 the mechanism specified in [RFC3396] MUST be used if 533 OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255 534 octets. 536 5.2.3. DHCPv4 Client Behavior 538 To discover a peer DOTS agent, the DHCPv4 client MUST include both 539 OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request 540 List Option [RFC2132]. 542 If the DHCP client receives more than one instance of 543 OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST use 544 only the first instance of that option. 546 If the DHCP client receives both OPTION_V4_DOTS_RI and 547 OPTION_V4_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 548 reference identifier for authentication purposes, while the addresses 549 included in OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS 550 agent. In other words, the name conveyed in OPTION_V4_DOTS_RI MUST 551 NOT be passed to underlying resolution library in the presence of 552 OPTION_V4_DOTS_ADDRESS in a response. 554 If the DHCP client receives OPTION_V4_DOTS_RI only, but 555 OPTION_V4_DOTS_RI option contains more than one name, as 556 distinguished by the presence of multiple root labels, the DHCP 557 client MUST use only the first name. Once the name is validated 558 (Section 10 of [RFC8415]), the name is passed to a name resolution 559 library. Moreover, that name is also used as a reference identifier 560 for authentication purposes. 562 If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the 563 address(es) included in OPTION_V4_DOTS_ADDRESS is used to reach the 564 peer DOTS server. In addition, these addresses can be used as 565 identifiers for authentication. 567 The DHCP client MUST silently discard multicast and host loopback 568 addresses conveyed in OPTION_V4_DOTS_ADDRESS. 570 6. Discovery using Service Resolution 572 This mechanism is performed in two steps: 574 1. A DNS domain name is retrieved for each combination of interface 575 and address family. A DOTS client has to determine the domain in 576 which it is located relying on dynamic means such as DHCP 577 (Section 5) . Implementations MAY allow the user to specify a 578 default name that is used, if no specific name has been 579 configured. 581 2. Retrieved DNS domain names are then used for S-NAPTR lookups 582 [RFC3958]. Further DNS lookups may be necessary to determine 583 DOTS server IP address(es). 585 Once the DOTS client has retrieved client's DNS domain or discovered 586 the peer DOTS agent name that needs to be resolved (e.g., Section 5), 587 an S-NAPTR lookup with 'DOTS' application service and the desired 588 protocol tag is made to obtain information necessary to connect to 589 the authoritative DOTS server within the given domain. 591 This specification defines "DOTS" and "DOTS-CALL-HOME" as application 592 service tags (Sections 9.3.1 and 9.3.2). It also defines 593 "signal.udp" (Section 9.3.3), "signal.tcp" (Section 9.3.4), and 594 "data.tcp" (Section 9.3.5) as application protocol tags. An example 595 is provided in Figure 8. 597 In the example below, for domain 'example.net', the resolution 598 algorithm will result in IP address(es), port, tag and protocol 599 tuples as follows: 601 example.net. 602 IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. 603 IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. 604 IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net. 606 signal.example.net. 607 IN NAPTR 100 10 "s" DOTS:signal.udp "" _dots._signal._udp.example.net. 608 IN NAPTR 200 10 "s" DOTS:signal.tcp "" _dots._signal._tcp.example.net. 610 data.example.net. 611 IN NAPTR 100 10 "s" DOTS:data.tcp "" _dots._data._tcp.example.net. 613 _dots._signal._udp.example.net. 614 IN SRV 0 0 5000 a.example.net. 616 _dots._signal._tcp.example.net. 617 IN SRV 0 0 5001 a.example.net. 619 _dots._data._tcp.example.net. 620 IN SRV 0 0 5002 a.example.net. 622 a.example.net. 623 IN AAAA 2001:db8::1 625 +-------+----------+-------------+------+--------+ 626 | Order | Protocol | IP address | Port | Tag | 627 +-------+----------+-------------+------+--------+ 628 | 1 | UDP | 2001:db8::1 | 5000 | Signal | 629 | 2 | TCP | 2001:db8::1 | 5001 | Signal | 630 | 3 | TCP | 2001:db8::1 | 5002 | Data | 631 +-------+----------+-------------+------+--------+ 633 Figure 8: Sample Example 635 An example is provided in Figure 9 for the Call Home case. 637 In the example below, for domain 'example.net', the resolution 638 algorithm will result in IP address(es), port, tag and protocol 639 tuples as follows: 641 example.net. 642 IN NAPTR 100 10 "" DOTS-CALL-HOME:signal.udp "" signal.example.net. 643 IN NAPTR 200 10 "" DOTS-CALL-HOME:signal.tcp "" signal.example.net. 645 signal.example.net. 646 IN NAPTR 100 10 "s" DOTS-CALL-HOME:signal.udp "" 647 _dots-call-home._signal._udp.example.net. 648 IN NAPTR 200 10 "s" DOTS-CALL-HOME:signal.tcp "" 649 _dots-call-home._signal._tcp.example.net. 651 _dots-call-home._signal._udp.example.net. 652 IN SRV 0 0 6000 b.example.net. 654 _dots-call-home._signal._tcp.example.net. 655 IN SRV 0 0 6001 b.example.net. 657 b.example.net. 658 IN AAAA 2001:db8::2 660 +-------+----------+-------------+------+--------+ 661 | Order | Protocol | IP address | Port | Tag | 662 +-------+----------+-------------+------+--------+ 663 | 1 | UDP | 2001:db8::2 | 6000 | Signal | 664 | 2 | TCP | 2001:db8::2 | 6001 | Signal | 665 +-------+----------+-------------+------+--------+ 667 Figure 9: Sample Example for DOTS Signal Channel Call Home 669 If no DOTS-specific S-NAPTR records can be retrieved, the discovery 670 procedure fails for this domain name (and the corresponding interface 671 and IP protocol version). If more domain names are known, the 672 discovery procedure MAY perform the corresponding S-NAPTR lookups 673 immediately. However, before retrying a lookup that has failed, a 674 DOTS client MUST wait a time period that is appropriate for the 675 encountered error (e.g., NXDOMAIN, timeout, etc.). 677 7. DNS Service Discovery 679 DNS-based Service Discovery (DNS-SD) [RFC6763] provides generic 680 solutions for discovering services. DNS-SD defines a set of naming 681 rules for certain DNS record types that they use for advertising and 682 discovering services. 684 Section 4.1 of [RFC6763] specifies that a service instance name in 685 DNS-SD has the following structure: 687 . . 689 The portion specifies the DNS sub-domain where the service 690 instance is registered. It may be "local.", indicating the mDNS 691 local domain, or it may be a conventional domain name such as 692 "example.com.". 694 The portion of the DOTS service instance name MUST be 695 "_dots._signal._udp" or "_dots._signal._tcp" or "_dots._data._tcp" or 696 "_dots-call-home._signal._udp" or "_dots-call-home._signal._tcp". 698 8. Security Considerations 700 DOTS-related security considerations are discussed in Section 4 of 701 [I-D.ietf-dots-architecture] is to be considered. DOTS agents must 702 authenticate each other using (D)TLS before a DOTS session is 703 considered valid according to the [I-D.ietf-dots-signal-channel]. 705 8.1. DHCP 707 The security considerations in [RFC2131] and [RFC8415] are to be 708 considered. 710 8.2. Service Resolution 712 The primary attack against the methods described in Section 6 is one 713 that would lead to impersonation of a DOTS server. An attacker could 714 attempt to compromise the S-NAPTR resolution. The use of mutual 715 authentication makes it difficult to redirect a DOTS client to an 716 illegitimate DOTS server. 718 8.3. DNS Service Discovery 720 Since DNS-SD is just a specification for how to name and use records 721 in the existing DNS system, it has no specific additional security 722 requirements over and above those that already apply to DNS queries 723 and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC) 724 [RFC4033] SHOULD be used where the authenticity of information is 725 important. For DNS updates, secure updates [RFC2136][RFC3007] SHOULD 726 generally be used to control which clients have permission to update 727 DNS records. 729 9. IANA Considerations 731 IANA is requested to allocate the SRV service name of "_dots._signal" 732 for DOTS signal channel over UDP or TCP, and the service name of 733 "_dots._data" for DOTS data channel over TCP. 735 9.1. DHCPv6 Option 737 IANA is requested to assign the following new DHCPv6 Option Code in 738 the registry maintained in: http://www.iana.org/assignments/ 739 dhcpv6-parameters. 741 Value Description Client ORO Singleton Option 742 TBD1 OPTION_V6_DOTS_RI Yes Yes 743 TBD2 OPTION_V6_DOTS_ADDRESS Yes No 745 9.2. DHCPv4 Option 747 IANA is requested to assign the following new DHCPv4 Option Code in 748 the registry maintained in: http://www.iana.org/assignments/bootp- 749 dhcp-parameters/. 751 Option Name Value Data length Meaning 752 ---------------------- ----- ------------ --------------------------- 753 OPTION_V4_DOTS_RI TBA3 Variable; Includes the name of the 754 the maximum DOTS server. 755 length is 756 255 octets. 757 OPTION_V4_DOTS_ADDRESS TBA4 Variable; Includes one or multiple 758 the minimum lists of DOTS IP addresses; 759 length is 5. each list is treated as a 760 separate DOTS server. 762 9.3. Application Service & Application Protocol Tags 764 This document requests IANA to make the following allocations from 765 the registry available at: https://www.iana.org/assignments/s-naptr- 766 parameters/s-naptr-parameters.xhtml. 768 9.3.1. DOTS Application Service Tag Registration 770 o Application Protocol Tag: DOTS 772 o Intended Usage: See Section 6 774 o Security Considerations: See Section 8 776 o Contact Information: 778 9.3.2. DOTS Call Home Application Service Tag Registration 780 o Application Protocol Tag: DOTS-CALL-HOME 782 o Intended Usage: See Section 6 784 o Security Considerations: See Section 8 786 o Contact Information: 788 9.3.3. signal.udp Application Protocol Tag Registration 790 o Application Protocol Tag: signal.udp 792 o Intended Usage: See Section 6 794 o Security Considerations: See Section 8 796 o Contact Information: 798 9.3.4. signal.tcp Application Protocol Tag Registration 800 o Application Protocol Tag: signal.tcp 802 o Intended Usage: See Section 6 804 o Security Considerations: See Section 8 806 o Contact Information: 808 9.3.5. data.tcp Application Protocol Tag Registration 810 o Application Protocol Tag: data.tcp 812 o Intended Usage: See Section 6 814 o Security Considerations: See Section 8 816 o Contact Information: 818 10. Contributors 820 Prashanth Patil 821 Cisco Systems, Inc. 823 Email: praspati@cisco.com 825 11. Acknowledgements 827 Thanks to Brian Carpenter for the review of the BRSKI text. 829 Many thanks to Russ White for the review, comments, and text 830 contribution. 832 Thanks for Dan Wing and Pei Wei for the review and comments. 834 Thanks to Bernie Volz for the review of the DHCP section. 836 12. References 838 12.1. Normative References 840 [I-D.ietf-dots-signal-channel] 841 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 842 Teague, "Distributed Denial-of-Service Open Threat 843 Signaling (DOTS) Signal Channel Specification", draft- 844 ietf-dots-signal-channel-34 (work in progress), May 2019. 846 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 847 Requirement Levels", BCP 14, RFC 2119, 848 DOI 10.17487/RFC2119, March 1997, 849 . 851 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 852 RFC 2131, DOI 10.17487/RFC2131, March 1997, 853 . 855 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 856 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 857 . 859 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 860 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 861 DOI 10.17487/RFC3396, November 2002, 862 . 864 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 865 Service Location Using SRV RRs and the Dynamic Delegation 866 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 867 January 2005, . 869 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 870 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 871 2006, . 873 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 874 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 875 . 877 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 878 "Special-Purpose IP Address Registries", BCP 153, 879 RFC 6890, DOI 10.17487/RFC6890, April 2013, 880 . 882 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 883 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 884 May 2017, . 886 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 887 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 888 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 889 RFC 8415, DOI 10.17487/RFC8415, November 2018, 890 . 892 12.2. Informative References 894 [I-D.ietf-anima-bootstrapping-keyinfra] 895 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 896 S., and K. Watsen, "Bootstrapping Remote Secure Key 897 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 898 keyinfra-21 (work in progress), June 2019. 900 [I-D.ietf-dots-architecture] 901 Mortensen, A., K, R., Andreasen, F., Teague, N., and R. 902 Compton, "Distributed-Denial-of-Service Open Threat 903 Signaling (DOTS) Architecture", draft-ietf-dots- 904 architecture-14 (work in progress), May 2019. 906 [I-D.ietf-dots-data-channel] 907 Boucadair, M. and R. K, "Distributed Denial-of-Service 908 Open Threat Signaling (DOTS) Data Channel Specification", 909 draft-ietf-dots-data-channel-29 (work in progress), May 910 2019. 912 [I-D.ietf-dots-multihoming] 913 Boucadair, M. and R. K, "Multi-homing Deployment 914 Considerations for Distributed-Denial-of-Service Open 915 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 916 (work in progress), January 2019. 918 [I-D.ietf-dots-signal-call-home] 919 K, R., Boucadair, M., and J. Shallow, "Distributed Denial- 920 of-Service Open Threat Signaling (DOTS) Signal Channel 921 Call Home", draft-ietf-dots-signal-call-home-02 (work in 922 progress), May 2019. 924 [I-D.ietf-dots-use-cases] 925 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 926 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 927 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 928 in progress), January 2019. 930 [I-D.ietf-netconf-zerotouch] 931 Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero 932 Touch Provisioning (SZTP)", draft-ietf-netconf- 933 zerotouch-29 (work in progress), January 2019. 935 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 936 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 937 RFC 2136, DOI 10.17487/RFC2136, April 1997, 938 . 940 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 941 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 942 . 944 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 945 Rose, "DNS Security Introduction and Requirements", 946 RFC 4033, DOI 10.17487/RFC4033, March 2005, 947 . 949 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 950 Verification of Domain-Based Application Service Identity 951 within Internet Public Key Infrastructure Using X.509 952 (PKIX) Certificates in the Context of Transport Layer 953 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 954 2011, . 956 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 957 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 958 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 959 . 961 Authors' Addresses 962 Mohamed Boucadair 963 Orange 964 Rennes 35000 965 France 967 Email: mohamed.boucadair@orange.com 969 Tirumaleswar Reddy 970 McAfee, Inc. 971 Embassy Golf Link Business Park 972 Bangalore, Karnataka 560071 973 India 975 Email: TirumaleswarReddy_Konda@McAfee.com