idnits 2.17.1 draft-reddy-dots-telemetry-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2019) is 1757 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Enterprise-Numbers' == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-30 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-35 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-17 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track M. Boucadair 5 Expires: January 6, 2020 Orange 6 E. Doron 7 Radware Ltd. 8 July 5, 2019 10 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry 11 draft-reddy-dots-telemetry-00 13 Abstract 15 This document aims to enrich DOTS signal channel protocol with 16 various telemetry attributes allowing optimal DDoS attack mitigation. 17 This document specifies the normal traffic baseline and attack 18 traffic telemetry attributes a DOTS client can convey to its DOTS 19 server in the mitigation request, the mitigation status telemetry 20 attributes a DOTS server can communicate to a DOTS client, and the 21 mitigation efficacy telemetry attributes a DOTS client can 22 communicate to a DOTS server. The telemetry attributes can assist 23 the mitigator to choose the DDoS mitigation techniques and perform 24 optimal DDoS attack mitigation. 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 January 6, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. DOTS Telemetry: Overview & Purpose . . . . . . . . . . . . . 5 63 4. DOTS Telemetry Attributes . . . . . . . . . . . . . . . . . . 8 64 4.1. Pre-mitigation DOTS Telemetry Attributes . . . . . . . . 8 65 4.1.1. Total Traffic Normal Baseline . . . . . . . . . . . . 8 66 4.1.2. Total Pipe Capability . . . . . . . . . . . . . . . . 9 67 4.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 9 68 4.1.4. Total Traffic . . . . . . . . . . . . . . . . . . . . 9 69 4.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 9 70 4.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry 71 Attributes . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.2.1. Total Attack Traffic . . . . . . . . . . . . . . . . 10 73 4.2.2. Attack Details . . . . . . . . . . . . . . . . . . . 10 74 4.3. DOTS Server to Client Mitigation Status DOTS Telemetry 75 Attributes . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.3.1. Mitigation Status . . . . . . . . . . . . . . . . . . 10 77 5. DOTS Telemetry YANG Module . . . . . . . . . . . . . . . . . 10 78 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 10 79 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 6.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 11 82 6.2. DOTS Signal Telemetry YANG Module . . . . . . . . . . . . 11 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 9.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 The Internet security 'battle' between the adversary and security 93 countermeasures is an everlasting one. DDoS attacks have become more 94 vicious and sophisticated in almost all aspects of their maneuvers 95 and malevolent intentions. IT organizations and service providers 96 are facing DDoS attacks that fall into two broad categories: Network/ 97 Transport layer attacks and Application layer attacks. Network/ 98 Transport layer attacks target the victim's infrastructure. These 99 attacks are not necessarily aimed at taking down the actual delivered 100 services, but rather to eliminate various network elements (routers, 101 switches, firewalls, transit links, and so on) from serving 102 legitimate user traffic. The main method of such attacks is to send 103 a large volume or high PPS of traffic toward the victim's 104 infrastructure. Typically, attack volumes may vary from a few 100 105 Mbps/PPS to 100s of Gbps or even Tbps. Attacks are commonly carried 106 out leveraging botnets and attack reflectors for amplification 107 attacks, such as NTP, DNS, SNMP, SSDP, and so on. Application layer 108 attacks target various applications. Typical examples include 109 attacks against HTTP/HTTPS, DNS, SIP, SMTP, and so on. However, all 110 valid applications with their port numbers open at network edges can 111 be attractive attack targets. Application layer attacks are 112 considered more complex and hard to categorize, therefore harder to 113 detect and mitigate efficiently. 115 To compound the problem, attackers also leverage multi-vectored 116 attacks. These merciless attacks are assembled from dynamic attack 117 vectors (Network/Application) and tactics. As such, multiple attack 118 vectors formed by multiple attack types and volumes are launched 119 simultaneously towards a victim. Multi-vector attacks are harder to 120 detect and defend. Multiple and simultaneous mitigation techniques 121 are needed to defeat such attack campaigns. It is also common for 122 attackers to change attack vectors right after a successful 123 mitigation, burdening their opponents with changing their defense 124 methods. 126 The ultimate conclusion derived from these real scenarios is that 127 modern attacks detection and mitigation are most certainly 128 complicated and highly convoluted tasks. They demand a comprehensive 129 knowledge of the attack attributes, the targeted normal behavior/ 130 traffic patterns, as well as the attacker's on-going and past 131 actions. Even more challenging, retrieving all the analytics needed 132 for detecting these attacks is not simple to obtain with the 133 industry's current capabilities. 135 The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is 136 used to carry information about a network resource or a network (or a 137 part thereof) that is under a Distributed Denial of Service (DDoS) 138 attack. Such information is sent by a DOTS client to one or multiple 139 DOTS servers so that appropriate mitigation actions are undertaken on 140 traffic deemed suspicious. Various use cases are discussed in 141 [I-D.ietf-dots-use-cases]. 143 Typically, DOTS clients can be integrated within a DDoS attack 144 detector, or network and security elements that have been actively 145 engaged with ongoing attacks. The DOTS client mitigation environment 146 determines that it is no longer possible or practical for it to 147 handle these attacks. This can be due to lack of resources or 148 security capabilities, as derived from the complexities and the 149 intensity of these attacks. In this circumstance, the DOTS client 150 has invaluable knowledge about the actual attacks that need to be 151 handled by the DOTS server. By enabling the DOTS client to share 152 this comprehensive knowledge of an ongoing attack under specific 153 circumstances, the DOTS server can drastically increase its abilities 154 to accomplish successful mitigation. While the attack is being 155 handled by the DOTS server associated mitigation resources, the DOTS 156 server has the knowledge about the ongoing attack mitigation. The 157 DOTS server can share this information with the DOTS client so that 158 the client can better assess and evaluate the actual mitigation 159 realized. 161 In some deployments, DOTS clients can send mitigation hints derived 162 from attack details to DOTS servers, with the full understanding that 163 the DOTS server may ignore mitigation hints, as described in 164 [RFC8612] (Gen-004). Mitigation hints will be transmitted across the 165 DOTS signal channel, as the data channel may not be functional during 166 an attack. How a DOTS server is handling normal and attack traffic 167 attributes, and mitigation hints is implementation-specific. 169 Both DOTS client and server can benefit this information by 170 presenting various information in relevant management, reporting, and 171 portal systems. 173 This document defines DOTS telemetry attributes the DOTS client can 174 convey to the DOTS server, and vice versa. The DOTS telemetry 175 attributes are not mandatory fields. Nevertheless, when DOTS 176 telemetry attributes are available to a DOTS agent, and absent any 177 policy, it can signal the attributes in order to optimize the overall 178 mitigation service provisioned using DOTS. Some of the DOTS 179 telemetry data are not shared during an attack time. 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 185 "OPTIONAL" in this document are to be interpreted as described in BCP 186 14 [RFC2119][RFC8174] when, and only when, they appear in all 187 capitals, as shown here. 189 The reader should be familiar with the terms defined in [RFC8612]. 191 "DOTS Telemetry" is defined as the collection of attributes that are 192 used to characterize normal traffic baseline, attacks and their 193 mitigation measures, and any related information that may help in 194 enforcing countermeasures. The DOTS Telemetry is an optional set of 195 attributes that can be signaled in the DOTS signal channel protocol. 197 The meaning of the symbols in YANG tree diagrams is defined in 198 [RFC8340]. 200 3. DOTS Telemetry: Overview & Purpose 202 When signaling a mitigation request, it is most certainly beneficial 203 for the DOTS client to signal to the DOTS server any knowledge 204 regarding ongoing attacks. This can happen in cases where DOTS 205 clients are asking the DOTS server for support in defending against 206 attacks that they have already detected and/or mitigated. These 207 actions taken by DOTS clients are referred to as "signaling the DOTS 208 Telemetry". 210 If attacks are already detected and categorized by the DOTS client 211 domain, the DOTS server, and its associated mitigation services, can 212 proactively benefit this information and optimize the overall service 213 delivered. It is important to note that DOTS client and server 214 detection and mitigation approaches can be different, and can 215 potentially outcome different results and attack classifications. 216 The DDoS mitigation service treats the ongoing attack details from 217 the client as hints and cannot completely rely or trust the attack 218 details conveyed by the DOTS client. 220 A basic requirement of security operation teams is to be aware and 221 get visibility into the attacks they need to handle. The DOTS server 222 security operation teams benefit from the DOTS telemetry, especially 223 from the reports of ongoing attacks. Even if some mitigation can be 224 automated, operational teams can use the DOTS telemetry to be 225 prepared for attack mitigation and to assign the correct resources 226 (operation staff, networking and mitigation) for the specific 227 service. Similarly, security operation personnel at the DOTS client 228 side ask for feedback about their requests for protection. 229 Therefore, it is valuable for the DOTS server to share DOTS telemetry 230 with the DOTS client. Thus mutual sharing of information is crucial 231 for "closing the mitigation loop" between the DOTS client and server. 232 For the server side team, it is important to realize that the same 233 attacks that the DOTS server's mitigation resources are seeing are 234 those that the DOTS client is asking to mitigate. For the DOTS 235 client side team, it is important to realize that the DOTS clients 236 receive the required service. For example: understanding that "I 237 asked for mitigation of two attacks and my DOTS server detects and 238 mitigates only one...". Cases of inconsistency in attack 239 classification between DOTS client and server can be high-lighted, 240 and maybe handled, using the DOTS telemetry attributes. 242 In addition, management and orchestration systems, at both DOTS 243 client and server sides, can potentially use DOTS telemetry as a 244 feedback to automate various control and management activities 245 derived from ongoing information signaled. 247 If the DOTS server's mitigation resources have the capabilities to 248 facilitate the DOTS telemetry, the DOTS server adopts its protection 249 strategy and activates the required countermeasures immediately 250 (automation enabled). The overall results of this adoption are 251 optimized attack mitigation decisions and actions. 253 The DOTS telemetry can also be used to tune the DDoS mitigators with 254 the correct state of the attack. During the last few years, DDoS 255 attack detection technologies have evolved from threshold-based 256 detection (that is, cases when all or specific parts of traffic cross 257 a pre-defined threshold for a certain period of time is considered as 258 an attack) to an "anomaly detection" approach. In anomaly detection, 259 the main idea is to maintain rigorous learning of "normal" behavior 260 and where an "anomaly" (or an attack) is identified and categorized 261 based on the knowledge about the normal behavior and a deviation from 262 this normal behavior. Machine learning approaches are used such that 263 the actual "traffic thresholds" are "automatically calculated" by 264 learning the protected entity normal traffic behavior during peace 265 time. The normal traffic characterization learned is referred to as 266 the "normal traffic baseline". An attack is detected when the 267 victim's actual traffic is deviating from this normal baseline. 269 In addition, subsequent activities toward mitigating an attack are 270 much more challenging. The ability to distinguish legitimate traffic 271 from attacker traffic on a per packet basis is complex. This 272 complexity originates from the fact that the packet itself may look 273 "legitimate" and no attack signature can be identified. The anomaly 274 can be identified only after detailed statistical analysis. DDoS 275 attack mitigators use the normal baseline during the mitigation of an 276 attack to identify and categorize the expected appearance of a 277 specific traffic pattern. Particularly the mitigators use the normal 278 baseline to recognize the "level of normality" needs to be achieved 279 during the various mitigation process. 281 Normal baseline calculation is performed based on continuous learning 282 of the normal behavior of the protected entities. The minimum 283 learning period varies from hours to days and even weeks, depending 284 on the protected application behavior. The baseline cannot be 285 learned during active attacks because attack conditions do not 286 characterize the protected entities' normal behavior. 288 If the DOTS client has calculated the normal baseline of its 289 protected entities, signaling this attribute to the DOTS server along 290 with the attack traffic levels is significantly valuable. The DOTS 291 server benefits from this telemetry by tuning its mitigation 292 resources with the DOTS client's normal baseline. The DOTS server 293 mitigators use the baseline to familiarize themselves with the attack 294 victim's normal behavior and target the baseline as the level of 295 normality they need to achieve. Consequently, the overall mitigation 296 performances obtained are dramatically improved in terms of time to 297 mitigate, accuracy, false-negative, false-positive, and other 298 measures. 300 Mitigation of attacks without having certain knowledge of normal 301 traffic can be inaccurate at best. This is especially true for 302 recursive signaling (see Section 3.2.3 in [I-D.ietf-dots-use-cases]). 303 In addition, the highly diverse types of use-cases where DOTS clients 304 are integrated also emphasize the need for knowledge of client 305 behavior. Consequently, common global thresholds for attack 306 detection practically cannot be realized. Each DOTS client can have 307 its own levels of traffic and normal behavior. Without facilitating 308 normal baseline signaling, it may be very difficult for DOTS servers 309 in some cases to detect and mitigate the attacks accurately. It is 310 important to emphasize that it is practically impossible for the 311 server's mitigators to calculate the normal baseline, in cases they 312 do not have any knowledge of the traffic beforehand. In addition, 313 baseline learning requires a period of time that cannot be afforded 314 during active attack. Of course, this information can provided using 315 out-of-band mechanisms or manual configuration at the risk to 316 maintain inaccurate information as the network evolves and "normal" 317 patterns change. The use of a dynamic and collaborative means 318 between the DOTS client and server to identify and share key 319 parameters for the sake of efficient DDoS protect is valuable. 321 During a high volume attack, DOTS client pipes can be totally 322 saturated. The DOTS client asks the DOTS server to handle the attack 323 upstream so that DOTS client pipes return to a reasonable load level 324 (normal pattern, ideally). At this point, it is essential to ensure 325 that the DOTS server does not overwhelm the DOTS client pipes by 326 sending back "clean traffic", or what it believes is "clean". This 327 can happen when the server has not managed to detect and mitigate all 328 the attacks launched towards the client. In this case, it can be 329 valuable to clients to signal to server the "Total pipe capacity", 330 which is the level of traffic the clients can absorb from the 331 upstream server. Dynamic updating of the condition of pipes between 332 DOTS agents while they are under a DDoS attack is essential. For 333 example, for cases of multiple DOTS clients share the same physical 334 connectivity pipes. It is important to note, that the term "pipe" 335 noted here does not necessary represent physical pipe, but rather 336 represents the current level of traffic client can observe from 337 server. The server should activate other mechanisms to ensure it 338 does not saturate the client's pipes unintentionally. The rate-limit 339 action defined in [I-D.ietf-dots-data-channel] can be a reasonable 340 candidate to achieve this objective; the client can ask for the type 341 of traffic (such as ICMP, UDP, TCP port 80) it prefers to limit. 343 To summarize, timely and effective signaling of up-to-date DOTS 344 telemetry to all elements involved in the mitigation process is 345 essential and absolutely improves the overall service effectiveness. 346 Bi-directional feedback between DOTS agents is required for the 347 increased awareness of each party, supporting superior and highly 348 efficient attack mitigation service. 350 4. DOTS Telemetry Attributes 352 This section outlines the set of DOTS telemetry attributes. The 353 ultimate objective of these attributes is to allow for the complete 354 knowledge of attacks and the various particulars that can best 355 characterize attacks. 357 The description and motivation behind each attribute were presented 358 in Section 3. DOTS telemetry attributes are optionally signaled and 359 therefore MUST NOT be treated as mandatory fields in the DOTS signal 360 channel protocol. 362 4.1. Pre-mitigation DOTS Telemetry Attributes 364 The following pre-mitigation telemetry attributes can be signaled 365 from the DOTS client to the DOTS server. 367 o DISCUSSION NOTES: (1) Some telemetry can be communicated using 368 DOTS data channel. (2) Evaluate the risk of fragmentation, or (3) 369 check if we can define a dedicated URI for telemetry (e.g.: use 370 ./telemetry). Some of the information is not specific to each 371 mitigation request. 373 4.1.1. Total Traffic Normal Baseline 375 The low percentile (10th percentile), mid percentile (50th 376 percentile), high percentile (90th percentile) and peak values of 377 "Total traffic normal baselines" measured in kilobytes per second or 378 megabytes per second or gigabytes per second. 380 4.1.2. Total Pipe Capability 382 The limit of traffic volume, in kilobytes per second or megabytes per 383 second or gigabytes per second. This attribute represents the DOTS 384 client domain pipe limit. 386 o NOTE: Multi-homing case to be considered. 388 4.1.3. Total Attack Traffic 390 The low percentile (10th percentile), mid percentile (50th 391 percentile), high percentile (90th percentile) and peak values of 392 total attack traffic measured in kilobytes per second or megabytes 393 per second or gigabytes per second. 395 4.1.4. Total Traffic 397 The low percentile (10th percentile), mid percentile (50th 398 percentile), high percentile (90th percentile) and peak values of 399 total traffic during a DDoS attack measured in kilobytes per second 400 or megabytes per second gigabytes per second. 402 4.1.5. Attack Details 404 Various information and details that describe the on-going attacks 405 that needs to be mitigated by the DOTS server. The attack details 406 need to cover well-known and common attacks (such as a SYN Flood) 407 along with new emerging or vendor-specific attacks. The following 408 fields describing the on-going attack are discussed: 410 vendor-id: Vendor ID is a security vendor's Enterprise Number as 411 registered with IANA [Enterprise-Numbers]. It is a four-byte 412 integer value. 414 This is a mandatory sub-attribute. 416 attack-id: Unique identifier assigned by the vendor for the attack. 418 This is a mandatory sub-attribute. 420 attack-name: Textual representation of attack description. Natural 421 Language Processing (e.g., word embedding) can possibly be used to 422 map the attack description to an attack type. Textual 423 representation of attack solves two problems (a) avoids the need 424 to create mapping tables manually between vendors (2) Avoids the 425 need to standardize attack types which keep evolving. 427 This is a mandatory sub-attribute 429 attack-severity: Attack severity. Emergency (0), critical (1) and 430 alert (2). 432 This is an optional sub-attribute 434 4.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry 435 Attributes 437 The mitigation efficacy telemetry attributes can be signaled from the 438 DOTS client to the DOTS server as part of the periodic mitigation 439 efficacy updates to the server. 441 4.2.1. Total Attack Traffic 443 The low percentile (10th percentile), mid percentile (50th 444 percentile), high percentile (90th percentile) and peak values of 445 total attack traffic the DOTS client still sees during the active 446 mitigation service measured in kilobytes per second or megabytes per 447 second or gigabytes per second. 449 4.2.2. Attack Details 451 The overall attack details as observed from the DOTS client 452 perspective during the active mitigation service. The same 453 attributes defined in Section 4.1.5 are applicable here. 455 4.3. DOTS Server to Client Mitigation Status DOTS Telemetry Attributes 457 The mitigation status telemetry attributes can be signaled from the 458 DOTS server to the DOTS client as part of the periodic mitigation 459 status update. 461 4.3.1. Mitigation Status 463 As defined in [RFC8612], the actual mitigation activities can include 464 several countermeasure mechanisms. The DOTS server SHOULD signal the 465 current operational status to each relevant countermeasure. A list 466 of attacks detected by each countermeasure. The same attributes 467 defined for Section 4.1.5 are applicable here for describing the 468 attacks detected and mitigated. 470 5. DOTS Telemetry YANG Module 472 5.1. Tree Structure 474 TODO 476 5.2. YANG Module 478 TODO 480 6. IANA Considerations 482 6.1. DOTS Signal Channel CBOR Mappings Registry 484 This specification registers the DOTS telemetry attributes in the 485 IANA "DOTS Signal Channel CBOR Mappings" registry established by 486 [I-D.ietf-dots-signal-channel]. 488 The DOTS telemetry attributes defined in this specification are 489 comprehension-optional parameters. 491 o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys 492 are assigned from the 0x8000 - 0xBFFF range. 494 +-------------------+------------+--------+---------------+--------+ 495 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 496 | | Type | Key | Type & | Type | 497 | | | | Information | | 498 +-------------------+------------+--------+---------------+--------+ 499 | TODO | | | | | 500 +-------------------+------------+--------+---------------+--------+ 502 6.2. DOTS Signal Telemetry YANG Module 504 This document requests IANA to register the following URI in the "ns" 505 subregistry within the "IETF XML Registry" [RFC3688]: 507 URI: urn:ietf:params:xml:ns:yang:TODO 508 Registrant Contact: The IESG. 509 XML: N/A; the requested URI is an XML namespace. 511 This document requests IANA to register the following YANG module in 512 the "YANG Module Names" subregistry [RFC7950] within the "YANG 513 Parameters" registry. 515 name: ietf-dots-telemetry 516 namespace: urn:ietf:params:xml:ns:yang:TODO 517 maintained by IANA: N 518 prefix: dots-telemetry 519 reference: RFC XXXX 521 7. Security Considerations 523 Security considerations in [I-D.ietf-dots-signal-channel] need to be 524 taken into consideration. 526 8. Acknowledgements 528 The authors would like to thank Flemming Andreasen, Liang Xia, and 529 Kaname Nishizuka co-authors of https://tools.ietf.org/html/draft- 530 doron-dots-telemetry-00 draft and everyone who had contributed to 531 that document. 533 9. References 535 9.1. Normative References 537 [Enterprise-Numbers] 538 "Private Enterprise Numbers", 2005, . 541 [I-D.ietf-dots-data-channel] 542 Boucadair, M. and R. K, "Distributed Denial-of-Service 543 Open Threat Signaling (DOTS) Data Channel Specification", 544 draft-ietf-dots-data-channel-30 (work in progress), July 545 2019. 547 [I-D.ietf-dots-signal-channel] 548 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 549 Teague, "Distributed Denial-of-Service Open Threat 550 Signaling (DOTS) Signal Channel Specification", draft- 551 ietf-dots-signal-channel-35 (work in progress), July 2019. 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, 555 DOI 10.17487/RFC2119, March 1997, 556 . 558 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 559 DOI 10.17487/RFC3688, January 2004, 560 . 562 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 563 RFC 7950, DOI 10.17487/RFC7950, August 2016, 564 . 566 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 567 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 568 May 2017, . 570 9.2. Informative References 572 [I-D.ietf-dots-use-cases] 573 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 574 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 575 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 576 in progress), January 2019. 578 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 579 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 580 . 582 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 583 Threat Signaling (DOTS) Requirements", RFC 8612, 584 DOI 10.17487/RFC8612, May 2019, 585 . 587 Authors' Addresses 589 Tirumaleswar Reddy 590 McAfee, Inc. 591 Embassy Golf Link Business Park 592 Bangalore, Karnataka 560071 593 India 595 Email: kondtir@gmail.com 597 Mohamed Boucadair 598 Orange 599 Rennes 35000 600 France 602 Email: mohamed.boucadair@orange.com 604 Ehud Doron 605 Radware Ltd. 606 Raoul Wallenberg Street 607 Tel-Aviv 69710 608 Israel 610 Email: ehudd@radware.com