idnits 2.17.1 draft-ietf-dots-server-discovery-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 18, 2019) is 1621 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 (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-29 == 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-06 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-38 == 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: 0 errors (**), 0 flaws (~~), 7 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: May 21, 2020 McAfee 6 November 18, 2019 8 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent 9 Discovery 10 draft-ietf-dots-server-discovery-06 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 May 21, 2020. 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? . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 17 75 8.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 8.2. Service Resolution . . . . . . . . . . . . . . . . . . . 17 77 8.3. DNS Service Discovery . . . . . . . . . . . . . . . . . . 17 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 9.1. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 18 80 9.2. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . 18 81 9.3. Application Service & Application Protocol Tags . . . . . 18 82 9.3.1. DOTS Application Service Tag Registration . . . . . . 18 83 9.3.2. DOTS Call Home Application Service Tag Registration . 19 84 9.3.3. signal.udp Application Protocol Tag Registration . . 19 85 9.3.4. signal.tcp Application Protocol Tag Registration . . 19 86 9.3.5. data.tcp Application Protocol Tag Registration . . . 19 87 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 91 12.2. Informative References . . . . . . . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 the DOTS data channel protocol 109 [I-D.ietf-dots-data-channel]. 111 The basic high-level DOTS architecture is illustrated in Figure 1: 113 +-----------+ +-------------+ 114 | Mitigator | ~~~~~~~~~~ | DOTS Server | 115 +-----------+ +------+------+ 116 | 117 | 118 | 119 +---------------+ +------+------+ 120 | Attack Target | ~~~~~~ | DOTS Client | 121 +---------------+ +-------------+ 123 Figure 1: Basic DOTS Architecture 125 [I-D.ietf-dots-architecture] specifies that the DOTS client may be 126 provided with a list of DOTS servers; each associated with one or 127 more IP addresses. These addresses may or may not be of the same 128 address family. The DOTS client establishes one or more DOTS 129 sessions by connecting to the provided DOTS server addresses. 131 This document specifies methods for DOTS clients to discover their 132 DOTS server(s). The rationale for specifying multiple discovery 133 mechanisms is discussed in Section 3. 135 The discovery methods can also be used by a DOTS server to locate a 136 DOTS client in the context of DOTS Signal Channel Call Home 137 [I-D.ietf-dots-signal-call-home]. The basic high-level DOTS Call 138 Home architecture is illustrated in Figure 2: 140 +---------------+ +-------------+ 141 | Alert/DMS/ | ~~~~~~ | Call Home | 142 | Peer DMS/... | | DOTS client | 143 +---------------+ +------+------+ 144 | 145 | 146 | 147 +---------------+ +------+------+ 148 | Attack | ~~~~~~ | Call Home | 149 | Source(s) | | DOTS server | 150 +---------------+ +-------------+ 152 Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture 154 A DOTS agent may be used to establish base DOTS channels, DOTS Call 155 Home, or both. This specification accommodates all these deployment 156 cases. 158 Considerations for the selection of DOTS server(s) by multi-homed 159 DOTS clients is out of scope; the reader should refer to 160 [I-D.ietf-dots-multihoming] for more details. 162 This document assumes that security credentials to authenticate DOTS 163 server(s) are provisioned to a DOTS client using a variety of means 164 such as (but not limited to) those discussed in [RFC8572] or 165 [I-D.ietf-anima-bootstrapping-keyinfra]. DOTS clients use those 166 credentials for authentication purposes following the rules 167 documented in [I-D.ietf-dots-signal-channel]. 169 2. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119][RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 The reader should be familiar with the terms defined in 178 [I-D.ietf-dots-architecture], [RFC3958], and 179 [I-D.ietf-dots-signal-call-home]. 181 DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC8415]. 183 "Peer DOTS agent" refers to the peer DOTS server (base DOTS 184 operation) or to a peer Call Home DOTS client (for DOTS Signal 185 Channel Call Home). 187 3. Why Multiple Discovery Mechanisms? 189 It is tempting to specify one single discovery mechanism for DOTS. 190 Nevertheless, the analysis of the various use cases sketched in 191 [I-D.ietf-dots-use-cases] reveals that it is unlikely that one single 192 discovery method can be suitable for all the sample deployments. 193 Concretely: 195 o Many use cases discussed in [I-D.ietf-dots-use-cases] do involve a 196 CPE device. Multiple CPEs, connected to distinct network 197 providers may even be considered. It is intuitive to leverage on 198 existing mechanisms such as discovery using service resolution or 199 DHCP to provision the CPE acting as a DOTS client with the DOTS 200 server(s). 202 o Resolving a DOTS server domain name offered by an upstream transit 203 provider provisioned to a DOTS client into IP address(es) require 204 the use of the appropriate DNS resolvers; otherwise, resolving 205 those names will fail. The use of protocols such as DHCP does 206 allow to associate provisioned DOTS server domain names with a 207 list of DNS servers to be used for name resolution. Furthermore, 208 DHCP allows to directly provision IP addresses avoiding therefore 209 the need for extra lookup delays. 211 o Some of the use cases may allow DOTS clients to have direct 212 communications with upstream DOTS servers; that is no DOTS gateway 213 is involved. Leveraging on existing features that do not require 214 specific feature on the node embedding the DOTS client may ease 215 DOTS deployment. Typically, the use of Straightforward-Naming 216 Authority Pointer (S-NAPTR) lookups [RFC3958] allows the DOTS 217 server administrators to provision the preferred DOTS transport 218 protocol between the DOTS client and the DOTS server and allows 219 the DOTS client to discover this preference. 221 o The upstream network provider is not the DDoS mitigation provider 222 for some of these use cases. It is safe to assume that for such 223 deployments, the DOTS server(s) domain name is provided during the 224 service subscription (i.e., manual/local configuration). 226 o Multiple DOTS clients may be enabled within a network (e.g., 227 enterprise network). Dynamic means to discover DOTS servers in a 228 deterministic manner are interesting from an operational 229 standpoint. 231 o Some of the use cases may involve a DOTS gateway that is 232 responsible for selecting the appropriate DOTS server(s) to relay 233 requests received from DOTS clients. 235 Consequently, this document describes a unified discovery logic 236 (Section 4) which involves the following mechanisms: 238 o Dynamic discovery using DHCP (Section 5). 240 o A resolution mechanism based on straightforward Naming Authority 241 Pointer (S-NAPTR) resource records in the Domain Name System (DNS) 242 (Section 6). 244 o DNS Service Discovery (Section 7). 246 4. Unified DOTS Discovery Procedure 248 A key point in the deployment of DOTS is the ability of network 249 operators to be able to configure DOTS clients with the correct DOTS 250 server(s) information consistently. To accomplish this, operators 251 will need a consistent set of ways in which DOTS clients can discover 252 this information, and a consistent priority among these options. If 253 some devices prefer manual configuration over dynamic discovery, 254 while others prefer dynamic discovery over manual configuration, the 255 result will be a process of "whack-a-mole", where the operator must 256 find devices that are using the wrong DOTS server(s), determine how 257 to ensure the devices are configured properly, and then reconfigure 258 the device through the preferred method. 260 All DOTS clients MUST support at least one of the three mechanisms 261 below to determine a DOTS server list. All DOTS clients SHOULD 262 implement all three, or as many as are practical for any specific 263 device (e.g., a CPE will support the first two mechanisms, a host 264 within a LAN will support the last two mechanisms, or an application 265 server will support a local configuration. More samples are 266 discussed in Section 3), of these ways to discover DOTS servers, in 267 order to facilitate the deployment of DOTS in large scale 268 environments: 270 1. Explicit configuration: 272 * Local/Manual configuration: A DOTS client, will learn the DOTS 273 server(s) by means of local or manual DOTS configuration 274 (i.e., DOTS servers configured at the system level). 275 Configuration discovered from a DOTS client application is 276 considered as local configuration. 278 An implementation may give the user an opportunity (e.g., by 279 means of configuration file options or menu items) to specify 280 DOTS server(s) for each address family. These may be 281 specified either as IP addresses or the DNS name of a DOTS 282 server. When only DOTS server's IP addresses are configured, 283 a reference identifier must also be configured for 284 authentication purposes. 286 * Automatic configuration (e.g., DHCP, an automation system): 287 The DOTS client attempts to discover DOTS server(s) names and/ 288 or addresses from DHCP, as described in Section 5. 290 2. Service Resolution : The DOTS client attempts to discover DOTS 291 server name(s) using service resolution, as specified in 292 Section 6. 294 3. DNS SD: DNS Service Discovery. The DOTS client attempts to 295 discover DOTS server name(s) using DNS service discovery, as 296 specified in Section 7. 298 Some of these mechanisms imply the use of DNS to resolve the IP 299 address(es) of the DOTS server, while others imply an IP address of 300 the relevant DOTS server is obtained directly. Implementation 301 options may vary on a per device basis, as some devices may not have 302 DNS capabilities and/or proper configuration. 304 DOTS clients will prefer information received from the discovery 305 methods in the order listed. 307 On hosts with more than one interface or address family (IPv4/v6), 308 the DOTS server discovery procedure has to be performed for each 309 combination of interface and address family. A DOTS client may 310 choose to perform the discovery procedure only for a desired 311 interface/address combination if the client does not wish to discover 312 a DOTS server for all combinations of interface and address family. 314 This procedure is also followed by a Call Home DOTS server to 315 discover its Call Home DOTS client in the context of 316 [I-D.ietf-dots-signal-call-home]. 318 The discovery method is reiterated by a DOTS agent upon the following 319 events: 321 o Expiry of a lease associated with a discovered DOTS agent. 323 o Expiry of a peer DOTS agent's certificate currently in use. 325 o Attachment to a new network. 327 5. DHCP Options for DOTS Agent Discovery 329 As reported in Section 1.7.2 of [RFC6125]: 331 "few certification authorities issue server certificates based on 332 IP addresses, but preliminary evidence indicates that such 333 certificates are a very small percentage (less than 1%) of issued 334 certificates". 336 In order to allow for PKIX-based authentication between a DOTS client 337 and server while accommodating for the current best practices for 338 issuing certificates, this document allows for configuring names to 339 DOTS clients. These names can be used for two purposes: to retrieve 340 the list of IP addresses of a DOTS server or to be presented as a 341 reference identifier for authentication purposes. 343 Defining the option to include a list of IP addresses would avoid a 344 dependency on an underlying name resolution, but that design requires 345 to also supply a name for PKIX-based authentication purposes. 347 The list of the IP addresses returned by DHCP servers is typically 348 used to fed the DOTS server selection procedure or to provide DOTS 349 agents with primary and backup IP addresses of their peer DOTS 350 agents. 352 The design assumes that the same peer DOTS agent is used for 353 establishing both signal and data channels. For more customized 354 configurations (e.g., transport-specific configuration, distinct DOTS 355 servers for the signal and the data channels), an operator can supply 356 only a DOTS reference identifier that will be then passed to the 357 procedure described in Section 6. 359 The design allows to terminate the base DOTS channels and DOTS Call 360 Home on the same or distinct peer DOTS agents. If distinct peer DOTS 361 agents are deployed, the DHCP option can return, for example, a list 362 of IP addresses to a requesting DOTS agent. This list includes the 363 IP address to be used for the base DOTS channels and the IP address 364 for the DOTS Call Home. The DOTS client (or Call Home DOTS server) 365 will then use the address selection specified in Section 4.3 of 366 [I-D.ietf-dots-signal-channel] to identify the IP address of the peer 367 DOTS server (or Call Home DOTS client). For example: 369 Let's consider that the DOTS server is reachable at 370 2001:db8:122:300::1 while the Call Home DOTS client is reachable 371 at 2001:db8:122:300::2. The DHCP server will then return one DOTS 372 reference identifier and a list that includes both 373 2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP 374 client. That list is passed to the DOTS client (or Call Home DOTS 375 server) which will try to establish connections to the addresses 376 of that list and destination port number 4646 (or 4647). As a 377 result, the DOTS client (or Call Home DOTS server) will select 378 2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server (or 379 Call Home DOTS client). 381 5.1. DHCPv6 DOTS Options 383 5.1.1. Format of DOTS Reference Identifier Option 385 The DHCPv6 DOTS Reference Identifier option is used to configure a 386 name of the DOTS server (or the name of the Call Home DOTS client). 387 The format of this option is shown in Figure 3. 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | OPTION_V6_DOTS_RI | Option-length | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 | dots-agent-name (FQDN) | 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Figure 3: DHCPv6 DOTS Reference Identifier Option 400 The fields of the option shown in Figure 3 are as follows: 402 o Option-code: OPTION_V6_DOTS_RI (TBA1, see Section 9.1) 403 o Option-length: Length of the dots-agent-name field in octets. 404 o dots-agent-name: A fully qualified domain name of the peer DOTS 405 agent. This field is formatted as specified in Section 10 of 406 [RFC8415]. 408 An example of the dots-agent-name encoding is shown in Figure 4. 409 This example conveys the FQDN "dots.example.com.". 411 +------+------+------+------+------+------+------+------+------+ 412 | 0x04 | d | o | t | s | 0x07 | e | x | a | 413 +------+------+------+------+------+------+------+------+------+ 414 | m | p | l | e | 0x03 | c | o | m | 0x00 | 415 +------+------+------+------+------+------+------+------+------+ 417 Figure 4: An example of the dots-agent-name Encoding 419 5.1.2. Format of DOTS Address Option 421 The DHCPv6 DOTS Address option can be used to configure a list of 422 IPv6 addresses of a DOTS server (or a Call Home DOTS client). The 423 format of this option is shown in Figure 5. As a reminder, this 424 format follows the guidelines for creating new DHCPv6 options 425 (Section 5.1 of [RFC7227]). 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | OPTION_V6_DOTS_ADDRESS | Option-length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | | 432 | DOTS ipv6-address | 433 | | 434 | | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 | DOTS ipv6-address | 438 | | 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | ... | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Figure 5: DHCPv6 DOTS Address Option 446 The fields of the option shown in Figure 5 are as follows: 448 o Option-code: OPTION_V6_DOTS_ADDRESS (TBA2, see Section 9.1) 449 o Option-length: Length of the 'DOTS ipv6-address(es)' field in 450 octets. MUST be a multiple of 16. 451 o DOTS ipv6-address: Includes one or more IPv6 addresses [RFC4291] 452 of the peer DOTS agent to be used by a DOTS agent for establishing 453 a DOTS session. 455 Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) 456 are allowed to be included in this option. 458 5.1.3. DHCPv6 Client Behavior 460 DHCP clients MAY request options OPTION_V6_DOTS_RI and 461 OPTION_V6_DOTS_ADDRESS, as defined in [RFC8415], Sections 18.2.1, 462 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. As a convenience to the 463 reader, it is mentioned here that the DHCP client includes the 464 requested option codes in the Option Request Option. 466 If the DHCP client receives more than one instance of 467 OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use 468 only the first instance of that option. 470 If the DHCP client receives both OPTION_V6_DOTS_RI and 471 OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 472 reference identifier for authentication purposes (e.g., PKIX 473 [RFC6125]), while the addresses included in OPTION_V6_DOTS_ADDRESS 474 are used to reach the peer DOTS agent. In other words, the name 475 conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying 476 resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a 477 response. 479 If the DHCP client receives OPTION_V6_DOTS_RI only, but 480 OPTION_V6_DOTS_RI option contains more than one name, as 481 distinguished by the presence of multiple root labels, the DHCP 482 client MUST use only the first name. Once the name is validated 483 (Section 8 of [RFC8415]), the name is passed to a name resolution 484 library. Moreover, that name is also used as a reference identifier 485 for authentication purposes. 487 If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the 488 address(es) included in OPTION_V6_DOTS_ADDRESS are used to reach the 489 peer DOTS agent. In addition, these addresses can be used as 490 identifiers for authentication. 492 The DHCP client MUST silently discard multicast and host loopback 493 addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS. 495 5.2. DHCPv4 DOTS Options 497 5.2.1. Format of DOTS Reference Identifier Option 499 The DHCPv4 DOTS Reference Identifier option is used to configure a 500 name of the peer DOTS agent. The format of this option is 501 illustrated in Figure 6. 503 Code Length Peer DOTS agent name 504 +-----+-----+-----+-----+-----+-----+-----+-- 505 |TBA3 | n | s1 | s2 | s3 | s4 | s5 | ... 506 +-----+-----+-----+-----+-----+-----+-----+-- 508 The values s1, s2, s3, etc. represent the domain name labels in the 509 domain name encoding. 511 Figure 6: DHCPv4 DOTS Reference Identifier Option 513 The fields of the option shown in Figure 6 are as follows: 515 o Code: OPTION_V4_DOTS_RI (TBA3, see Section 9.2). 516 o Length: Includes the length of the "Peer DOTS agent name" field in 517 octets; the maximum length is 255 octets. 518 o Peer DOTS agent name: The domain name of the peer DOTS agent. 519 This field is formatted as specified in Section 10 of [RFC8415]. 521 5.2.2. Format of DOTS Address Option 523 The DHCPv4 DOTS Address option can be used to configure a list of 524 IPv4 addresses of a peer DOTS agent. The format of this option is 525 illustrated in Figure 7. 527 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Code=TBA4 | Length | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | | 532 + DOTS IPv4 Address | 533 | | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 535 | | | 536 + DOTS IPv4 Address | | 537 | | optional 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 539 . ... . | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 542 Figure 7: DHCPv4 DOTS Address Option 544 The fields of the option shown in Figure 7 are as follows: 546 o Code: OPTION_V4_DOTS_ADDRESS (TBA4, see Section 9.2). 547 o Length: is set to 4*N, where N is the number of IPv4 addresses 548 included in the option. 549 o DOTS IPv4 Address(es): Contains one or more IPv4 addresses of the 550 peer DOTS agent to be used by a DOTS agent. 552 OPTION_V4_DOTS_ADDRESS is a concatenation-requiring option. As such, 553 the mechanism specified in [RFC3396] MUST be used if 554 OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255 555 octets. 557 5.2.3. DHCPv4 Client Behavior 559 To discover a peer DOTS agent, the DHCPv4 client MUST include both 560 OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request 561 List Option [RFC2132]. 563 If the DHCP client receives more than one instance of 564 OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST use 565 only the first instance of that option. 567 If the DHCP client receives both OPTION_V4_DOTS_RI and 568 OPTION_V4_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 569 reference identifier for authentication purposes, while the addresses 570 included in OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS 571 agent. In other words, the name conveyed in OPTION_V4_DOTS_RI MUST 572 NOT be passed to underlying resolution library in the presence of 573 OPTION_V4_DOTS_ADDRESS in a response. 575 If the DHCP client receives OPTION_V4_DOTS_RI only, but 576 OPTION_V4_DOTS_RI option contains more than one name, as 577 distinguished by the presence of multiple root labels, the DHCP 578 client MUST use only the first name. Once the name is validated 579 (Section 10 of [RFC8415]), the name is passed to a name resolution 580 library. Moreover, that name is also used as a reference identifier 581 for authentication purposes. 583 If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the 584 address(es) included in OPTION_V4_DOTS_ADDRESS are used to reach the 585 peer DOTS server. In addition, these addresses can be used as 586 identifiers for authentication. 588 The DHCP client MUST silently discard multicast and host loopback 589 addresses conveyed in OPTION_V4_DOTS_ADDRESS. 591 6. Discovery using Service Resolution 593 This mechanism is performed in two steps: 595 1. A DNS domain name is retrieved for each combination of interface 596 and address family. A DOTS agent has to determine the domain in 597 which it is located relying on dynamic means such as DHCP 598 (Section 5) . Implementations may allow the user to specify a 599 default name that is used, if no specific name has been 600 configured. 602 2. Retrieved DNS domain names are then used for S-NAPTR lookups 603 [RFC3958]. Further DNS lookups may be necessary to determine the 604 peer DOTS agent IP address(es). 606 Once the DOTS agent has retrieved its DNS domain or discovered the 607 peer DOTS agent name that needs to be resolved (e.g., Section 5), an 608 S-NAPTR lookup with 'DOTS' application service and the desired 609 protocol tag is made to obtain information necessary to connect to 610 the authoritative peer DOTS agent within the given domain. 612 This specification defines "DOTS" and "DOTS-CALL-HOME" as application 613 service tags (Sections 9.3.1 and 9.3.2). It also defines 614 "signal.udp" (Section 9.3.3), "signal.tcp" (Section 9.3.4), and 615 "data.tcp" (Section 9.3.5) as application protocol tags. An example 616 is provided in Figure 8. 618 In the example below, for domain 'example.net', the resolution 619 algorithm will result in IP address(es), port, tag and protocol 620 tuples as follows: 622 example.net. 623 IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. 624 IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. 625 IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net. 627 signal.example.net. 628 IN NAPTR 100 10 "s" DOTS:signal.udp "" _dots._signal._udp.example.net. 629 IN NAPTR 200 10 "s" DOTS:signal.tcp "" _dots._signal._tcp.example.net. 631 data.example.net. 632 IN NAPTR 100 10 "s" DOTS:data.tcp "" _dots._data._tcp.example.net. 634 _dots._signal._udp.example.net. 635 IN SRV 0 0 5000 a.example.net. 637 _dots._signal._tcp.example.net. 638 IN SRV 0 0 5001 a.example.net. 640 _dots._data._tcp.example.net. 641 IN SRV 0 0 5002 a.example.net. 643 a.example.net. 644 IN AAAA 2001:db8::1 646 +-------+----------+-------------+------+--------+ 647 | Order | Protocol | IP address | Port | Tag | 648 +-------+----------+-------------+------+--------+ 649 | 1 | UDP | 2001:db8::1 | 5000 | Signal | 650 | 2 | TCP | 2001:db8::1 | 5001 | Signal | 651 | 3 | TCP | 2001:db8::1 | 5002 | Data | 652 +-------+----------+-------------+------+--------+ 654 Figure 8: Sample Example of Discovery of DOTS Servers using Service 655 Resolution 657 An example is provided in Figure 9 for the Call Home case. 659 In the example below, for domain 'example.net', the resolution 660 algorithm will result in IP address(es), port, tag and protocol 661 tuples as follows: 663 example.net. 664 IN NAPTR 100 10 "" DOTS-CALL-HOME:signal.udp "" signal.example.net. 665 IN NAPTR 200 10 "" DOTS-CALL-HOME:signal.tcp "" signal.example.net. 667 signal.example.net. 668 IN NAPTR 100 10 "s" DOTS-CALL-HOME:signal.udp "" 669 _dots-call-home._signal._udp.example.net. 670 IN NAPTR 200 10 "s" DOTS-CALL-HOME:signal.tcp "" 671 _dots-call-home._signal._tcp.example.net. 673 _dots-call-home._signal._udp.example.net. 674 IN SRV 0 0 6000 b.example.net. 676 _dots-call-home._signal._tcp.example.net. 677 IN SRV 0 0 6001 b.example.net. 679 b.example.net. 680 IN AAAA 2001:db8::2 682 +-------+----------+-------------+------+--------+ 683 | Order | Protocol | IP address | Port | Tag | 684 +-------+----------+-------------+------+--------+ 685 | 1 | UDP | 2001:db8::2 | 6000 | Signal | 686 | 2 | TCP | 2001:db8::2 | 6001 | Signal | 687 +-------+----------+-------------+------+--------+ 689 Figure 9: Sample Example of Discovery of DOTS Call Home Client using 690 Service Resolution 692 If no DOTS-specific S-NAPTR records can be retrieved, the discovery 693 procedure fails for this domain name (and the corresponding interface 694 and IP protocol version). If more domain names are known, the 695 discovery procedure MAY perform the corresponding S-NAPTR lookups 696 immediately. However, before retrying a lookup that has failed, a 697 DOTS client MUST wait a time period that is appropriate for the 698 encountered error (e.g., NXDOMAIN, timeout, etc.). 700 7. DNS Service Discovery 702 DNS-based Service Discovery (DNS-SD) [RFC6763] provides generic 703 solutions for discovering services. DNS-SD defines a set of naming 704 rules for certain DNS record types that they use for advertising and 705 discovering services. 707 Section 4.1 of [RFC6763] specifies that a service instance name in 708 DNS-SD has the following structure: 710 . . 712 The portion specifies the DNS sub-domain where the service 713 instance is registered. It may be "local.", indicating the mDNS 714 local domain, or it may be a conventional domain name such as 715 "example.com.". 717 The portion of the DOTS service instance name MUST be 718 "_dots._signal._udp" or "_dots._signal._tcp" or "_dots._data._tcp" or 719 "_dots-call-home._signal._udp" or "_dots-call-home._signal._tcp". 721 8. Security Considerations 723 DOTS-related security considerations are discussed in Section 4 of 724 [I-D.ietf-dots-architecture]. As a reminder, DOTS agents must 725 authenticate each other using (D)TLS before a DOTS session is 726 considered valid according to the [I-D.ietf-dots-signal-channel]. 728 8.1. DHCP 730 The security considerations in [RFC2131] and [RFC8415] are to be 731 considered. 733 8.2. Service Resolution 735 The primary attack against the methods described in Section 6 is one 736 that would lead to impersonation of a peer DOTS agent. An attacker 737 could attempt to compromise the S-NAPTR resolution. The use of 738 mutual authentication makes it difficult to redirect a DOTS client 739 (or a Call Home DOTS server) to an illegitimate DOTS server (or a 740 Call Home DOTS client). 742 8.3. DNS Service Discovery 744 Since DNS-SD is a specification for how to name and use records in 745 the existing DNS system, it has no specific additional security 746 requirements over and above those that already apply to DNS queries 747 and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC) 748 [RFC4033] SHOULD be used where the authenticity of information is 749 important. For DNS updates, secure updates [RFC2136][RFC3007] SHOULD 750 generally be used to control which clients have permission to update 751 DNS records. 753 9. IANA Considerations 755 IANA is requested to allocate the SRV service name of "_dots._signal" 756 for DOTS signal channel over UDP or TCP, and the service name of 757 "_dots._data" for DOTS data channel over TCP. 759 9.1. DHCPv6 Options 761 IANA is requested to assign the following new DHCPv6 Option Codes in 762 the registry maintained in: http://www.iana.org/assignments/ 763 dhcpv6-parameters. 765 Value Description Client ORO Singleton Option 766 TBD1 OPTION_V6_DOTS_RI Yes Yes 767 TBD2 OPTION_V6_DOTS_ADDRESS Yes Yes 769 9.2. DHCPv4 Options 771 IANA is requested to assign the following new DHCPv4 Option Codes in 772 the registry maintained in: http://www.iana.org/assignments/bootp- 773 dhcp-parameters/. 775 Option Name Value Data length Meaning 776 ---------------------- ----- ----------------- ---------------------- 777 OPTION_V4_DOTS_RI TBA3 Variable; the Includes the name of 778 maximum length is the peer DOTS agent. 779 255 octets. 780 OPTION_V4_DOTS_ADDRESS TBA4 Variable Includes one or more 781 IP addresses of peer 782 DOTS agent(s). 784 9.3. Application Service & Application Protocol Tags 786 This document requests IANA to make the following allocations from 787 the registry available at: https://www.iana.org/assignments/s-naptr- 788 parameters/s-naptr-parameters.xhtml. 790 9.3.1. DOTS Application Service Tag Registration 792 o Application Protocol Tag: DOTS 794 o Intended Usage: See Section 6 796 o Security Considerations: See Section 8 798 o Contact Information: 800 9.3.2. DOTS Call Home Application Service Tag Registration 802 o Application Protocol Tag: DOTS-CALL-HOME 804 o Intended Usage: See Section 6 806 o Security Considerations: See Section 8 808 o Contact Information: 810 9.3.3. signal.udp Application Protocol Tag Registration 812 o Application Protocol Tag: signal.udp 814 o Intended Usage: See Section 6 816 o Security Considerations: See Section 8 818 o Contact Information: 820 9.3.4. signal.tcp Application Protocol Tag Registration 822 o Application Protocol Tag: signal.tcp 824 o Intended Usage: See Section 6 826 o Security Considerations: See Section 8 828 o Contact Information: 830 9.3.5. data.tcp Application Protocol Tag Registration 832 o Application Protocol Tag: data.tcp 834 o Intended Usage: See Section 6 836 o Security Considerations: See Section 8 838 o Contact Information: 840 10. Contributors 842 Prashanth Patil 843 Cisco Systems, Inc. 845 Email: praspati@cisco.com 847 11. Acknowledgements 849 Thanks to Brian Carpenter for the review of the BRSKI text. 851 Many thanks to Russ White for the review, comments, and text 852 contribution. 854 Thanks for Dan Wing, Pei Wei, Valery Smyslov, and Jon Shallow for the 855 review and comments. 857 Thanks to Bernie Volz for the review of the DHCP section. 859 12. References 861 12.1. Normative References 863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 864 Requirement Levels", BCP 14, RFC 2119, 865 DOI 10.17487/RFC2119, March 1997, 866 . 868 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 869 RFC 2131, DOI 10.17487/RFC2131, March 1997, 870 . 872 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 873 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 874 . 876 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 877 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 878 DOI 10.17487/RFC3396, November 2002, 879 . 881 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 882 Service Location Using SRV RRs and the Dynamic Delegation 883 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 884 January 2005, . 886 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 887 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 888 2006, . 890 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 891 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 892 . 894 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 895 "Special-Purpose IP Address Registries", BCP 153, 896 RFC 6890, DOI 10.17487/RFC6890, April 2013, 897 . 899 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 900 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 901 May 2017, . 903 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 904 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 905 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 906 RFC 8415, DOI 10.17487/RFC8415, November 2018, 907 . 909 12.2. Informative References 911 [I-D.ietf-anima-bootstrapping-keyinfra] 912 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 913 and K. Watsen, "Bootstrapping Remote Secure Key 914 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 915 keyinfra-29 (work in progress), October 2019. 917 [I-D.ietf-dots-architecture] 918 Mortensen, A., K, R., Andreasen, F., Teague, N., and R. 919 Compton, "Distributed-Denial-of-Service Open Threat 920 Signaling (DOTS) Architecture", draft-ietf-dots- 921 architecture-14 (work in progress), May 2019. 923 [I-D.ietf-dots-data-channel] 924 Boucadair, M. and R. K, "Distributed Denial-of-Service 925 Open Threat Signaling (DOTS) Data Channel Specification", 926 draft-ietf-dots-data-channel-31 (work in progress), July 927 2019. 929 [I-D.ietf-dots-multihoming] 930 Boucadair, M., K, R., and W. Pan, "Multi-homing Deployment 931 Considerations for Distributed-Denial-of-Service Open 932 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-02 933 (work in progress), July 2019. 935 [I-D.ietf-dots-signal-call-home] 936 K, R., Boucadair, M., and J. Shallow, "Distributed Denial- 937 of-Service Open Threat Signaling (DOTS) Signal Channel 938 Call Home", draft-ietf-dots-signal-call-home-06 (work in 939 progress), September 2019. 941 [I-D.ietf-dots-signal-channel] 942 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 943 Teague, "Distributed Denial-of-Service Open Threat 944 Signaling (DOTS) Signal Channel Specification", draft- 945 ietf-dots-signal-channel-38 (work in progress), October 946 2019. 948 [I-D.ietf-dots-use-cases] 949 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 950 L., and K. Nishizuka, "Use cases for DDoS Open Threat 951 Signaling", draft-ietf-dots-use-cases-20 (work in 952 progress), September 2019. 954 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 955 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 956 RFC 2136, DOI 10.17487/RFC2136, April 1997, 957 . 959 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 960 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 961 . 963 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 964 Rose, "DNS Security Introduction and Requirements", 965 RFC 4033, DOI 10.17487/RFC4033, March 2005, 966 . 968 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 969 Verification of Domain-Based Application Service Identity 970 within Internet Public Key Infrastructure Using X.509 971 (PKIX) Certificates in the Context of Transport Layer 972 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 973 2011, . 975 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 976 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 977 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 978 . 980 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 981 Touch Provisioning (SZTP)", RFC 8572, 982 DOI 10.17487/RFC8572, April 2019, 983 . 985 Authors' Addresses 987 Mohamed Boucadair 988 Orange 989 Rennes 35000 990 France 992 Email: mohamed.boucadair@orange.com 994 Tirumaleswar Reddy 995 McAfee, Inc. 996 Embassy Golf Link Business Park 997 Bangalore, Karnataka 560071 998 India 1000 Email: TirumaleswarReddy_Konda@McAfee.com