idnits 2.17.1 draft-boucadair-dots-server-discovery-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There 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 873 has weird spacing: '...minimum lists...' -- The document date (October 18, 2017) is 2380 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-04 ** 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-02 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-08 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-05 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-07 -- 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 21, 2018 McAfee 6 P. Patil 7 Cisco 8 October 18, 2017 10 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server 11 Discovery 12 draft-boucadair-dots-server-discovery-03 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 21, 2018. 43 Copyright Notice 45 Copyright (c) 2017 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", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 3. Terminology 163 This document makes use of the following terms: 165 o DDoS: A distributed Denial-of-Service attack, in which traffic 166 originating from multiple sources are directed at a target on a 167 network. DDoS attacks are intended to cause a negative impact on 168 the availability of servers, services, applications, and/or other 169 functionality of an attack target. 170 o DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC3315]. 171 o DHCP client denotes a node that initiates requests to obtain 172 configuration parameters from one or more DHCP servers. 173 o DHCP server refers to a node that responds to requests from DHCP 174 clients. 175 o DOTS client: A DOTS-aware software module responsible for 176 requesting attack response coordination with other DOTS-aware 177 elements. 178 o DOTS server: A DOTS-aware software module handling and responding 179 to messages from DOTS clients. The DOTS server should enable 180 mitigation on behalf of the DOTS client, if requested, by 181 communicating the DOTS client's request to the mitigator and 182 returning selected mitigator feedback to the requesting DOTS 183 client. A DOTS server may also be a mitigator. 184 o DOTS gateway: A DOTS-aware software module that is logically 185 equivalent to a DOTS client back-to-back with a DOTS server. 187 Furthermore, the reader should be familiar with other terms defined 188 in [I-D.ietf-dots-architecture] and [RFC3958]. 190 4. Why Multiple Discovery Mechanisms? 192 It is tempting to specify one single discovery mechanism for DOTS. 193 Nevertheless, the analysis of the various use cases sketched in 194 [I-D.ietf-dots-use-cases] reveals that it is unlikely that one single 195 discovery method can be suitable for all the sample deployments 196 (Table 1). Concretely: 198 o Some of the use cases may allow DOTS clients to have direct 199 communications with upstream DOTS servers; that is no DOTS gateway 200 is involved. Leveraging on existing features that do not require 201 specific feature on the node embedding the DOTS client may ease 202 DOTS deployment. Typically, the use of Straightforward-Naming 203 Authority Pointer (S-NAPTR) lookups [RFC3958] allows the DOTS 204 server administrators provision the preferred DOTS signal channel 205 transport protocol between the DOTS client and the DOTS server and 206 allows the DOTS client to discover this preference. 208 o Resolving a DOTS server domain name offered by the upstream 209 transit provider provisioned to a DOTS client into IP address(es) 210 require the use of the appropriate DNS resolvers; otherwise, 211 resolving those names will fail. The use of protocols such as 212 DHCP does allow to associate provisioned DOTS server domain names 213 with a list of DNS servers to be used for name resolution. 215 o The upstream network provider is not the DDoS mitigation provider 216 for some of these use cases. The use of anycast is not 217 appropriate for this use case, in particular. It is safe to 218 assume that for such deployments, the DOTS server(s) domain name 219 is provided during the service subscription (i.e., manual/local 220 configuration). 222 o Multiple DOTS clients may be enabled within a network (e.g., 223 enterprise network). Automatic means to discover DOTS servers in 224 a deterministic manner are interesting from an operational 225 standpoint. 227 o Some of the use cases may involve a DOTS gateway that is 228 responsible for forking requests received from DOTS clients to 229 upstream DOTS servers or for selecting the appropriate DOTS 230 server. Particularly, the use of anycast may simplify the 231 operations within the enterprise network to discover a DOTS 232 gateway, if the enterprise network is single-homed. 234 o Many use cases discussed in [I-D.ietf-dots-use-cases] do involve a 235 CPE device. Multiple CPEs, connected to distinct network 236 providers may even be considered. It is intuitive to leverage on 237 existing mechanisms such as discovery using service resolution or 238 DHCP or anycast to provision the CPE acting as a DOTS client with 239 the DOTS server(s). 241 +------------------------+-------------------------+----------------+ 242 | Use Case | Requires a CPE | The Network | 243 | | | Provider is | 244 | | | also the DDoS | 245 | | | Mitigation | 246 | | | Provider | 247 +------------------------+-------------------------+----------------+ 248 | End-customer with | Yes (Intelligent DDoS | Yes | 249 | single or multiple | mitigation system | | 250 | upstream transit | (IDMS) acting as a DOTS | | 251 | provider(s) offering | client may be co- | | 252 | DDoS mitigation | located on the CPE) | | 253 | services | | | 254 +------------------------+-------------------------+----------------+ 255 | End-customer with an | Yes (DDOS Detector | No | 256 | overlay DDoS | acting as a DOTS client | | 257 | mitigation managed | may be co-located on | | 258 | security service | the CPE) | | 259 | provider (MSSP) | | | 260 +------------------------+-------------------------+----------------+ 261 | End-customer operating | Yes (CPE may act as a | Yes/No | 262 | an application or | DOTS gateway) | | 263 | service with an | | | 264 | integrated DOTS client | | | 265 +------------------------+-------------------------+----------------+ 266 | End-customer operating | Yes (CPE acts as a DOTS | Yes | 267 | a CPE network | client) | | 268 | infrastructure device | | | 269 | with an integrated | | | 270 | DOTS client | | | 271 +------------------------+-------------------------+----------------+ 272 | Suppression of | Yes (CPE acts as a DOTS | Yes | 273 | outbound DDoS traffic | server) | | 274 | originating from a | | | 275 | consumer broadband | | | 276 | access network | | | 277 +------------------------+-------------------------+----------------+ 278 | DDoS Orchestration | No | N/A | 279 +------------------------+-------------------------+----------------+ 281 Table 1: Summary of DOTS Use Cases 283 Consequently, this document describes the following mechanisms for 284 discovery: 286 o A resolution mechanism based on straightforward Naming Authority 287 Pointer (S-NAPTR) resource records in the Domain Name System 288 (DNS). 290 o DNS Service Discovery. 292 o Discovery using DHCP Options. 294 o A mechanism based on anycast address for DOTS usage. 296 5. Discovery Procedure 298 A key point in the deployment of DOTS is the ability of network 299 operators to be able to configure DOTS clients with the correct 300 server information consistently. To accomplish this, operators will 301 need a consistent set of ways in which DOTS clients can discover this 302 information, and a consistent priority among these options. If some 303 devices prefer manual configuration over DNS discovery, while others 304 prefer DNS discovery over manual configuration, the result will be a 305 process of "whack-a-mole", where the operator must find devices that 306 are using the wrong DOTS server, determine how to ensure the devices 307 are configured properly, and then reconfigure the device through the 308 preferred method. 310 All DOTS clients MUST support at least one of the four mechanisms 311 below to determine a DOTS server list. All DOTS clients SHOULD 312 implement all four, or as many as are practical for any specific 313 device, of these ways to discover DOTS servers, in order to 314 facilitate the deployment of DOTS in large scale environments: 316 1. Explicit configuration: 318 * Local/Manual configuration: A DOTS client, will learn the DOTS 319 server(s) by means of local or manual DOTS configuration 320 (i.e., DOTS servers configured at the system level). 321 Configuration discovered from a DOTS client application is 322 considered as local configuration. An implementation may give 323 the user an opportunity (e.g., by means of configuration file 324 options or menu items) to specify DOTS server(s) for each 325 address family. These MAY be specified either as IP addresses 326 or the DNS name of a DOTS server. When only DOTS server' IP 327 addresses are configured, a reference identifier must also be 328 configured for authentication purposes. 330 * Automatic configuration (e.g., DHCP, an automation system): 331 The DOTS client attempts to discover DOTS server(s) names and/ 332 or addresses from DHCP, as described in Section 9. 334 2. Service Resolution : The DOTS client attempts to discover DOTS 335 server name(s) using service resolution, as specified in 336 Section 7. 338 3. DNS SD: DNS Service Discovery. The DOTS client attempts to 339 discover DOTS server name(s) using DNS service discovery, as 340 specified in Section 8. 342 4. Anycast : Send DOTS request to establish a DOTS session with the 343 assigned DOTS server anycast address for each combination of 344 interface and address family. 346 Some of these mechanisms imply the use of DNS to resolve the IP 347 address of the DOTS server, while others imply the IP address of the 348 relevant DOTS server is obtained directly. Implementation options 349 may vary on a per device basis, as some devices may not have DNS 350 capabilities and/or proper configuration. 352 Clients will prefer information received from the discovery methods 353 in the order listed. 355 On hosts with more than one interface or address family (IPv4/v6), 356 the DOTS server discovery procedure has to be performed for each 357 combination of interface and address family. A client MAY choose to 358 perform the discovery procedure only for a desired interface/address 359 combination if the client does not wish to discover a DOTS server for 360 all combinations of interface and address family. 362 The above procedure MUST also be followed by a DOTS gateway. 364 6. Resolution 366 Once the DOTS client has retrieved client's DNS domain or discovered 367 the DOTS server name that needs to be resolved, an S-NAPTR lookup 368 with 'DOTS' application service and the desired protocol tag is made 369 to obtain information necessary to connect to the authoritative DOTS 370 server within the given domain. 372 This specification defines "DOTS" as an application service tag 373 (Section 12.3.1) and "signal.udp" (Section 12.3.2), "signal.tcp" 374 (Section 12.3.3), and "data.tcp" (Section 12.3.4) as application 375 protocol tags. 377 In the example below, for domain 'example.net', the resolution 378 algorithm will result in IP address(es), port, tag and protocol tuples as 379 follows: 381 example.net. 382 IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. 383 IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. 384 IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net. 386 signal.example.net. 387 IN NAPTR 100 10 S DOTS:signal.udp "" _dots._signal._udp.example.net. 388 IN NAPTR 200 10 S DOTS:signal.tcp "" _dots._signal._tcp.example.net. 390 data.example.net. 391 IN NAPTR 100 10 S DOTS:data.tcp "" _dots._data._tcp.example.net. 393 _dots._signal._udp.example.net. 394 IN SRV 0 0 5000 a.example.net. 396 _dots._signal._tcp.example.net. 397 IN SRV 0 0 5001 a.example.net. 399 _dots._data._tcp.example.net. 400 IN SRV 0 0 5002 a.example.net. 402 a.example.net. 403 IN AAAA 2001:db8::1 405 +-------+----------+-------------+------+--------+ 406 | Order | Protocol | IP address | Port | Tag | 407 +-------+----------+-------------+------+--------+ 408 | 1 | UDP | 2001:db8::1 | 5000 | Signal | 409 | 2 | TCP | 2001:db8::1 | 5001 | Signal | 410 | 3 | TCP | 2001:db8::1 | 5002 | Data | 411 +-------+----------+-------------+------+--------+ 413 If no DOTS-specific S-NAPTR records can be retrieved, the discovery 414 procedure fails for this domain name (and the corresponding interface 415 and IP protocol version). If more domain names are known, the 416 discovery procedure MAY perform the corresponding S-NAPTR lookups 417 immediately. However, before retrying a lookup that has failed, a 418 DOTS client MUST wait a time period that is appropriate for the 419 encountered error (e.g., NXDOMAIN, timeout, etc.). 421 7. Discovery using Service Resolution 423 This mechanism is performed in two steps: 425 1. A DNS domain name is retrieved for each combination of interface 426 and address family. 428 2. Retrieved DNS domain names are then used for S-NAPTR lookups. 429 Further DNS lookups may be necessary to determine DOTS server IP 430 address(es). 432 7.1. Retrieving Domain Name 434 A DOTS client has to determine the domain in which it is located. 435 The following section describes the means to obtain the domain name 436 from DHCP. Other means of retrieving domain names may be used, which 437 are outside the scope of this document, e.g., local configuration. 439 Implementations MAY allow the user to specify a default name that is 440 used, if no specific name has been configured. 442 7.1.1. DHCP 444 DHCP can be used to determine the domain name related to an 445 interface's point of network attachment. Network operators may 446 provide the domain name to be used for service discovery within an 447 access network using DHCP. Sections 3.2 and 3.3 of [RFC5986] define 448 DHCP IPv4 and IPv6 access network domain name options, 449 OPTION_V4_ACCESS_DOMAIN and OPTION_V6_ACCESS_DOMAIN respectively, to 450 identify a domain name that is suitable for service discovery within 451 the access network. 453 For IPv4, the discovery procedure MUST request the access network 454 domain name option in a Parameter Request List option, as described 455 in [RFC2131]. [RFC2132] defines the DHCP IPv4 domain name option; 456 while this option is less suitable, a client MAY request for it if 457 the access network domain name defined in [RFC5986] is not available. 459 For IPv6, the discovery procedure MUST request for the access network 460 domain name option in an Options Request Option (ORO) within an 461 Information-request message, as described in [RFC3315]. 463 If neither option can be retrieved the procedure fails for this 464 interface. If a result can be retrieved it will be used as an input 465 for S-NAPTR resolution discussed in Section 6. 467 8. DNS Service Discovery 469 DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS 470 (mDNS) [RFC6762] provide generic solutions for discovering services. 471 DNS-SD/mDNS define a set of naming rules for certain DNS record types 472 that they use for advertising and discovering services. 474 8.1. DNS-SD 476 Section 4.1 of [RFC6763] specifies that a service instance name in 477 DNS-SD has the following structure: 479 . . 481 The portion specifies the DNS sub-domain where the service 482 instance is registered. It may be "local.", indicating the mDNS 483 local domain, or it may be a conventional domain name such as 484 "example.com.". 486 The portion of the DOTS service instance name MUST be 487 "_dots._signal._udp" or "_dots._signal._tcp" or "_dots._data._tcp". 489 8.2. mDNS 491 A DOTS client can proactively discover DOTS servers being advertised 492 in the site by multicasting a PTR query to one or all of the 493 following: 495 o "_dots._signal._udp.local." 497 o "_dots._signal._tcp.local." 499 o "_dots._data._tcp.local." 501 A DOTS server can send out gratuitous multicast DNS answer packets 502 whenever it starts up, wakes from sleep, or detects a change in 503 network configuration. DOTS clients receive these gratuitous packets 504 and cache information contained in it. 506 9. DHCP Options for DOTS 508 As reported in Section 1.7.2 of [RFC6125]: 510 "few certification authorities issue server certificates based on 511 IP addresses, but preliminary evidence indicates that such 512 certificates are a very small percentage (less than 1%) of issued 513 certificates". 515 In order to allow for PKIX-based authentication between a DOTS client 516 and server while accommodating for the current best practices for 517 issuing certificates, this document allows for configuring names to 518 DOTS clients. These names can be used for two purposes: to retrieve 519 the list of IP addresses of a DOTS server or to be presented as a 520 reference identifier for authentication purposes. 522 Defining the option to include a list of IP addresses would avoid a 523 dependency on an underlying name resolution, but that design requires 524 to also supply a name for PKIX-based authentication purposes. 526 9.1. DHCPv6 DOTS Options 528 9.1.1. Format of DOTS Reference Identifier Option 530 The DHCPv6 DOTS option is used to configure a name of the DOTS 531 server. The format of this option is shown in Figure 2. 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | OPTION_V6_DOTS | Option-length | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | | 538 | dots-server-name (FQDN) | 539 | | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Figure 2: DHCPv6 DOTS Reference Identifier option 544 The fields of the option shown in Figure 2 are as follows: 546 o Option-code: OPTION_V6_DOTS_RI (TBA1, see Section 12.1) 547 o Option-length: Length of the dots-server-name field in octets. 548 o dots-server-name: A fully qualified domain name of the DOTS 549 server. This field is formatted as specified in Section 8 of 550 [RFC3315]. 552 An example of the dots-server-name encoding is shown in Figure 3. 553 This example conveys the FQDN "dots.example.com.". 555 +------+------+------+------+------+------+------+------+------+ 556 | 0x04 | d | o | t | s | 0x07 | e | x | a | 557 +------+------+------+------+------+------+------+------+------+ 558 | m | p | l | e | 0x03 | c | o | m | 0x00 | 559 +------+------+------+------+------+------+------+------+------+ 561 Figure 3: An example of the dots-server-name encoding 563 9.1.2. Format Format of DOTS Address Option 565 The DHCPv6 DOTS option can be used to configure a list of IPv6 566 addresses of a DOTS server. The format of this option is shown in 567 Figure 4. 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | OPTION_V6_DOTS | Option-length | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | | 574 | DOTS ipv6-address | 575 | | 576 | | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | | 579 | DOTS ipv6-address | 580 | | 581 | | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | ... | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Figure 4: DHCPv6 DOTS Address option 588 The fields of the option shown in Figure 4 are as follows: 590 o Option-code: OPTION_V6_DOTS_ADDRESS (TBA2, see Section 12.1) 591 o Option-length: Length of the 'DOTS ipv6-address(es)' field in 592 octets. MUST be a multiple of 16. 593 o DOTS ipv6-address: Includes one or more IPv6 addresses [RFC4291] 594 of the DOTS server to be used by the DOTS client. 596 Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) 597 are allowed to be included in this option. 599 To return more than one DOTS servers to the requesting DHCPv6 client, 600 the DHCPv6 server returns multiple instances of OPTION_V6_DOTS. 602 9.1.3. DHCPv6 Client Behavior 604 DHCP clients MAY request options OPTION_V6_DOTS_RI and 605 OPTION_V6_DOTS_ADDRESS, as defined in [RFC3315], Sections 17.1.1, 606 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. As a convenience to the 607 reader, it is mentioned here that the DHCP client includes the 608 requested option codes in the Option Request Option. 610 If the DHCP client receives more than one instance of 611 OPTION_V6_DOTS_RI (resp. OPTION_V6_DOTS_ADDRESS) option, it MUST use 612 only the first instance of that option. 614 If the DHCP client receives both OPTION_V6_DOTS_RI and 615 OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 616 reference identifier for authentication purposes (e.g., PKIX 617 [RFC6125]), while the addresses included in OPTION_V6_DOTS_ADDRESS 618 are used to reach the DOTS server. In other words, the name conveyed 619 in OPTION_V6_DOTS_RI MUST NOT be passed to underlying resolution 620 library in the presence of OPTION_V6_DOTS_ADDRESS in a response. 622 If the DHCP client receives OPTION_V6_DOTS_RI only, but 623 OPTION_V6_DOTS_RI option contains more than one name, as 624 distinguished by the presence of multiple root labels, the DHCP 625 client MUST use only the first name. Once the name is validated 626 (Section 8 of [RFC3315]), the name is passed to a name resolution 627 library. Moreover, that name is also used as a reference identifier 628 for authentication purposes. 630 If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the 631 address(es) included in OPTION_V6_DOTS_ADDRESS is used to reach the 632 DOTS server. In addition, these addresses can be used as identifiers 633 for authentication. 635 9.2. DHCPv4 DOTS Options 637 9.2.1. Format of DOTS Reference Identifier Option 639 The DHCPv4 DOTS option is used to configure a name of the DOTS 640 server. The format of this option is illustrated in Figure 5. 642 Code Length DOTS server name 643 +-----+-----+-----+-----+-----+-----+-----+-- 644 | TBA | n | s1 | s2 | s3 | s4 | s5 | ... 645 +-----+-----+-----+-----+-----+-----+-----+-- 647 The values s1, s2, s3, etc. represent the domain name labels in the 648 domain name encoding. 650 Figure 5: DHCPv4 DOTS Reference Identifier option 652 The fields of the option shown in Figure 5 are as follows: 654 o Code: OPTION_V4_DOTS_RI (TBA3, see Section 12.2); 655 o Length: Includes the length of the "DOTS server name" field in 656 octets; the maximum length is 255 octets. 658 o DOTS server name: The domain name of the DOTS server. This field 659 is formatted as specified in Section 8 of [RFC3315]. 661 9.2.2. Format Format of DOTS Address Option 663 The DHCPv4 DOTS option can be used to configure a list of IPv4 664 addresses of a DOTS server. The format of this option is illustrated 665 in Figure 6. 667 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Code | Length | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | List-Length | List of | 672 +-+-+-+-+-+-+-+-+ DOTS | 673 / IPv4 Addresses / 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 675 | List-Length | List of | | 676 +-+-+-+-+-+-+-+-+ DOTS | | 677 / IPv4 Addresses / | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 679 . ... . optional 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 681 | List-Length | List of | | 682 +-+-+-+-+-+-+-+-+ DOTS | | 683 / IPv4 Addresses / | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 686 Figure 6: DHCPv4 DOTS Address option 688 The fields of the option shown in Figure 6 are as follows: 690 o Code: OPTION_V4_DOTS_ADDRESS (TBA4, see Section 12.2); 691 o Length: Length of all included data in octets. The minimum length 692 is 5. 693 o List-Length: Length of the "List of DOTS IPv4 Addresses" field in 694 octets; MUST be a multiple of 4. 695 o List of DOTS IPv4 Addresses: Contains one or more IPv4 addresses 696 of the DOTS server to be used by the DOTS client. The format of 697 this field is shown in Figure 7. 698 o OPTION_V4_DOTS can include multiple lists of DOTS IPv4 addresses; 699 each list is treated separately as it corresponds to a given DOTS 700 server. 702 When several lists of DOTS IPv4 addresses are to be included, 703 "List-Length" and "DOTS IPv4 Addresses" fields are repeated. 705 0 8 16 24 32 40 48 706 +-----+-----+-----+-----+-----+-----+-- 707 | a1 | a2 | a3 | a4 | a1 | a2 | ... 708 +-----+-----+-----+-----+-----+-----+-- 709 IPv4 Address 1 IPv4 Address 2 ... 711 This format assumes that an IPv4 address is encoded as a1.a2.a3.a4. 713 Figure 7: Format of the List of DOTS IPv4 Addresses 715 OPTION_V4_DOTS is a concatenation-requiring option. As such, the 716 mechanism specified in [RFC3396] MUST be used if OPTION_V4_DOTS 717 exceeds the maximum DHCPv4 option size of 255 octets. 719 9.2.3. DHCPv4 Client Behavior 721 To discover a DOTS server, the DHCPv4 client MUST include both 722 OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request 723 List Option [RFC2132]. 725 If the DHCP client receives more than one instance of 726 OPTION_V4_DOTS_RI (resp. OPTION_V4_DOTS_ADDRESS) option, it MUST use 727 only the first instance of that option. 729 If the DHCP client receives both OPTION_V4_DOTS_RI and 730 OPTION_V4_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as 731 reference identifier for authentication purposes, while the addresses 732 included in OPTION_V4_DOTS_ADDRESS are used to reach the DOTS server. 733 In other words, the name conveyed in OPTION_V4_DOTS_RI MUST NOT be 734 passed to underlying resolution library in the presence of 735 OPTION_V4_DOTS_ADDRESS in a response. 737 If the DHCP client receives OPTION_V4_DOTS_RI only, but 738 OPTION_V4_DOTS_RI option contains more than one name, as 739 distinguished by the presence of multiple root labels, the DHCP 740 client MUST use only the first name. Once the name is validated 741 (Section 8 of [RFC3315]), the name is passed to a name resolution 742 library. Moreover, that name is also used as a reference identifier 743 for authentication purposes. 745 If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the 746 address(es) included in OPTION_V4_DOTS_ADDRESS is used to reach the 747 DOTS server. In addition, these addresses can be used as identifiers 748 for authentication. 750 10. Anycast 752 IP anycast can also be used for DOTS service discovery. A packet 753 sent to an anycast address is delivered to the 'topologically 754 nearest' network interface with the anycast address. 756 When a DOTS client requires DOTS services, it attempts to establish a 757 signaling session with the assigned anycast address(es) defined in 758 Sections 12.4 and 12.5. A DOTS server, that receives a DOTS request 759 with an anycast address, SHOULD redirect the DOTS client to the 760 appropriate DOTS unicast server(s) using the mechanism described in 761 Section 5.5 of [I-D.ietf-dots-signal-channel], unless it is 762 configured otherwise. Indeed, a DOTS server SHOULD be configurable 763 to maintain all DOTS communications using anycast. DOTS redirect is 764 not made mandatory because the use of anycast is not problematic for 765 some deployment scenarios such as an enterprise network deploying one 766 single DOTS gateway connected to one single network provider. 768 [I-D.boucadair-dots-multihoming] identifies a set of deployment 769 schemes in which the use of anycast is not recommended. 771 11. Security Considerations 773 DOTS-related security considerations are discussed in Section 4 of 774 [I-D.ietf-dots-architecture] is to be considered. DOTS agents must 775 authenticate each other using (D)TLS before a DOTS session is 776 considered valid. 778 If the DOTS client is explicitly configured with DOTS server(s) then 779 the DOTS client can also be explicitly configured with credentials to 780 authenticate the DOTS server. 782 The CPE device acting as a DOTS client MAY use Bootstrapping Remote 783 Secure Key Infrastructures (BRSKI) discussed in 784 [I-D.ietf-anima-bootstrapping-keyinfra] to automatically bootstrap 785 using the vendor installed X.509 certificate, in combination with a 786 domain registrar provided by the upstream transit provider and 787 vendor's authorizing service. The CPE device authenticates to the 788 upstream transit provider using the vendor installed X.509 789 certificate and the upstream transit provider validates the vendor 790 installed certificate on the CPE device using the Manufacturer 791 Authorized Signing Authority (MASA) service. If authentication is 792 successful then the CPE device can request and get a voucher from the 793 MASA service via the domain registrar. The voucher is signed by the 794 MASA service and includes the upstream transit provider's trust 795 anchor certificate. The CPE device validates the signed voucher 796 using the manufacturer installed trust anchor associated with the 797 vendor's selected MASA service and stores the upstream transit 798 provider's trust anchor certificate. The CPE device then uses 799 Enrollment over Secure Transport (EST) [RFC7030] for certificate 800 enrollment (Section 3.8 in [I-D.ietf-anima-bootstrapping-keyinfra]). 801 The DOTS client on the CPE device can authenticate to the DOTS server 802 using the certificate provisioned by the EST server and the DOTS 803 client can validate the DOTS server certificate using the upstream 804 transit provider's trust anchor certificate it had received in the 805 voucher. 807 11.1. DHCP 809 The security considerations in [RFC2131] and [RFC3315] are to be 810 considered. 812 11.2. Service Resolution 814 The primary attack against the methods described in Section 7 is one 815 that would lead to impersonation of a DOTS server. An attacker could 816 attempt to compromise the S-NAPTR resolution. The use of mutual 817 authentication makes it difficult to redirect a DOTS client to an 818 illegitimate DOTS server. 820 11.3. DNS Service Discovery 822 Since DNS-SD is just a specification for how to name and use records 823 in the existing DNS system, it has no specific additional security 824 requirements over and above those that already apply to DNS queries 825 and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC) 826 [RFC4033] SHOULD be used where the authenticity of information is 827 important. For DNS updates, secure updates [RFC2136][RFC3007] SHOULD 828 generally be used to control which clients have permission to update 829 DNS records. 831 For mDNS, in addition to what has been described above, a principal 832 security threat is a security threat inherent to IP multicast routing 833 and any application that runs on it. A rogue system can advertise 834 that it is a DOTS server. Discovery of such rogue systems as DOTS 835 servers, in itself, is not a security threat if the DOTS client 836 authenticates the discovered DOTS servers. 838 11.4. Anycast 840 Anycast-related security considerations are discussed in [RFC4786] 841 and [RFC7094]. 843 12. IANA Considerations 845 IANA is requested to allocate the SRV service name of "_dots._signal" 846 for DOTS signal channel over UDP or TCP, and the service name of 847 "_dots._data" for DOTS data channel over TCP. 849 12.1. DHCPv6 Option 851 IANA is requested to assign the following new DHCPv6 Option Code in 852 the registry maintained in http://www.iana.org/assignments/ 853 dhcpv6-parameters: 855 Option Name Value 856 ---------------------- ----- 857 OPTION_V6_DOTS_RI TBA1 858 OPTION_V6_DOTS_ADDRESS TBA2 860 12.2. DHCPv4 Option 862 IANA is requested to assign the following new DHCPv4 Option Code in 863 the registry maintained in http://www.iana.org/assignments/bootp- 864 dhcp-parameters/: 866 Option Name Value Data length Meaning 867 ---------------------- ----- ------------ --------------------------- 868 OPTION_V4_DOTS_RI TBA3 Variable; Includes the name of the 869 the maximum DOTS server. 870 length is 871 255 octets. 872 OPTION_V4_DOTS_ADDRESS TBA4 Variable; Includes one or multiple 873 the minimum lists of DOTS IP addresses; 874 length is 5. each list is treated as a 875 separate DOTS server. 877 12.3. Application Service & Application Protocol Tags 879 This document requests IANA to make the following allocations from 880 the registry available at: https://www.iana.org/assignments/s-naptr- 881 parameters/s-naptr-parameters.xhtml. 883 12.3.1. DOTS Application Service Tag Registration 885 o Application Protocol Tag: DOTS 887 o Intended Usage: See Section 6 889 o Security Considerations: See Section 11 890 o Contact Information: 892 12.3.2. signal.udp Application Protocol Tag Registration 894 o Application Protocol Tag: signal.udp 896 o Intended Usage: See Section 6 898 o Security Considerations: See Section 11 900 o Contact Information: 902 12.3.3. signal.tcp Application Protocol Tag Registration 904 o Application Protocol Tag: signal.tcp 906 o Intended Usage: See Section 6 908 o Security Considerations: See Section 11 910 o Contact Information: 912 12.3.4. data.tcp Application Protocol Tag Registration 914 o Application Protocol Tag: data.tcp 916 o Intended Usage: See Section 6 918 o Security Considerations: See Section 11 920 o Contact Information: 922 12.4. IPv4 Anycast 924 IANA has assigned a single IPv4 address from the 192.0.0.0/24 prefix 925 and registered it in the "IANA IPv4 Special-Purpose Address Registry" 926 [RFC6890]. 928 +----------------------+-------------------------------------------+ 929 | Attribute | Value | 930 +----------------------+-------------------------------------------+ 931 | Address Block | TBA | 932 | Name | Distributed-Denial-of-Service Open Threat | 933 | | Signaling (DOTS) Anycast | 934 | RFC | | 935 | Allocation Date | | 936 | Termination Date | N/A | 937 | Source | True | 938 | Destination | True | 939 | Forwardable | True | 940 | Global | True | 941 | Reserved-by-Protocol | False | 942 +----------------------+-------------------------------------------+ 944 12.5. IPv6 Anycast 946 IANA has assigned a single IPv6 address from the 2001:0000::/23 947 prefix and registered it in the "IANA IPv6 Special-Purpose Address 948 Registry" [RFC6890]. 950 +----------------------+-------------------------------------------+ 951 | Attribute | Value | 952 +----------------------+-------------------------------------------+ 953 | Address Block | TBA | 954 | Name | Distributed-Denial-of-Service Open Threat | 955 | | Signaling (DOTS) Anycast | 956 | RFC | | 957 | Allocation Date | | 958 | Termination Date | N/A | 959 | Source | True | 960 | Destination | True | 961 | Forwardable | True | 962 | Global | True | 963 | Reserved-by-Protocol | False | 964 +----------------------+-------------------------------------------+ 966 13. Acknowledgements 968 Thanks to Brian Carpenter for the review of the BRSKI text. 970 Many thanks to Russ White for the review, comments, and text 971 contribution. 973 14. References 975 14.1. Normative References 977 [I-D.ietf-dots-architecture] 978 Mortensen, A., Andreasen, F., Reddy, T., 979 christopher_gray3@cable.comcast.com, c., Compton, R., and 980 N. Teague, "Distributed-Denial-of-Service Open Threat 981 Signaling (DOTS) Architecture", draft-ietf-dots- 982 architecture-04 (work in progress), July 2017. 984 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 985 Requirement Levels", BCP 14, RFC 2119, 986 DOI 10.17487/RFC2119, March 1997, 987 . 989 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 990 RFC 2131, DOI 10.17487/RFC2131, March 1997, 991 . 993 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 994 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 995 . 997 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 998 C., and M. Carney, "Dynamic Host Configuration Protocol 999 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1000 2003, . 1002 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 1003 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 1004 DOI 10.17487/RFC3396, November 2002, 1005 . 1007 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 1008 Service Location Using SRV RRs and the Dynamic Delegation 1009 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 1010 January 2005, . 1012 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1013 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1014 2006, . 1016 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 1017 Location Information Server (LIS)", RFC 5986, 1018 DOI 10.17487/RFC5986, September 2010, 1019 . 1021 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1022 DOI 10.17487/RFC6762, February 2013, 1023 . 1025 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1026 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1027 . 1029 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1030 "Special-Purpose IP Address Registries", BCP 153, 1031 RFC 6890, DOI 10.17487/RFC6890, April 2013, 1032 . 1034 14.2. Informative References 1036 [I-D.boucadair-dots-multihoming] 1037 Boucadair, M. and T. Reddy, "Multi-homing Deployment 1038 Considerations for Distributed-Denial-of-Service Open 1039 Threat Signaling (DOTS)", draft-boucadair-dots- 1040 multihoming-02 (work in progress), October 2017. 1042 [I-D.ietf-anima-bootstrapping-keyinfra] 1043 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1044 S., and K. Watsen, "Bootstrapping Remote Secure Key 1045 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1046 keyinfra-08 (work in progress), October 2017. 1048 [I-D.ietf-dots-signal-channel] 1049 Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. 1050 Teague, "Distributed Denial-of-Service Open Threat 1051 Signaling (DOTS) Signal Channel", draft-ietf-dots-signal- 1052 channel-05 (work in progress), October 2017. 1054 [I-D.ietf-dots-use-cases] 1055 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 1056 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 1057 Open Threat Signaling", draft-ietf-dots-use-cases-07 (work 1058 in progress), July 2017. 1060 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1061 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1062 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1063 . 1065 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1066 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 1067 . 1069 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1070 Rose, "DNS Security Introduction and Requirements", 1071 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1072 . 1074 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1075 Denial-of-Service Considerations", RFC 4732, 1076 DOI 10.17487/RFC4732, December 2006, 1077 . 1079 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1080 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1081 December 2006, . 1083 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1084 Verification of Domain-Based Application Service Identity 1085 within Internet Public Key Infrastructure Using X.509 1086 (PKIX) Certificates in the Context of Transport Layer 1087 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1088 2011, . 1090 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1091 "Enrollment over Secure Transport", RFC 7030, 1092 DOI 10.17487/RFC7030, October 2013, 1093 . 1095 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1096 "Architectural Considerations of IP Anycast", RFC 7094, 1097 DOI 10.17487/RFC7094, January 2014, 1098 . 1100 Authors' Addresses 1102 Mohamed Boucadair 1103 Orange 1104 Rennes 35000 1105 France 1107 Email: mohamed.boucadair@orange.com 1109 Tirumaleswar Reddy 1110 McAfee, Inc. 1111 Embassy Golf Link Business Park 1112 Bangalore, Karnataka 560071 1113 India 1115 Email: TirumaleswarReddy_Konda@McAfee.com 1116 Prashanth Patil 1117 Cisco Systems, Inc. 1119 Email: praspati@cisco.com