idnits 2.17.1 draft-ietf-dots-server-discovery-09.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 7 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 830 has weird spacing: '...minimal add...' == Line 831 has weird spacing: '...ngth is peer ...' -- The document date (January 9, 2020) is 1568 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ThisDocument' is mentioned on line 829, but not defined == Missing Reference: 'I-D.ietf-dots-call-home' is mentioned on line 805, but not defined == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-34 == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-14 == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-02 == Outdated reference: A later version (-14) exists of draft-ietf-dots-signal-call-home-07 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-20 -- 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: July 12, 2020 McAfee 6 January 9, 2020 8 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent 9 Discovery 10 draft-ietf-dots-server-discovery-09 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 their DOTS servers. The discovery procedure also covers the DOTS 23 Signal 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 July 12, 2020. 42 Copyright Notice 44 Copyright (c) 2020 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? . . . . . . . . . . . . . 5 62 4. Unified DOTS Discovery Procedure . . . . . . . . . . . . . . 6 63 5. DHCP Options for DOTS Agent Discovery . . . . . . . . . . . . 8 64 5.1. DHCPv6 DOTS Options . . . . . . . . . . . . . . . . . . . 9 65 5.1.1. Format of DOTS Reference Identifier Option . . . . . 9 66 5.1.2. Format of DOTS Address Option . . . . . . . . . . . . 10 67 5.1.3. DHCPv6 Client Behavior . . . . . . . . . . . . . . . 10 68 5.2. DHCPv4 DOTS Options . . . . . . . . . . . . . . . . . . . 11 69 5.2.1. Format of DOTS Reference Identifier Option . . . . . 11 70 5.2.2. Format of DOTS Address Option . . . . . . . . . . . . 12 71 5.2.3. DHCPv4 Client Behavior . . . . . . . . . . . . . . . 13 72 6. Discovery using Service Resolution . . . . . . . . . . . . . 13 73 7. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 16 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 8.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 8.2. Service Resolution . . . . . . . . . . . . . . . . . . . 16 77 8.3. DNS Service Discovery . . . . . . . . . . . . . . . . . . 17 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 9.1. The Service Name and Transport Protocol Port Number 80 Registry . . . . . . . . . . . . . . . . . . . . . . . . 17 81 9.2. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 18 82 9.3. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . 18 83 9.4. Application Service & Application Protocol Tags . . . . . 19 84 9.4.1. DOTS Application Service Tag Registration . . . . . . 19 85 9.4.2. DOTS Call Home Application Service Tag Registration . 19 86 9.4.3. signal.udp Application Protocol Tag Registration . . 20 87 9.4.4. signal.tcp Application Protocol Tag Registration . . 20 88 9.4.5. data.tcp Application Protocol Tag Registration . . . 20 89 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 90 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 93 12.2. Informative References . . . . . . . . . . . . . . . . . 22 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 96 1. Introduction 98 DDoS Open Threat Signaling (DOTS) [I-D.ietf-dots-architecture] 99 specifies an architecture, in which a DOTS client can inform a DOTS 100 server that the network is under a potential attack and that 101 appropriate mitigation actions are required. Indeed, because the 102 lack of a common method to coordinate a real-time response among 103 involved actors and network domains inhibits the effectiveness of 104 DDoS attack mitigation, DOTS signal channel protocol 105 [I-D.ietf-dots-signal-channel] is meant to carry requests for DDoS 106 attack mitigation, thereby reducing the impact of an attack and 107 leading to more efficient defensive actions in various deployment 108 scenarios such as those discussed in [I-D.ietf-dots-use-cases]. 109 Moreover, DOTS clients can instruct a DOTS server to install 110 filtering rules by means of the DOTS data channel protocol 111 [I-D.ietf-dots-data-channel]. 113 The basic high-level DOTS architecture is illustrated in Figure 1. 115 +-----------+ +-------------+ 116 | Mitigator | ~~~~~~~~~~ | DOTS Server | 117 +-----------+ +------+------+ 118 | 119 | 120 | 121 +---------------+ +------+------+ 122 | Attack Target | ~~~~~~ | DOTS Client | 123 +---------------+ +-------------+ 125 Figure 1: Basic DOTS Architecture 127 [I-D.ietf-dots-architecture] specifies that the DOTS client may be 128 provided with a list of DOTS servers; each associated with one or 129 more IP addresses. These addresses may or may not be of the same 130 address family. The DOTS client establishes one or more DOTS 131 sessions by connecting to the provided DOTS server addresses. 133 This document specifies methods for DOTS clients to discover their 134 DOTS server(s). The rationale for specifying multiple discovery 135 mechanisms is discussed in Section 3. 137 The discovery methods can also be used by a DOTS server to locate a 138 DOTS client in the context of DOTS Signal Channel Call Home 139 [I-D.ietf-dots-signal-call-home]. The basic high-level DOTS Call 140 Home architecture is illustrated in Figure 2. 142 +---------------+ +-------------+ 143 | Alert/DMS/ | ~~~~~~ | Call Home | 144 | Peer DMS/... | | DOTS client | 145 +---------------+ +------+------+ 146 | 147 | 148 | 149 +---------------+ +------+------+ 150 | Attack | ~~~~~~ | Call Home | 151 | Source(s) | | DOTS server | 152 +---------------+ +-------------+ 154 Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture 156 A DOTS agent may be used to establish base DOTS channels, DOTS Call 157 Home, or both. This specification accommodates all these deployment 158 cases. 160 Considerations for the selection of DOTS server(s) by multi-homed 161 DOTS clients are out of scope; readers should refer to 162 [I-D.ietf-dots-multihoming] for more details. 164 This document assumes that security credentials to authenticate DOTS 165 server(s) are provisioned to a DOTS client using a variety of means 166 such as (but not limited to) those discussed in [RFC8572] or 167 [I-D.ietf-anima-bootstrapping-keyinfra]. DOTS clients use those 168 credentials for authentication purposes following the rules 169 documented in [I-D.ietf-dots-signal-channel]. 171 2. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in BCP 176 14 [RFC2119][RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 The reader should be familiar with the terms defined in 180 [I-D.ietf-dots-architecture], [RFC3958], and 181 [I-D.ietf-dots-signal-call-home]. 183 DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC8415]. 185 "Peer DOTS agent" refers to the peer DOTS server (base DOTS 186 operation) or to a peer Call Home DOTS client (for DOTS Signal 187 Channel Call Home). 189 3. Why Multiple Discovery Mechanisms? 191 It is tempting to specify one single discovery mechanism for DOTS. 192 Nevertheless, the analysis of the various use cases sketched in 193 [I-D.ietf-dots-use-cases] reveals that it is unlikely that one single 194 discovery method can be suitable for all the sample deployments. 195 Concretely: 197 o Many use cases discussed in [I-D.ietf-dots-use-cases] do involve a 198 CPE device. Multiple CPEs, connected to distinct network 199 providers may even be considered. It is intuitive to leverage on 200 existing mechanisms such as discovery using service resolution or 201 DHCP to provision the CPE acting as a DOTS client with the DOTS 202 server(s). 204 o Resolving a DOTS server domain name offered by an upstream transit 205 provider provisioned to a DOTS client into IP address(es) require 206 the use of the appropriate DNS resolvers; otherwise, resolving 207 those names will fail. The use of protocols such as DHCP does 208 allow to associate provisioned DOTS server domain names with a 209 list of DNS servers to be used for name resolution. Furthermore, 210 DHCP allows to directly provision IP addresses avoiding therefore 211 the need for extra lookup delays. 213 o Some of the use cases may allow DOTS clients to have direct 214 communications with upstream DOTS servers; that is no DOTS gateway 215 is involved. Leveraging on existing features that do not require 216 specific feature on the node embedding the DOTS client may ease 217 DOTS deployment. Typically, the use of Straightforward-Naming 218 Authority Pointer (S-NAPTR) lookups [RFC3958] allows the DOTS 219 server administrators to provision the preferred DOTS transport 220 protocol between the DOTS client and the DOTS server and allows 221 the DOTS client to discover this preference. 223 o The upstream network provider is not the DDoS mitigation provider 224 for some of these use cases. It is safe to assume that for such 225 deployments, the DOTS server(s) domain name is provided during the 226 service subscription (i.e., manual/local configuration). 228 o Multiple DOTS clients may be enabled within a network (e.g., 229 enterprise network). Dynamic means to discover DOTS servers in a 230 deterministic manner are interesting from an operational 231 standpoint. 233 o Some of the use cases may involve a DOTS gateway that is 234 responsible for selecting the appropriate DOTS server(s) to relay 235 requests received from DOTS clients. 237 Consequently, this document describes a unified discovery logic 238 (Section 4) which involves the following mechanisms: 240 o Dynamic discovery using DHCP (Section 5). 242 o A resolution mechanism based on straightforward Naming Authority 243 Pointer (S-NAPTR) resource records in the Domain Name System (DNS) 244 (Section 6). 246 o DNS Service Discovery (Section 7). 248 4. Unified DOTS Discovery Procedure 250 A key point in the deployment of DOTS is the ability of network 251 operators to be able to configure DOTS clients with the correct DOTS 252 server(s) information consistently. To accomplish this, operators 253 will need a consistent set of ways in which DOTS clients can discover 254 this information, and a consistent priority among these options. If 255 some devices prefer manual configuration over dynamic discovery, 256 while others prefer dynamic discovery over manual configuration, the 257 result will be a process of "whack-a-mole", where the operator must 258 find devices that are using the wrong DOTS server(s), determine how 259 to ensure the devices are configured properly, and then reconfigure 260 the device through the preferred method. 262 All DOTS clients MUST support at least one of the three mechanisms 263 below to determine a DOTS server list. All DOTS clients SHOULD 264 implement all three, or as many as are practical for any specific 265 device (e.g., a CPE will support the first two mechanisms, a host 266 within a LAN will support the last two mechanisms, or an application 267 server will support a local configuration. More samples are 268 discussed in Section 3), of these ways to discover DOTS servers, in 269 order to facilitate the deployment of DOTS in large scale 270 environments: 272 1. Explicit configuration: 274 * Local/Manual configuration: A DOTS client, will learn the DOTS 275 server(s) by means of local or manual DOTS configuration 276 (i.e., DOTS servers configured at the system level). 277 Configuration discovered from a DOTS client application is 278 considered as local configuration. 280 An implementation may give the user an opportunity (e.g., by 281 means of configuration file options or menu items) to specify 282 DOTS server(s) for each address family. These may be 283 specified either as IP addresses or the DNS name of a DOTS 284 server. When only DOTS server's IP addresses are configured, 285 a reference identifier must also be configured for 286 authentication purposes. 288 * Automatic configuration (e.g., DHCP, an automation system): 289 The DOTS client attempts to discover DOTS server(s) names and/ 290 or addresses from DHCP, as described in Section 5. 292 2. Service Resolution : The DOTS client attempts to discover DOTS 293 server name(s) using service resolution, as specified in 294 Section 6. 296 3. DNS SD: DNS Service Discovery. The DOTS client attempts to 297 discover DOTS server name(s) using DNS service discovery, as 298 specified in Section 7. 300 Some of these mechanisms imply the use of DNS to resolve the IP 301 address(es) of the DOTS server, while others imply an IP address of 302 the relevant DOTS server is obtained directly. Implementation 303 options may vary on a per device basis, as some devices may not have 304 DNS capabilities and/or proper configuration. 306 DOTS clients will prefer information received from the discovery 307 methods in the order listed. 309 On hosts with more than one interface or address family (IPv4/v6), 310 the DOTS server discovery procedure has to be performed for each 311 combination of interface and address family. A DOTS client may 312 choose to perform the discovery procedure only for a desired 313 interface/address combination if the client does not wish to discover 314 a DOTS server for all combinations of interface and address family. 316 This procedure is also followed by a Call Home DOTS server to 317 discover its Call Home DOTS client in the context of 318 [I-D.ietf-dots-signal-call-home]. 320 The discovery method is reiterated by a DOTS agent upon the following 321 events: 323 o Expiry of a lease associated with a discovered DOTS agent. 325 o Expiry of a peer DOTS agent's certificate currently in use. 327 o Attachment to a new network. 329 5. DHCP Options for DOTS Agent Discovery 331 As reported in Section 1.7.2 of [RFC6125]: 333 "few certification authorities issue server certificates based on 334 IP addresses, but preliminary evidence indicates that such 335 certificates are a very small percentage (less than 1%) of issued 336 certificates". 338 In order to allow for PKIX-based authentication between a DOTS client 339 and server while accommodating for the current best practices for 340 issuing certificates, this document allows for configuring names to 341 DOTS clients. These names can be used for two purposes: to retrieve 342 the list of IP addresses of a DOTS server or to be presented as a 343 reference identifier for authentication purposes. 345 Defining the option to include a list of IP addresses would avoid a 346 dependency on an underlying name resolution, but that design requires 347 to also supply a name for PKIX-based authentication purposes. 349 The list of the IP addresses returned by DHCP servers is typically 350 used to fed the DOTS server selection procedure or to provide DOTS 351 agents with primary and backup IP addresses of their peer DOTS 352 agents. 354 The design assumes that the same peer DOTS agent is used for 355 establishing both signal and data channels. For more customized 356 configurations (e.g., transport-specific configuration, distinct DOTS 357 servers for the signal and the data channels), an operator can supply 358 only a DOTS reference identifier that will be then passed to the 359 procedure described in Section 6. 361 The design allows to terminate the base DOTS channels and DOTS Call 362 Home on the same or distinct peer DOTS agents. If distinct peer DOTS 363 agents are deployed, the DHCP option can return, for example, a list 364 of IP addresses to a requesting DOTS agent. This list includes the 365 IP address to be used for the base DOTS channels and the IP address 366 for the DOTS Call Home. The DOTS client (or Call Home DOTS server) 367 will then use the address selection specified in Section 4.3 of 368 [I-D.ietf-dots-signal-channel] to identify the IP address of the peer 369 DOTS server (or Call Home DOTS client). For example: 371 Let's consider that the DOTS server is reachable at 372 2001:db8:122:300::1 while the Call Home DOTS client is reachable 373 at 2001:db8:122:300::2. The DHCP server will then return one DOTS 374 reference identifier and a list that includes both 375 2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP 376 client. That list is passed to the DOTS client (or Call Home DOTS 377 server) which will try to establish connections to the addresses 378 of that list and destination port number 4646 (or 4647). As a 379 result, the DOTS client (or Call Home DOTS server) will select 380 2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server (or 381 Call Home DOTS client). 383 5.1. DHCPv6 DOTS Options 385 5.1.1. Format of DOTS Reference Identifier Option 387 The DHCPv6 DOTS Reference Identifier option is used to configure a 388 name of the DOTS server (or the name of the Call Home DOTS client). 389 The format of this option is shown in Figure 3. 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | OPTION_V6_DOTS_RI | Option-length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | 396 | dots-agent-name (FQDN) | 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 3: DHCPv6 DOTS Reference Identifier Option 402 The fields of the option shown in Figure 3 are as follows: 404 o Option-code: OPTION_V6_DOTS_RI (TBA1, see Section 9.2) 405 o Option-length: Length of the dots-agent-name field in octets. 406 o dots-agent-name: A fully qualified domain name of the peer DOTS 407 agent. This field is formatted as specified in Section 10 of 408 [RFC8415]. 410 An example of the dots-agent-name encoding is shown in Figure 4. 411 This example conveys the FQDN "dots.example.com.". 413 +------+------+------+------+------+------+------+------+------+ 414 | 0x04 | d | o | t | s | 0x07 | e | x | a | 415 +------+------+------+------+------+------+------+------+------+ 416 | m | p | l | e | 0x03 | c | o | m | 0x00 | 417 +------+------+------+------+------+------+------+------+------+ 419 Figure 4: An example of the dots-agent-name Encoding 421 5.1.2. Format of DOTS Address Option 423 The DHCPv6 DOTS Address option can be used to configure a list of 424 IPv6 addresses of a DOTS server (or a Call Home DOTS client). The 425 format of this option is shown in Figure 5. As a reminder, this 426 format follows the guidelines for creating new DHCPv6 options 427 (Section 5.1 of [RFC7227]). 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | OPTION_V6_DOTS_ADDRESS | Option-length | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | | 434 | DOTS ipv6-address | 435 | | 436 | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | 439 | DOTS ipv6-address | 440 | | 441 | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | ... | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Figure 5: DHCPv6 DOTS Address Option 448 The fields of the option shown in Figure 5 are as follows: 450 o Option-code: OPTION_V6_DOTS_ADDRESS (TBA2, see Section 9.2) 451 o Option-length: Length of the 'DOTS ipv6-address(es)' field in 452 octets. MUST be a multiple of 16. 453 o DOTS ipv6-address(es): Includes one or more IPv6 addresses 454 [RFC4291] of the peer DOTS agent to be used by a DOTS agent for 455 establishing a DOTS session. 457 Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) 458 are allowed to be included in this option. 460 5.1.3. DHCPv6 Client Behavior 462 DHCP clients MAY request options OPTION_V6_DOTS_RI and 463 OPTION_V6_DOTS_ADDRESS, as defined in [RFC8415], Sections 18.2.1, 464 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. As a convenience to the 465 reader, it is mentioned here that the DHCP client includes the 466 requested option codes in the Option Request Option. 468 If the DHCP client receives more than one instance of 469 OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use 470 only the first instance of that option. 472 If the DHCP client receives both OPTION_V6_DOTS_RI and 473 OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 474 reference identifier for authentication purposes (e.g., PKIX 475 [RFC6125]), while the addresses included in OPTION_V6_DOTS_ADDRESS 476 are used to reach the peer DOTS agent. In other words, the name 477 conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying 478 resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a 479 response. 481 If the DHCP client receives OPTION_V6_DOTS_RI only, but 482 OPTION_V6_DOTS_RI option contains more than one name, as 483 distinguished by the presence of multiple root labels, the DHCP 484 client MUST use only the first name. Once the name is validated 485 (Section 8 of [RFC8415]), the name is passed to a name resolution 486 library. Moreover, that name is also used as a reference identifier 487 for authentication purposes. 489 If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the 490 address(es) included in OPTION_V6_DOTS_ADDRESS are used to reach the 491 peer DOTS agent. In addition, these addresses can be used as 492 identifiers for authentication. 494 The DHCP client MUST silently discard multicast and host loopback 495 addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS. 497 5.2. DHCPv4 DOTS Options 499 5.2.1. Format of DOTS Reference Identifier Option 501 The DHCPv4 DOTS Reference Identifier option is used to configure a 502 name of the peer DOTS agent. The format of this option is 503 illustrated in Figure 6. 505 Code Length Peer DOTS agent name 506 +-----+-----+-----+-----+-----+-----+-----+-- 507 |TBA3 | n | s1 | s2 | s3 | s4 | s5 | ... 508 +-----+-----+-----+-----+-----+-----+-----+-- 510 The values s1, s2, s3, etc. represent the domain name labels in the 511 domain name encoding. 513 Figure 6: DHCPv4 DOTS Reference Identifier Option 515 The fields of the option shown in Figure 6 are as follows: 517 o Code: OPTION_V4_DOTS_RI (TBA3, see Section 9.3). 518 o Length: Includes the length of the "Peer DOTS agent name" field in 519 octets. 520 o Peer DOTS agent name: The domain name of the peer DOTS agent. 521 This field is formatted as specified in Section 10 of [RFC8415]. 523 5.2.2. Format of DOTS Address Option 525 The DHCPv4 DOTS Address option can be used to configure a list of 526 IPv4 addresses of a peer DOTS agent. The format of this option is 527 illustrated in Figure 7. 529 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Code=TBA4 | Length | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | | 534 + DOTS IPv4 Address | 535 | | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 537 | | | 538 + DOTS IPv4 Address | | 539 | | optional 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 541 . ... . | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 544 Figure 7: DHCPv4 DOTS Address Option 546 The fields of the option shown in Figure 7 are as follows: 548 o Code: OPTION_V4_DOTS_ADDRESS (TBA4, see Section 9.3). 549 o Length: is set to 4*N, where N is the number of IPv4 addresses 550 included in the option. 551 o DOTS IPv4 Address(es): Contains one or more IPv4 addresses of the 552 peer DOTS agent to be used by a DOTS agent. 554 OPTION_V4_DOTS_ADDRESS is a concatenation-requiring option. As such, 555 the mechanism specified in [RFC3396] MUST be used if 556 OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255 557 octets. 559 5.2.3. DHCPv4 Client Behavior 561 To discover a peer DOTS agent, the DHCPv4 client MUST include both 562 OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request 563 List Option [RFC2132]. 565 If the DHCP client receives more than one instance of 566 OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST use 567 only the first instance of that option. 569 If the DHCP client receives both OPTION_V4_DOTS_RI and 570 OPTION_V4_DOTS_ADDRESS, the content of OPTION_V4_DOTS_RI is used as 571 reference identifier for authentication purposes, while the addresses 572 included in OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS 573 agent. In other words, the name conveyed in OPTION_V4_DOTS_RI MUST 574 NOT be passed to underlying resolution library in the presence of 575 OPTION_V4_DOTS_ADDRESS in a response. 577 If the DHCP client receives OPTION_V4_DOTS_RI only, but 578 OPTION_V4_DOTS_RI option contains more than one name, as 579 distinguished by the presence of multiple root labels, the DHCP 580 client MUST use only the first name. Once the name is validated 581 (Section 10 of [RFC8415]), the name is passed to a name resolution 582 library. Moreover, that name is also used as a reference identifier 583 for authentication purposes. 585 If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the 586 address(es) included in OPTION_V4_DOTS_ADDRESS are used to reach the 587 peer DOTS server. In addition, these addresses can be used as 588 identifiers for authentication. 590 The DHCP client MUST silently discard multicast and host loopback 591 addresses conveyed in OPTION_V4_DOTS_ADDRESS. 593 6. Discovery using Service Resolution 595 This mechanism is performed in two steps: 597 1. A DNS domain name is retrieved for each combination of interface 598 and address family. A DOTS agent has to determine the domain in 599 which it is located relying on dynamic means such as DHCP 600 (Section 5) . Implementations may allow the user to specify a 601 default name that is used, if no specific name has been 602 configured. 604 2. Retrieved DNS domain names are then used for S-NAPTR lookups 605 [RFC3958]. Further DNS lookups may be necessary to determine the 606 peer DOTS agent IP address(es). 608 Once the DOTS agent has retrieved its DNS domain or discovered the 609 peer DOTS agent name that needs to be resolved (e.g., Section 5), an 610 S-NAPTR lookup with 'DOTS' application service and the desired 611 protocol tag is made to obtain information necessary to connect to 612 the authoritative peer DOTS agent within the given domain. 614 This specification defines "DOTS" and "DOTS-CALL-HOME" as application 615 service tags (Sections 9.4.1 and 9.4.2). It also defines 616 "signal.udp" (Section 9.4.3), "signal.tcp" (Section 9.4.4), and 617 "data.tcp" (Section 9.4.5) as application protocol tags. An example 618 is provided in Figure 8. 620 In the example below, for domain 'example.net', the resolution 621 algorithm will result in IP address(es), port, tag, and protocol 622 tuples listed in Table 1. 624 example.net. 625 IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. 626 IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. 627 IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net. 629 signal.example.net. 630 IN NAPTR 100 10 "s" DOTS:signal.udp "" _dots-signal._udp.example.net. 631 IN NAPTR 200 10 "s" DOTS:signal.tcp "" _dots-signal._tcp.example.net. 633 data.example.net. 634 IN NAPTR 100 10 "s" DOTS:data.tcp "" _dots-data._tcp.example.net. 636 _dots-signal._udp.example.net. 637 IN SRV 0 0 5000 a.example.net. 639 _dots-signal._tcp.example.net. 640 IN SRV 0 0 5001 a.example.net. 642 _dots-data._tcp.example.net. 643 IN SRV 0 0 5002 a.example.net. 645 a.example.net. 646 IN AAAA 2001:db8::1 648 Figure 8: Sample Example of Discovery of DOTS Servers using Service 649 Resolution 651 +-------+----------+-------------+------+--------+ 652 | Order | Protocol | IP address | Port | Tag | 653 +-------+----------+-------------+------+--------+ 654 | 1 | UDP | 2001:db8::1 | 5000 | Signal | 655 | 2 | TCP | 2001:db8::1 | 5001 | Signal | 656 | 3 | TCP | 2001:db8::1 | 5002 | Data | 657 +-------+----------+-------------+------+--------+ 658 Table 1 660 An example is provided in Figure 9 for the Call Home case. In this 661 example, the resolution algorithm will result in IP address(es), 662 port, and protocol listed in Table 2 for domain 'example.net'. 664 example.net. 665 IN NAPTR 100 10 "" DOTS-CALL-HOME:signal.udp "" signal.example.net. 666 IN NAPTR 200 10 "" DOTS-CALL-HOME:signal.tcp "" signal.example.net. 668 signal.example.net. 669 IN NAPTR 100 10 "s" DOTS-CALL-HOME:signal.udp "" 670 _dots-call-home._udp.example.net. 671 IN NAPTR 200 10 "s" DOTS-CALL-HOME:signal.tcp "" 672 _dots-call-home._tcp.example.net. 674 _dots-call-home._udp.example.net. 675 IN SRV 0 0 6000 b.example.net. 677 _dots-call-home._tcp.example.net. 678 IN SRV 0 0 6001 b.example.net. 680 b.example.net. 681 IN AAAA 2001:db8::2 683 Figure 9: Sample Example of Discovery of DOTS Call Home Client using 684 Service Resolution 686 +-------+----------+-------------+------+ 687 | Order | Protocol | IP address | Port | 688 +-------+----------+-------------+------+ 689 | 1 | UDP | 2001:db8::2 | 6000 | 690 | 2 | TCP | 2001:db8::2 | 6001 | 691 +-------+----------+-------------+------+ 692 Table 2 694 If no DOTS-specific S-NAPTR records can be retrieved, the discovery 695 procedure fails for this domain name (and the corresponding interface 696 and IP protocol version). If more domain names are known, the 697 discovery procedure MAY perform the corresponding S-NAPTR lookups 698 immediately. However, before retrying a lookup that has failed, a 699 DOTS client MUST wait a time period that is appropriate for the 700 encountered error (e.g., NXDOMAIN, timeout, etc.). 702 7. DNS Service Discovery 704 DNS-based Service Discovery (DNS-SD) [RFC6763] provides generic 705 solutions for discovering services. DNS-SD defines a set of naming 706 rules for certain DNS record types that they use for advertising and 707 discovering services. 709 Section 4.1 of [RFC6763] specifies that a service instance name in 710 DNS-SD has the following structure: 712 . . 714 The portion specifies the DNS sub-domain where the service 715 instance is registered. It may be "local.", indicating the mDNS 716 local domain, or it may be a conventional domain name such as 717 "example.com.". 719 The portion of the DOTS service instance name MUST be 720 "_dots-signal._udp" or "_dots-signal._tcp" or "_dots-data._tcp" or 721 "_dots-call-home._udp" or "_dots-call-home._tcp". 723 8. Security Considerations 725 DOTS-related security considerations are discussed in Section 4 of 726 [I-D.ietf-dots-architecture]. As a reminder, DOTS agents must 727 authenticate each other using (D)TLS before a DOTS session is 728 considered valid according to the [I-D.ietf-dots-signal-channel]. 730 8.1. DHCP 732 The security considerations in [RFC2131] and [RFC8415] are to be 733 considered. 735 8.2. Service Resolution 737 The primary attack against the methods described in Section 6 is one 738 that would lead to impersonation of a peer DOTS agent. An attacker 739 could attempt to compromise the S-NAPTR resolution. The use of 740 mutual authentication makes it difficult to redirect a DOTS client 741 (or a Call Home DOTS server) to an illegitimate DOTS server (or a 742 Call Home DOTS client). 744 8.3. DNS Service Discovery 746 Since DNS-SD is a specification for how to name and use records in 747 the existing DNS system, it has no specific additional security 748 requirements over and above those that already apply to DNS queries 749 and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC) 750 [RFC4033] SHOULD be used where the authenticity of information is 751 important. For DNS updates, secure updates [RFC2136][RFC3007] SHOULD 752 generally be used to control which clients have permission to update 753 DNS records. 755 9. IANA Considerations 757 9.1. The Service Name and Transport Protocol Port Number Registry 759 IANA is requested to allocate the following service name from the 760 registry available at: https://www.iana.org/assignments/service- 761 names-port-numbers/service-names-port-numbers.xhtml. 763 Service Name: dots-data 764 Port Number: N/A 765 Transport Protocol(s): TCP 766 Description: DOTS Data Channel Protocol 767 The service name is used to construct the 768 SRV service name "_dots-data._tcp" for discovering 769 DOTS servers used to establish DOTS data channel. 770 Assignee: IESG 771 Contact: IETF Chair 772 Reference: [ThisDocument] 774 IANA is requested to update the following entries from the registry 775 available at: https://www.iana.org/assignments/service-names-port- 776 numbers/service-names-port-numbers.xhtml. 778 Service Name: dots-signal 779 Port Number: TBD1 780 Transport Protocol(s): TCP/UDP 781 Description: DOTS Signal Channel Protocol. 782 The service name is used to construct the 783 SRV service names "_dots-signal._udp" and 784 "_dots-signal._tcp" for discovering DOTS 785 servers used to establish DOTS signal channel. 786 Assignee: IESG 787 Contact: IETF Chair 788 Reference: [I-D.ietf-dots-signal-channel][ThisDocument] 790 Service Name: dots-call-home 791 Port Number: TBD2 792 Transport Protocol(s): TCP/UDP 793 Description: DOTS Signal Channel Call Home Protocol. 794 The service name is used to construct the 795 SRV service names "_dots-call-home._udp" and 796 "_dots-call-home._tcp" for discovering Call 797 Home DOTS clients used to establish DOTS signal 798 channel call home. 799 Assignee: IESG 800 Contact: IETF Chair 801 Reference: [I-D.ietf-dots-call-home][ThisDocument] 803 Note to the RFC Editor: Please replace TBD1 and TBD2 with the port 804 numbers to be allocated by IANA as requested in [I-D.ietf-dots- 805 signal-channel] and [I-D.ietf-dots-call-home]. 807 9.2. DHCPv6 Options 809 IANA is requested to assign the following new DHCPv6 Option Codes in 810 the registry maintained in: https://www.iana.org/assignments/dhcpv6- 811 parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. 813 Value Description Client ORO Singleton Option 814 TBD1 OPTION_V6_DOTS_RI Yes Yes 815 TBD2 OPTION_V6_DOTS_ADDRESS Yes Yes 817 9.3. DHCPv4 Options 819 IANA is requested to assign the following new DHCPv4 Option Codes in 820 the registry maintained in: https://www.iana.org/assignments/bootp- 821 dhcp-parameters/bootp-dhcp-parameters.xhtml#options. 823 Name Tag Data Meaning Reference 824 Length 825 ---------------------- ---- ---------- --------------- -------------- 826 OPTION_V4_DOTS_RI TBA3 N The name of the [ThisDocument] 827 peer DOTS 828 agent. 829 OPTION_V4_DOTS_ADDRESS TBA4 N (the N/4 IPv4 [ThisDocument] 830 minimal addresses of 831 length is peer DOTS 832 4) agent(s). 834 9.4. Application Service & Application Protocol Tags 836 This document requests IANA to make the following allocations from 837 the registries available at: https://www.iana.org/assignments/s- 838 naptr-parameters/s-naptr-parameters.xhtml#s-naptr-parameters-1 for 839 Application Service Tags and https://www.iana.org/assignments/s- 840 naptr-parameters/s-naptr-parameters.xhtml#s-naptr-parameters-2 for 841 Application Protocol Tags. 843 9.4.1. DOTS Application Service Tag Registration 845 o Application Protocol Tag: DOTS 847 o Intended Usage: See Section 6 849 o Security Considerations: See Section 8 851 o Interoperability considerations: None 853 o Relevant publications: This document 855 9.4.2. DOTS Call Home Application Service Tag Registration 857 o Application Protocol Tag: DOTS-CALL-HOME 859 o Intended Usage: See Section 6 861 o Security Considerations: See Section 8 863 o Interoperability considerations: None 865 o Relevant publications: This document 867 9.4.3. signal.udp Application Protocol Tag Registration 869 o Application Protocol Tag: signal.udp 871 o Intended Usage: See Section 6 873 o Security Considerations: See Section 8 875 o Interoperability considerations: None 877 o Relevant publications: This document 879 9.4.4. signal.tcp Application Protocol Tag Registration 881 o Application Protocol Tag: signal.tcp 883 o Intended Usage: See Section 6 885 o Security Considerations: See Section 8 887 o Interoperability considerations: None 889 o Relevant publications: This document 891 9.4.5. data.tcp Application Protocol Tag Registration 893 o Application Protocol Tag: data.tcp 895 o Intended Usage: See Section 6 897 o Security Considerations: See Section 8 899 o Interoperability considerations: None 901 o Relevant publications: This document 903 10. Contributors 905 Prashanth Patil 906 Cisco Systems, Inc. 908 Email: praspati@cisco.com 910 11. Acknowledgements 912 Thanks to Brian Carpenter for the review of the BRSKI text. 914 Many thanks to Russ White for the review, comments, and text 915 contribution. 917 Thanks for Dan Wing, Pei Wei, Valery Smyslov, and Jon Shallow for the 918 review and comments. 920 Thanks to Bernie Volz for the review of the DHCP section. 922 12. References 924 12.1. Normative References 926 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 927 Requirement Levels", BCP 14, RFC 2119, 928 DOI 10.17487/RFC2119, March 1997, 929 . 931 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 932 RFC 2131, DOI 10.17487/RFC2131, March 1997, 933 . 935 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 936 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 937 . 939 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 940 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 941 DOI 10.17487/RFC3396, November 2002, 942 . 944 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 945 Service Location Using SRV RRs and the Dynamic Delegation 946 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 947 January 2005, . 949 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 950 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 951 2006, . 953 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 954 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 955 . 957 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 958 "Special-Purpose IP Address Registries", BCP 153, 959 RFC 6890, DOI 10.17487/RFC6890, April 2013, 960 . 962 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 963 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 964 May 2017, . 966 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 967 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 968 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 969 RFC 8415, DOI 10.17487/RFC8415, November 2018, 970 . 972 12.2. Informative References 974 [I-D.ietf-anima-bootstrapping-keyinfra] 975 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 976 and K. Watsen, "Bootstrapping Remote Secure Key 977 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 978 keyinfra-34 (work in progress), January 2020. 980 [I-D.ietf-dots-architecture] 981 Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and 982 R. Compton, "Distributed-Denial-of-Service Open Threat 983 Signaling (DOTS) Architecture", draft-ietf-dots- 984 architecture-14 (work in progress), May 2019. 986 [I-D.ietf-dots-data-channel] 987 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 988 Service Open Threat Signaling (DOTS) Data Channel 989 Specification", draft-ietf-dots-data-channel-31 (work in 990 progress), July 2019. 992 [I-D.ietf-dots-multihoming] 993 Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing 994 Deployment Considerations for Distributed-Denial-of- 995 Service Open Threat Signaling (DOTS)", draft-ietf-dots- 996 multihoming-02 (work in progress), July 2019. 998 [I-D.ietf-dots-signal-call-home] 999 Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed 1000 Denial-of-Service Open Threat Signaling (DOTS) Signal 1001 Channel Call Home", draft-ietf-dots-signal-call-home-07 1002 (work in progress), November 2019. 1004 [I-D.ietf-dots-signal-channel] 1005 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 1006 N. Teague, "Distributed Denial-of-Service Open Threat 1007 Signaling (DOTS) Signal Channel Specification", draft- 1008 ietf-dots-signal-channel-41 (work in progress), January 1009 2020. 1011 [I-D.ietf-dots-use-cases] 1012 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 1013 L., and K. Nishizuka, "Use cases for DDoS Open Threat 1014 Signaling", draft-ietf-dots-use-cases-20 (work in 1015 progress), September 2019. 1017 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1018 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1019 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1020 . 1022 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1023 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 1024 . 1026 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1027 Rose, "DNS Security Introduction and Requirements", 1028 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1029 . 1031 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1032 Verification of Domain-Based Application Service Identity 1033 within Internet Public Key Infrastructure Using X.509 1034 (PKIX) Certificates in the Context of Transport Layer 1035 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1036 2011, . 1038 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 1039 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 1040 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 1041 . 1043 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1044 Touch Provisioning (SZTP)", RFC 8572, 1045 DOI 10.17487/RFC8572, April 2019, 1046 . 1048 Authors' Addresses 1050 Mohamed Boucadair 1051 Orange 1052 Rennes 35000 1053 France 1055 Email: mohamed.boucadair@orange.com 1056 Tirumaleswar Reddy 1057 McAfee, Inc. 1058 Embassy Golf Link Business Park 1059 Bangalore, Karnataka 560071 1060 India 1062 Email: TirumaleswarReddy_Konda@McAfee.com