idnits 2.17.1 draft-boucadair-dots-server-discovery-05.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 is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 875 has weird spacing: '...minimum lists...' -- The document date (October 7, 2018) is 2021 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 (-18) exists of draft-ietf-dots-architecture-07 ** Downref: Normative reference to an Informational draft: draft-ietf-dots-architecture (ref. 'I-D.ietf-dots-architecture') ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-04) exists of draft-boucadair-dots-multihoming-03 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-16 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-25 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-16 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy 5 Expires: April 10, 2019 McAfee 6 P. Patil 7 Cisco 8 October 7, 2018 10 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server 11 Discovery 12 draft-boucadair-dots-server-discovery-05 14 Abstract 16 It may not be possible for a network to determine the cause for an 17 attack, but instead just realize that some resources seem to be under 18 attack. To fill that gap, Distributed-Denial-of-Service Open Threat 19 Signaling (DOTS) allows a network to inform a DOTS server that it is 20 under a potential attack so that appropriate mitigation actions are 21 undertaken. 23 This document specifies mechanisms to configure nodes with DOTS 24 servers. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 10, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Why Multiple Discovery Mechanisms? . . . . . . . . . . . . . 5 64 5. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 7 65 6. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Discovery using Service Resolution . . . . . . . . . . . . . 10 67 7.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 10 68 7.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 11 70 8.1. DNS-SD . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.2. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9. DHCP Options for DOTS . . . . . . . . . . . . . . . . . . . . 11 73 9.1. DHCPv6 DOTS Options . . . . . . . . . . . . . . . . . . . 12 74 9.1.1. Format of DOTS Reference Identifier Option . . . . . 12 75 9.1.2. Format Format of DOTS Address Option . . . . . . . . 13 76 9.1.3. DHCPv6 Client Behavior . . . . . . . . . . . . . . . 13 77 9.2. DHCPv4 DOTS Options . . . . . . . . . . . . . . . . . . . 14 78 9.2.1. Format of DOTS Reference Identifier Option . . . . . 14 79 9.2.2. Format Format of DOTS Address Option . . . . . . . . 15 80 9.2.3. DHCPv4 Client Behavior . . . . . . . . . . . . . . . 16 81 10. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 11.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 11.2. Service Resolution . . . . . . . . . . . . . . . . . . . 18 85 11.3. DNS Service Discovery . . . . . . . . . . . . . . . . . 18 86 11.4. Anycast . . . . . . . . . . . . . . . . . . . . . . . . 18 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 12.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . 19 89 12.2. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 19 90 12.3. Application Service & Application Protocol Tags . . . . 19 91 12.3.1. DOTS Application Service Tag Registration . . . . . 19 92 12.3.2. signal.udp Application Protocol Tag Registration . . 20 93 12.3.3. signal.tcp Application Protocol Tag Registration . . 20 94 12.3.4. data.tcp Application Protocol Tag Registration . . . 20 95 12.4. IPv4 Anycast . . . . . . . . . . . . . . . . . . . . . . 20 96 12.5. IPv6 Anycast . . . . . . . . . . . . . . . . . . . . . . 21 97 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 98 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 100 14.2. Informative References . . . . . . . . . . . . . . . . . 23 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 103 1. Introduction 105 In many deployments, it may not be possible for a network to 106 determine the cause for a distributed Denial-of-Service (DoS) attack 107 [RFC4732], but instead just realize that some resources seem to be 108 under attack. To fill that gap, the IETF is specifying an 109 architecture, called DDoS Open Threat Signaling (DOTS) 110 [I-D.ietf-dots-architecture], in which a DOTS client can inform a 111 DOTS server that the network is under a potential attack and that 112 appropriate mitigation actions are required. Indeed, because the 113 lack of a common method to coordinate a real-time response among 114 involved actors and network domains inhibits the effectiveness of 115 DDoS attack mitigation, DOTS protocol is meant to carry requests for 116 DDoS attack mitigation, thereby reducing the impact of an attack and 117 leading to more efficient defensive actions. 118 [I-D.ietf-dots-use-cases] identifies a set of scenarios for DOTS. 120 The basic high-level DOTS architecture is illustrated in Figure 1 121 ([I-D.ietf-dots-architecture]): 123 +-----------+ +-------------+ 124 | Mitigator | ~~~~~~~~~~ | DOTS Server | 125 +-----------+ +-------------+ 126 | 127 | 128 | 129 +---------------+ +-------------+ 130 | Attack Target | ~~~~~~ | DOTS Client | 131 +---------------+ +-------------+ 133 Figure 1: Basic DOTS Architecture 135 [I-D.ietf-dots-architecture] specifies that the DOTS client may be 136 provided with a list of DOTS servers; each associated with one or 137 more IP addresses. These addresses may or may not be of the same 138 address family. The DOTS client establishes one or more DOTS 139 sessions by connecting to the provided DOTS server addresses. The 140 logic for connecting to one or multiple IP addresses is out of scope 141 of this document. 143 This document specifies methods for DOTS clients to discover their 144 DOTS server(s). The rationale for specifying multiple discovery 145 mechanisms is discussed in Section 4. 147 Considerations for the selection of DOTS server(s) by multi-homed 148 DOTS clients is out of scope; the reader should refer to 149 [I-D.boucadair-dots-multihoming] for more details. 151 Likewise, happy eyeballs considerations for DOTS are out of scope. 152 The reader should refer to Section 4 of 153 [I-D.ietf-dots-signal-channel]. 155 2. Requirements Language 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in BCP 160 14 [RFC2119][RFC8174] when, and only when, they appear in all 161 capitals, as shown here. 163 3. Terminology 165 This document makes use of the following terms: 167 o DDoS: A distributed Denial-of-Service attack, in which traffic 168 originating from multiple sources are directed at a target on a 169 network. DDoS attacks are intended to cause a negative impact on 170 the availability of servers, services, applications, and/or other 171 functionality of an attack target. 172 o DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC3315]. 173 o DHCP client denotes a node that initiates requests to obtain 174 configuration parameters from one or more DHCP servers. 175 o DHCP server refers to a node that responds to requests from DHCP 176 clients. 177 o DOTS client: A DOTS-aware software module responsible for 178 requesting attack response coordination with other DOTS-aware 179 elements. 180 o DOTS server: A DOTS-aware software module handling and responding 181 to messages from DOTS clients. The DOTS server should enable 182 mitigation on behalf of the DOTS client, if requested, by 183 communicating the DOTS client's request to the mitigator and 184 returning selected mitigator feedback to the requesting DOTS 185 client. A DOTS server may also be a mitigator. 186 o DOTS gateway: A DOTS-aware software module that is logically 187 equivalent to a DOTS client back-to-back with a DOTS server. 189 Furthermore, the reader should be familiar with other terms defined 190 in [I-D.ietf-dots-architecture] and [RFC3958]. 192 4. Why Multiple Discovery Mechanisms? 194 It is tempting to specify one single discovery mechanism for DOTS. 195 Nevertheless, the analysis of the various use cases sketched in 196 [I-D.ietf-dots-use-cases] reveals that it is unlikely that one single 197 discovery method can be suitable for all the sample deployments 198 (Table 1). Concretely: 200 o Some of the use cases may allow DOTS clients to have direct 201 communications with upstream DOTS servers; that is no DOTS gateway 202 is involved. Leveraging on existing features that do not require 203 specific feature on the node embedding the DOTS client may ease 204 DOTS deployment. Typically, the use of Straightforward-Naming 205 Authority Pointer (S-NAPTR) lookups [RFC3958] allows the DOTS 206 server administrators provision the preferred DOTS signal channel 207 transport protocol between the DOTS client and the DOTS server and 208 allows the DOTS client to discover this preference. 210 o Resolving a DOTS server domain name offered by the upstream 211 transit provider provisioned to a DOTS client into IP address(es) 212 require the use of the appropriate DNS resolvers; otherwise, 213 resolving those names will fail. The use of protocols such as 214 DHCP does allow to associate provisioned DOTS server domain names 215 with a list of DNS servers to be used for name resolution. 217 o The upstream network provider is not the DDoS mitigation provider 218 for some of these use cases. The use of anycast is not 219 appropriate for this use case, in particular. It is safe to 220 assume that for such deployments, the DOTS server(s) domain name 221 is provided during the service subscription (i.e., manual/local 222 configuration). 224 o Multiple DOTS clients may be enabled within a network (e.g., 225 enterprise network). Automatic means to discover DOTS servers in 226 a deterministic manner are interesting from an operational 227 standpoint. 229 o Some of the use cases may involve a DOTS gateway that is 230 responsible for forking requests received from DOTS clients to 231 upstream DOTS servers or for selecting the appropriate DOTS 232 server. Particularly, the use of anycast may simplify the 233 operations within the enterprise network to discover a DOTS 234 gateway, if the enterprise network is single-homed. 236 o Many use cases discussed in [I-D.ietf-dots-use-cases] do involve a 237 CPE device. Multiple CPEs, connected to distinct network 238 providers may even be considered. It is intuitive to leverage on 239 existing mechanisms such as discovery using service resolution or 240 DHCP or anycast to provision the CPE acting as a DOTS client with 241 the DOTS server(s). 243 +------------------------+-------------------------+----------------+ 244 | Use Case | Requires a CPE | The Network | 245 | | | Provider is | 246 | | | also the DDoS | 247 | | | Mitigation | 248 | | | Provider | 249 +------------------------+-------------------------+----------------+ 250 | End-customer with | Yes (Intelligent DDoS | Yes | 251 | single or multiple | mitigation system | | 252 | upstream transit | (IDMS) acting as a DOTS | | 253 | provider(s) offering | client may be co- | | 254 | DDoS mitigation | located on the CPE) | | 255 | services | | | 256 +------------------------+-------------------------+----------------+ 257 | End-customer with an | Yes (DDOS Detector | No | 258 | overlay DDoS | acting as a DOTS client | | 259 | mitigation managed | may be co-located on | | 260 | security service | the CPE) | | 261 | provider (MSSP) | | | 262 +------------------------+-------------------------+----------------+ 263 | End-customer operating | Yes (CPE may act as a | Yes/No | 264 | an application or | DOTS gateway) | | 265 | service with an | | | 266 | integrated DOTS client | | | 267 +------------------------+-------------------------+----------------+ 268 | End-customer operating | Yes (CPE acts as a DOTS | Yes | 269 | a CPE network | client) | | 270 | infrastructure device | | | 271 | with an integrated | | | 272 | DOTS client | | | 273 +------------------------+-------------------------+----------------+ 274 | Suppression of | Yes (CPE acts as a DOTS | Yes | 275 | outbound DDoS traffic | server) | | 276 | originating from a | | | 277 | consumer broadband | | | 278 | access network | | | 279 +------------------------+-------------------------+----------------+ 280 | DDoS Orchestration | No | N/A | 281 +------------------------+-------------------------+----------------+ 283 Table 1: Summary of DOTS Use Cases 285 Consequently, this document describes the following mechanisms for 286 discovery: 288 o A resolution mechanism based on straightforward Naming Authority 289 Pointer (S-NAPTR) resource records in the Domain Name System 290 (DNS). 292 o DNS Service Discovery. 294 o Discovery using DHCP Options. 296 o A mechanism based on anycast address for DOTS usage. 298 5. Discovery Procedure 300 A key point in the deployment of DOTS is the ability of network 301 operators to be able to configure DOTS clients with the correct 302 server information consistently. To accomplish this, operators will 303 need a consistent set of ways in which DOTS clients can discover this 304 information, and a consistent priority among these options. If some 305 devices prefer manual configuration over DNS discovery, while others 306 prefer DNS discovery over manual configuration, the result will be a 307 process of "whack-a-mole", where the operator must find devices that 308 are using the wrong DOTS server, determine how to ensure the devices 309 are configured properly, and then reconfigure the device through the 310 preferred method. 312 All DOTS clients MUST support at least one of the four mechanisms 313 below to determine a DOTS server list. All DOTS clients SHOULD 314 implement all four, or as many as are practical for any specific 315 device, of these ways to discover DOTS servers, in order to 316 facilitate the deployment of DOTS in large scale environments: 318 1. Explicit configuration: 320 * Local/Manual configuration: A DOTS client, will learn the DOTS 321 server(s) by means of local or manual DOTS configuration 322 (i.e., DOTS servers configured at the system level). 323 Configuration discovered from a DOTS client application is 324 considered as local configuration. An implementation may give 325 the user an opportunity (e.g., by means of configuration file 326 options or menu items) to specify DOTS server(s) for each 327 address family. These MAY be specified either as IP addresses 328 or the DNS name of a DOTS server. When only DOTS server' IP 329 addresses are configured, a reference identifier must also be 330 configured for authentication purposes. 332 * Automatic configuration (e.g., DHCP, an automation system): 333 The DOTS client attempts to discover DOTS server(s) names and/ 334 or addresses from DHCP, as described in Section 9. 336 2. Service Resolution : The DOTS client attempts to discover DOTS 337 server name(s) using service resolution, as specified in 338 Section 7. 340 3. DNS SD: DNS Service Discovery. The DOTS client attempts to 341 discover DOTS server name(s) using DNS service discovery, as 342 specified in Section 8. 344 4. Anycast : Send DOTS request to establish a DOTS session with the 345 assigned DOTS server anycast address for each combination of 346 interface and address family. 348 Some of these mechanisms imply the use of DNS to resolve the IP 349 address of the DOTS server, while others imply the IP address of the 350 relevant DOTS server is obtained directly. Implementation options 351 may vary on a per device basis, as some devices may not have DNS 352 capabilities and/or proper configuration. 354 Clients will prefer information received from the discovery methods 355 in the order listed. 357 On hosts with more than one interface or address family (IPv4/v6), 358 the DOTS server discovery procedure has to be performed for each 359 combination of interface and address family. A client MAY choose to 360 perform the discovery procedure only for a desired interface/address 361 combination if the client does not wish to discover a DOTS server for 362 all combinations of interface and address family. 364 The above procedure MUST also be followed by a DOTS gateway. 366 6. Resolution 368 Once the DOTS client has retrieved client's DNS domain or discovered 369 the DOTS server name that needs to be resolved, an S-NAPTR lookup 370 with 'DOTS' application service and the desired protocol tag is made 371 to obtain information necessary to connect to the authoritative DOTS 372 server within the given domain. 374 This specification defines "DOTS" as an application service tag 375 (Section 12.3.1) and "signal.udp" (Section 12.3.2), "signal.tcp" 376 (Section 12.3.3), and "data.tcp" (Section 12.3.4) as application 377 protocol tags. 379 In the example below, for domain 'example.net', the resolution 380 algorithm will result in IP address(es), port, tag and protocol tuples as 381 follows: 383 example.net. 384 IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. 385 IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. 386 IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net. 388 signal.example.net. 389 IN NAPTR 100 10 S DOTS:signal.udp "" _dots._signal._udp.example.net. 390 IN NAPTR 200 10 S DOTS:signal.tcp "" _dots._signal._tcp.example.net. 392 data.example.net. 393 IN NAPTR 100 10 S DOTS:data.tcp "" _dots._data._tcp.example.net. 395 _dots._signal._udp.example.net. 396 IN SRV 0 0 5000 a.example.net. 398 _dots._signal._tcp.example.net. 399 IN SRV 0 0 5001 a.example.net. 401 _dots._data._tcp.example.net. 402 IN SRV 0 0 5002 a.example.net. 404 a.example.net. 405 IN AAAA 2001:db8::1 407 +-------+----------+-------------+------+--------+ 408 | Order | Protocol | IP address | Port | Tag | 409 +-------+----------+-------------+------+--------+ 410 | 1 | UDP | 2001:db8::1 | 5000 | Signal | 411 | 2 | TCP | 2001:db8::1 | 5001 | Signal | 412 | 3 | TCP | 2001:db8::1 | 5002 | Data | 413 +-------+----------+-------------+------+--------+ 415 If no DOTS-specific S-NAPTR records can be retrieved, the discovery 416 procedure fails for this domain name (and the corresponding interface 417 and IP protocol version). If more domain names are known, the 418 discovery procedure MAY perform the corresponding S-NAPTR lookups 419 immediately. However, before retrying a lookup that has failed, a 420 DOTS client MUST wait a time period that is appropriate for the 421 encountered error (e.g., NXDOMAIN, timeout, etc.). 423 7. Discovery using Service Resolution 425 This mechanism is performed in two steps: 427 1. A DNS domain name is retrieved for each combination of interface 428 and address family. 430 2. Retrieved DNS domain names are then used for S-NAPTR lookups. 431 Further DNS lookups may be necessary to determine DOTS server IP 432 address(es). 434 7.1. Retrieving Domain Name 436 A DOTS client has to determine the domain in which it is located. 437 The following section describes the means to obtain the domain name 438 from DHCP. Other means of retrieving domain names may be used, which 439 are outside the scope of this document, e.g., local configuration. 441 Implementations MAY allow the user to specify a default name that is 442 used, if no specific name has been configured. 444 7.1.1. DHCP 446 DHCP can be used to determine the domain name related to an 447 interface's point of network attachment. Network operators may 448 provide the domain name to be used for service discovery within an 449 access network using DHCP. Sections 3.2 and 3.3 of [RFC5986] define 450 DHCP IPv4 and IPv6 access network domain name options, 451 OPTION_V4_ACCESS_DOMAIN and OPTION_V6_ACCESS_DOMAIN respectively, to 452 identify a domain name that is suitable for service discovery within 453 the access network. 455 For IPv4, the discovery procedure MUST request the access network 456 domain name option in a Parameter Request List option, as described 457 in [RFC2131]. [RFC2132] defines the DHCP IPv4 domain name option; 458 while this option is less suitable, a client MAY request for it if 459 the access network domain name defined in [RFC5986] is not available. 461 For IPv6, the discovery procedure MUST request for the access network 462 domain name option in an Options Request Option (ORO) within an 463 Information-request message, as described in [RFC3315]. 465 If neither option can be retrieved the procedure fails for this 466 interface. If a result can be retrieved it will be used as an input 467 for S-NAPTR resolution discussed in Section 6. 469 8. DNS Service Discovery 471 DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS 472 (mDNS) [RFC6762] provide generic solutions for discovering services. 473 DNS-SD/mDNS define a set of naming rules for certain DNS record types 474 that they use for advertising and discovering services. 476 8.1. DNS-SD 478 Section 4.1 of [RFC6763] specifies that a service instance name in 479 DNS-SD has the following structure: 481 . . 483 The portion specifies the DNS sub-domain where the service 484 instance is registered. It may be "local.", indicating the mDNS 485 local domain, or it may be a conventional domain name such as 486 "example.com.". 488 The portion of the DOTS service instance name MUST be 489 "_dots._signal._udp" or "_dots._signal._tcp" or "_dots._data._tcp". 491 8.2. mDNS 493 A DOTS client can proactively discover DOTS servers being advertised 494 in the site by multicasting a PTR query to one or all of the 495 following: 497 o "_dots._signal._udp.local." 499 o "_dots._signal._tcp.local." 501 o "_dots._data._tcp.local." 503 A DOTS server can send out gratuitous multicast DNS answer packets 504 whenever it starts up, wakes from sleep, or detects a change in 505 network configuration. DOTS clients receive these gratuitous packets 506 and cache information contained in it. 508 9. DHCP Options for DOTS 510 As reported in Section 1.7.2 of [RFC6125]: 512 "few certification authorities issue server certificates based on 513 IP addresses, but preliminary evidence indicates that such 514 certificates are a very small percentage (less than 1%) of issued 515 certificates". 517 In order to allow for PKIX-based authentication between a DOTS client 518 and server while accommodating for the current best practices for 519 issuing certificates, this document allows for configuring names to 520 DOTS clients. These names can be used for two purposes: to retrieve 521 the list of IP addresses of a DOTS server or to be presented as a 522 reference identifier for authentication purposes. 524 Defining the option to include a list of IP addresses would avoid a 525 dependency on an underlying name resolution, but that design requires 526 to also supply a name for PKIX-based authentication purposes. 528 9.1. DHCPv6 DOTS Options 530 9.1.1. Format of DOTS Reference Identifier Option 532 The DHCPv6 DOTS option is used to configure a name of the DOTS 533 server. The format of this option is shown in Figure 2. 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | OPTION_V6_DOTS | Option-length | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | | 540 | dots-server-name (FQDN) | 541 | | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Figure 2: DHCPv6 DOTS Reference Identifier option 546 The fields of the option shown in Figure 2 are as follows: 548 o Option-code: OPTION_V6_DOTS_RI (TBA1, see Section 12.1) 549 o Option-length: Length of the dots-server-name field in octets. 550 o dots-server-name: A fully qualified domain name of the DOTS 551 server. This field is formatted as specified in Section 8 of 552 [RFC3315]. 554 An example of the dots-server-name encoding is shown in Figure 3. 555 This example conveys the FQDN "dots.example.com.". 557 +------+------+------+------+------+------+------+------+------+ 558 | 0x04 | d | o | t | s | 0x07 | e | x | a | 559 +------+------+------+------+------+------+------+------+------+ 560 | m | p | l | e | 0x03 | c | o | m | 0x00 | 561 +------+------+------+------+------+------+------+------+------+ 563 Figure 3: An example of the dots-server-name encoding 565 9.1.2. Format Format of DOTS Address Option 567 The DHCPv6 DOTS option can be used to configure a list of IPv6 568 addresses of a DOTS server. The format of this option is shown in 569 Figure 4. 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | OPTION_V6_DOTS | Option-length | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | | 576 | DOTS ipv6-address | 577 | | 578 | | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | | 581 | DOTS ipv6-address | 582 | | 583 | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | ... | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Figure 4: DHCPv6 DOTS Address option 590 The fields of the option shown in Figure 4 are as follows: 592 o Option-code: OPTION_V6_DOTS_ADDRESS (TBA2, see Section 12.1) 593 o Option-length: Length of the 'DOTS ipv6-address(es)' field in 594 octets. MUST be a multiple of 16. 595 o DOTS ipv6-address: Includes one or more IPv6 addresses [RFC4291] 596 of the DOTS server to be used by the DOTS client. 598 Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) 599 are allowed to be included in this option. 601 To return more than one DOTS servers to the requesting DHCPv6 client, 602 the DHCPv6 server returns multiple instances of OPTION_V6_DOTS. 604 9.1.3. DHCPv6 Client Behavior 606 DHCP clients MAY request options OPTION_V6_DOTS_RI and 607 OPTION_V6_DOTS_ADDRESS, as defined in [RFC3315], Sections 17.1.1, 608 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. As a convenience to the 609 reader, it is mentioned here that the DHCP client includes the 610 requested option codes in the Option Request Option. 612 If the DHCP client receives more than one instance of 613 OPTION_V6_DOTS_RI (resp. OPTION_V6_DOTS_ADDRESS) option, it MUST use 614 only the first instance of that option. 616 If the DHCP client receives both OPTION_V6_DOTS_RI and 617 OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 618 reference identifier for authentication purposes (e.g., PKIX 619 [RFC6125]), while the addresses included in OPTION_V6_DOTS_ADDRESS 620 are used to reach the DOTS server. In other words, the name conveyed 621 in OPTION_V6_DOTS_RI MUST NOT be passed to underlying resolution 622 library in the presence of OPTION_V6_DOTS_ADDRESS in a response. 624 If the DHCP client receives OPTION_V6_DOTS_RI only, but 625 OPTION_V6_DOTS_RI option contains more than one name, as 626 distinguished by the presence of multiple root labels, the DHCP 627 client MUST use only the first name. Once the name is validated 628 (Section 8 of [RFC3315]), the name is passed to a name resolution 629 library. Moreover, that name is also used as a reference identifier 630 for authentication purposes. 632 If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the 633 address(es) included in OPTION_V6_DOTS_ADDRESS is used to reach the 634 DOTS server. In addition, these addresses can be used as identifiers 635 for authentication. 637 9.2. DHCPv4 DOTS Options 639 9.2.1. Format of DOTS Reference Identifier Option 641 The DHCPv4 DOTS option is used to configure a name of the DOTS 642 server. The format of this option is illustrated in Figure 5. 644 Code Length DOTS server name 645 +-----+-----+-----+-----+-----+-----+-----+-- 646 | TBA | n | s1 | s2 | s3 | s4 | s5 | ... 647 +-----+-----+-----+-----+-----+-----+-----+-- 649 The values s1, s2, s3, etc. represent the domain name labels in the 650 domain name encoding. 652 Figure 5: DHCPv4 DOTS Reference Identifier option 654 The fields of the option shown in Figure 5 are as follows: 656 o Code: OPTION_V4_DOTS_RI (TBA3, see Section 12.2); 657 o Length: Includes the length of the "DOTS server name" field in 658 octets; the maximum length is 255 octets. 660 o DOTS server name: The domain name of the DOTS server. This field 661 is formatted as specified in Section 8 of [RFC3315]. 663 9.2.2. Format Format of DOTS Address Option 665 The DHCPv4 DOTS option can be used to configure a list of IPv4 666 addresses of a DOTS server. The format of this option is illustrated 667 in Figure 6. 669 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Code | Length | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | List-Length | List of | 674 +-+-+-+-+-+-+-+-+ DOTS | 675 / IPv4 Addresses / 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 677 | List-Length | List of | | 678 +-+-+-+-+-+-+-+-+ DOTS | | 679 / IPv4 Addresses / | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 681 . ... . optional 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 683 | List-Length | List of | | 684 +-+-+-+-+-+-+-+-+ DOTS | | 685 / IPv4 Addresses / | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 688 Figure 6: DHCPv4 DOTS Address option 690 The fields of the option shown in Figure 6 are as follows: 692 o Code: OPTION_V4_DOTS_ADDRESS (TBA4, see Section 12.2); 693 o Length: Length of all included data in octets. The minimum length 694 is 5. 695 o List-Length: Length of the "List of DOTS IPv4 Addresses" field in 696 octets; MUST be a multiple of 4. 697 o List of DOTS IPv4 Addresses: Contains one or more IPv4 addresses 698 of the DOTS server to be used by the DOTS client. The format of 699 this field is shown in Figure 7. 700 o OPTION_V4_DOTS can include multiple lists of DOTS IPv4 addresses; 701 each list is treated separately as it corresponds to a given DOTS 702 server. 704 When several lists of DOTS IPv4 addresses are to be included, 705 "List-Length" and "DOTS IPv4 Addresses" fields are repeated. 707 0 8 16 24 32 40 48 708 +-----+-----+-----+-----+-----+-----+-- 709 | a1 | a2 | a3 | a4 | a1 | a2 | ... 710 +-----+-----+-----+-----+-----+-----+-- 711 IPv4 Address 1 IPv4 Address 2 ... 713 This format assumes that an IPv4 address is encoded as a1.a2.a3.a4. 715 Figure 7: Format of the List of DOTS IPv4 Addresses 717 OPTION_V4_DOTS is a concatenation-requiring option. As such, the 718 mechanism specified in [RFC3396] MUST be used if OPTION_V4_DOTS 719 exceeds the maximum DHCPv4 option size of 255 octets. 721 9.2.3. DHCPv4 Client Behavior 723 To discover a DOTS server, the DHCPv4 client MUST include both 724 OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request 725 List Option [RFC2132]. 727 If the DHCP client receives more than one instance of 728 OPTION_V4_DOTS_RI (resp. OPTION_V4_DOTS_ADDRESS) option, it MUST use 729 only the first instance of that option. 731 If the DHCP client receives both OPTION_V4_DOTS_RI and 732 OPTION_V4_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 733 reference identifier for authentication purposes, while the addresses 734 included in OPTION_V4_DOTS_ADDRESS are used to reach the DOTS server. 735 In other words, the name conveyed in OPTION_V4_DOTS_RI MUST NOT be 736 passed to underlying resolution library in the presence of 737 OPTION_V4_DOTS_ADDRESS in a response. 739 If the DHCP client receives OPTION_V4_DOTS_RI only, but 740 OPTION_V4_DOTS_RI option contains more than one name, as 741 distinguished by the presence of multiple root labels, the DHCP 742 client MUST use only the first name. Once the name is validated 743 (Section 8 of [RFC3315]), the name is passed to a name resolution 744 library. Moreover, that name is also used as a reference identifier 745 for authentication purposes. 747 If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the 748 address(es) included in OPTION_V4_DOTS_ADDRESS is used to reach the 749 DOTS server. In addition, these addresses can be used as identifiers 750 for authentication. 752 10. Anycast 754 IP anycast can also be used for DOTS service discovery. A packet 755 sent to an anycast address is delivered to the 'topologically 756 nearest' network interface with the anycast address. 758 When a DOTS client requires DOTS services, it attempts to establish a 759 signaling session with the assigned anycast address(es) defined in 760 Sections 12.4 and 12.5. A DOTS server, that receives a DOTS request 761 with an anycast address, SHOULD redirect the DOTS client to the 762 appropriate DOTS unicast server(s) using the mechanism described in 763 Section 5.5 of [I-D.ietf-dots-signal-channel], unless it is 764 configured otherwise. Indeed, a DOTS server SHOULD be configurable 765 to maintain all DOTS communications using anycast. DOTS redirect is 766 not made mandatory because the use of anycast is not problematic for 767 some deployment scenarios such as an enterprise network deploying one 768 single DOTS gateway connected to one single network provider. 770 [I-D.boucadair-dots-multihoming] identifies a set of deployment 771 schemes in which the use of anycast is not recommended. 773 11. Security Considerations 775 DOTS-related security considerations are discussed in Section 4 of 776 [I-D.ietf-dots-architecture] is to be considered. DOTS agents must 777 authenticate each other using (D)TLS before a DOTS session is 778 considered valid. 780 If the DOTS client is explicitly configured with DOTS server(s) then 781 the DOTS client can also be explicitly configured with credentials to 782 authenticate the DOTS server. 784 The CPE device acting as a DOTS client MAY use Bootstrapping Remote 785 Secure Key Infrastructures (BRSKI) discussed in 786 [I-D.ietf-anima-bootstrapping-keyinfra] to automatically bootstrap 787 using the vendor installed X.509 certificate, in combination with a 788 domain registrar provided by the upstream transit provider and 789 vendor's authorizing service. The CPE device authenticates to the 790 upstream transit provider using the vendor installed X.509 791 certificate and the upstream transit provider validates the vendor 792 installed certificate on the CPE device using the Manufacturer 793 Authorized Signing Authority (MASA) service. If authentication is 794 successful then the CPE device can request and get a voucher from the 795 MASA service via the domain registrar. The voucher is signed by the 796 MASA service and includes the upstream transit provider's trust 797 anchor certificate. The CPE device validates the signed voucher 798 using the manufacturer installed trust anchor associated with the 799 vendor's selected MASA service and stores the upstream transit 800 provider's trust anchor certificate. The CPE device then uses 801 Enrollment over Secure Transport (EST) [RFC7030] for certificate 802 enrollment (Section 3.8 in [I-D.ietf-anima-bootstrapping-keyinfra]). 803 The DOTS client on the CPE device can authenticate to the DOTS server 804 using the certificate provisioned by the EST server and the DOTS 805 client can validate the DOTS server certificate using the upstream 806 transit provider's trust anchor certificate it had received in the 807 voucher. 809 11.1. DHCP 811 The security considerations in [RFC2131] and [RFC3315] are to be 812 considered. 814 11.2. Service Resolution 816 The primary attack against the methods described in Section 7 is one 817 that would lead to impersonation of a DOTS server. An attacker could 818 attempt to compromise the S-NAPTR resolution. The use of mutual 819 authentication makes it difficult to redirect a DOTS client to an 820 illegitimate DOTS server. 822 11.3. DNS Service Discovery 824 Since DNS-SD is just a specification for how to name and use records 825 in the existing DNS system, it has no specific additional security 826 requirements over and above those that already apply to DNS queries 827 and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC) 828 [RFC4033] SHOULD be used where the authenticity of information is 829 important. For DNS updates, secure updates [RFC2136][RFC3007] SHOULD 830 generally be used to control which clients have permission to update 831 DNS records. 833 For mDNS, in addition to what has been described above, a principal 834 security threat is a security threat inherent to IP multicast routing 835 and any application that runs on it. A rogue system can advertise 836 that it is a DOTS server. Discovery of such rogue systems as DOTS 837 servers, in itself, is not a security threat if the DOTS client 838 authenticates the discovered DOTS servers. 840 11.4. Anycast 842 Anycast-related security considerations are discussed in [RFC4786] 843 and [RFC7094]. 845 12. IANA Considerations 847 IANA is requested to allocate the SRV service name of "_dots._signal" 848 for DOTS signal channel over UDP or TCP, and the service name of 849 "_dots._data" for DOTS data channel over TCP. 851 12.1. DHCPv6 Option 853 IANA is requested to assign the following new DHCPv6 Option Code in 854 the registry maintained in http://www.iana.org/assignments/ 855 dhcpv6-parameters: 857 Option Name Value 858 ---------------------- ----- 859 OPTION_V6_DOTS_RI TBA1 860 OPTION_V6_DOTS_ADDRESS TBA2 862 12.2. DHCPv4 Option 864 IANA is requested to assign the following new DHCPv4 Option Code in 865 the registry maintained in http://www.iana.org/assignments/bootp- 866 dhcp-parameters/: 868 Option Name Value Data length Meaning 869 ---------------------- ----- ------------ --------------------------- 870 OPTION_V4_DOTS_RI TBA3 Variable; Includes the name of the 871 the maximum DOTS server. 872 length is 873 255 octets. 874 OPTION_V4_DOTS_ADDRESS TBA4 Variable; Includes one or multiple 875 the minimum lists of DOTS IP addresses; 876 length is 5. each list is treated as a 877 separate DOTS server. 879 12.3. Application Service & Application Protocol Tags 881 This document requests IANA to make the following allocations from 882 the registry available at: https://www.iana.org/assignments/s-naptr- 883 parameters/s-naptr-parameters.xhtml. 885 12.3.1. DOTS Application Service Tag Registration 887 o Application Protocol Tag: DOTS 889 o Intended Usage: See Section 6 891 o Security Considerations: See Section 11 892 o Contact Information: 894 12.3.2. signal.udp Application Protocol Tag Registration 896 o Application Protocol Tag: signal.udp 898 o Intended Usage: See Section 6 900 o Security Considerations: See Section 11 902 o Contact Information: 904 12.3.3. signal.tcp Application Protocol Tag Registration 906 o Application Protocol Tag: signal.tcp 908 o Intended Usage: See Section 6 910 o Security Considerations: See Section 11 912 o Contact Information: 914 12.3.4. data.tcp Application Protocol Tag Registration 916 o Application Protocol Tag: data.tcp 918 o Intended Usage: See Section 6 920 o Security Considerations: See Section 11 922 o Contact Information: 924 12.4. IPv4 Anycast 926 IANA has assigned a single IPv4 address from the 192.0.0.0/24 prefix 927 and registered it in the "IANA IPv4 Special-Purpose Address Registry" 928 [RFC6890]. 930 +----------------------+-------------------------------------------+ 931 | Attribute | Value | 932 +----------------------+-------------------------------------------+ 933 | Address Block | TBA | 934 | Name | Distributed-Denial-of-Service Open Threat | 935 | | Signaling (DOTS) Anycast | 936 | RFC | | 937 | Allocation Date | | 938 | Termination Date | N/A | 939 | Source | True | 940 | Destination | True | 941 | Forwardable | True | 942 | Global | True | 943 | Reserved-by-Protocol | False | 944 +----------------------+-------------------------------------------+ 946 12.5. IPv6 Anycast 948 IANA has assigned a single IPv6 address from the 2001:0000::/23 949 prefix and registered it in the "IANA IPv6 Special-Purpose Address 950 Registry" [RFC6890]. 952 +----------------------+-------------------------------------------+ 953 | Attribute | Value | 954 +----------------------+-------------------------------------------+ 955 | Address Block | TBA | 956 | Name | Distributed-Denial-of-Service Open Threat | 957 | | Signaling (DOTS) Anycast | 958 | RFC | | 959 | Allocation Date | | 960 | Termination Date | N/A | 961 | Source | True | 962 | Destination | True | 963 | Forwardable | True | 964 | Global | True | 965 | Reserved-by-Protocol | False | 966 +----------------------+-------------------------------------------+ 968 13. Acknowledgements 970 Thanks to Brian Carpenter for the review of the BRSKI text. 972 Many thanks to Russ White for the review, comments, and text 973 contribution. 975 14. References 977 14.1. Normative References 979 [I-D.ietf-dots-architecture] 980 Mortensen, A., Andreasen, F., K, R., 981 christopher_gray3@cable.comcast.com, c., Compton, R., and 982 N. Teague, "Distributed-Denial-of-Service Open Threat 983 Signaling (DOTS) Architecture", draft-ietf-dots- 984 architecture-07 (work in progress), September 2018. 986 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 987 Requirement Levels", BCP 14, RFC 2119, 988 DOI 10.17487/RFC2119, March 1997, 989 . 991 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 992 RFC 2131, DOI 10.17487/RFC2131, March 1997, 993 . 995 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 996 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 997 . 999 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1000 C., and M. Carney, "Dynamic Host Configuration Protocol 1001 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1002 2003, . 1004 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 1005 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 1006 DOI 10.17487/RFC3396, November 2002, 1007 . 1009 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 1010 Service Location Using SRV RRs and the Dynamic Delegation 1011 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 1012 January 2005, . 1014 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1015 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1016 2006, . 1018 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 1019 Location Information Server (LIS)", RFC 5986, 1020 DOI 10.17487/RFC5986, September 2010, 1021 . 1023 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1024 DOI 10.17487/RFC6762, February 2013, 1025 . 1027 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1028 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1029 . 1031 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1032 "Special-Purpose IP Address Registries", BCP 153, 1033 RFC 6890, DOI 10.17487/RFC6890, April 2013, 1034 . 1036 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1037 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1038 May 2017, . 1040 14.2. Informative References 1042 [I-D.boucadair-dots-multihoming] 1043 Boucadair, M. and R. K, "Multi-homing Deployment 1044 Considerations for Distributed-Denial-of-Service Open 1045 Threat Signaling (DOTS)", draft-boucadair-dots- 1046 multihoming-03 (work in progress), April 2018. 1048 [I-D.ietf-anima-bootstrapping-keyinfra] 1049 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1050 S., and K. Watsen, "Bootstrapping Remote Secure Key 1051 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1052 keyinfra-16 (work in progress), June 2018. 1054 [I-D.ietf-dots-signal-channel] 1055 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 1056 Teague, "Distributed Denial-of-Service Open Threat 1057 Signaling (DOTS) Signal Channel Specification", draft- 1058 ietf-dots-signal-channel-25 (work in progress), September 1059 2018. 1061 [I-D.ietf-dots-use-cases] 1062 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 1063 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 1064 Open Threat Signaling", draft-ietf-dots-use-cases-16 (work 1065 in progress), July 2018. 1067 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1068 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1069 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1070 . 1072 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1073 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 1074 . 1076 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1077 Rose, "DNS Security Introduction and Requirements", 1078 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1079 . 1081 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1082 Denial-of-Service Considerations", RFC 4732, 1083 DOI 10.17487/RFC4732, December 2006, 1084 . 1086 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1087 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1088 December 2006, . 1090 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1091 Verification of Domain-Based Application Service Identity 1092 within Internet Public Key Infrastructure Using X.509 1093 (PKIX) Certificates in the Context of Transport Layer 1094 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1095 2011, . 1097 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1098 "Enrollment over Secure Transport", RFC 7030, 1099 DOI 10.17487/RFC7030, October 2013, 1100 . 1102 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1103 "Architectural Considerations of IP Anycast", RFC 7094, 1104 DOI 10.17487/RFC7094, January 2014, 1105 . 1107 Authors' Addresses 1109 Mohamed Boucadair 1110 Orange 1111 Rennes 35000 1112 France 1114 Email: mohamed.boucadair@orange.com 1115 Tirumaleswar Reddy 1116 McAfee, Inc. 1117 Embassy Golf Link Business Park 1118 Bangalore, Karnataka 560071 1119 India 1121 Email: TirumaleswarReddy_Konda@McAfee.com 1123 Prashanth Patil 1124 Cisco Systems, Inc. 1126 Email: praspati@cisco.com