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