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