idnits 2.17.1 draft-reddy-dots-telemetry-01.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 22, 2019) is 1740 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 (-41) exists of draft-ietf-dots-signal-channel-35 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-18 Summary: 0 errors (**), 0 flaws (~~), 3 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 23, 2020 Orange 6 E. Doron 7 Radware Ltd. 8 July 22, 2019 10 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry 11 draft-reddy-dots-telemetry-01 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 23, 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 . . . . . . . . . . . . . . . . . 11 78 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 11 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 packets per second (PPS) 378 or kilo packets per second (Kpps) and Bits per Second (BPS), and 379 kilobytes per second or megabytes per second or gigabytes per second. 381 4.1.2. Total Pipe Capability 383 The limit of traffic volume, in packets per second (PPS) or kilo 384 packets per second (Kpps) and Bits per Second (BPS), and in kilobytes 385 per second or megabytes per second or gigabytes per second. These 386 attributes represents the DOTS client domain pipe limit. 388 o NOTE: Multi-homing case to be considered. 390 4.1.3. Total Attack Traffic 392 The total attack traffic can be identified by the DOTS client 393 domain's DDoS Mitigation System (DMS) or DDoS Detector. The low 394 percentile (10th percentile), mid percentile (50th percentile), high 395 percentile (90th percentile) and peak values of total attack traffic 396 measured in packets per second (PPS) or kilo packets per second 397 (Kpps) and Bits per Second (BPS), and kilobytes per second or 398 megabytes per second or gigabytes per second. 400 4.1.4. Total Traffic 402 The low percentile (10th percentile), mid percentile (50th 403 percentile), high percentile (90th percentile) and peak values of 404 total traffic during a DDoS attack measured in packets per second 405 (PPS) or kilo packets per second (Kpps) and Bits per Second (BPS), 406 and kilobytes per second or megabytes per second gigabytes per 407 second. 409 4.1.5. Attack Details 411 Various information and details that describe the on-going attacks 412 that needs to be mitigated by the DOTS server. The attack details 413 need to cover well-known and common attacks (such as a SYN Flood) 414 along with new emerging or vendor-specific attacks. The following 415 fields describing the on-going attack are discussed: 417 vendor-id: Vendor ID is a security vendor's Enterprise Number as 418 registered with IANA [Enterprise-Numbers]. It is a four-byte 419 integer value. 421 This is a mandatory sub-attribute. 423 attack-id: Unique identifier assigned by the vendor for the attack. 425 This is a mandatory sub-attribute. 427 attack-name: Textual representation of attack description. Natural 428 Language Processing techniques (e.g., word embedding) can possibly 429 be used to map the attack description to an attack type. Textual 430 representation of attack solves two problems (a) avoids the need 431 to create mapping tables manually between vendors (2) Avoids the 432 need to standardize attack types which keep evolving. 434 This is a mandatory sub-attribute 436 attack-severity: Attack severity. Emergency (0), critical (1) and 437 alert (2). 439 This is an optional sub-attribute 441 4.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry 442 Attributes 444 The mitigation efficacy telemetry attributes can be signaled from the 445 DOTS client to the DOTS server as part of the periodic mitigation 446 efficacy updates to the server. 448 4.2.1. Total Attack Traffic 450 The low percentile (10th percentile), mid percentile (50th 451 percentile), high percentile (90th percentile) and peak values of 452 total attack traffic the DOTS client still sees during the active 453 mitigation service measured in packets per second (PPS) or kilo 454 packets per second (Kpps) and Bits per Second (BPS), and kilobytes 455 per second or megabytes per second or gigabytes per second. 457 4.2.2. Attack Details 459 The overall attack details as observed from the DOTS client 460 perspective during the active mitigation service. The same 461 attributes defined in Section 4.1.5 are applicable here. 463 4.3. DOTS Server to Client Mitigation Status DOTS Telemetry Attributes 465 The mitigation status telemetry attributes can be signaled from the 466 DOTS server to the DOTS client as part of the periodic mitigation 467 status update. 469 4.3.1. Mitigation Status 471 As defined in [RFC8612], the actual mitigation activities can include 472 several countermeasure mechanisms. The DOTS server SHOULD signal the 473 current operational status to each relevant countermeasure. A list 474 of attacks detected by each countermeasure. The same attributes 475 defined for Section 4.1.5 are applicable here for describing the 476 attacks detected and mitigated. 478 5. DOTS Telemetry YANG Module 480 5.1. Tree Structure 482 TODO 484 5.2. YANG Module 486 TODO 488 6. IANA Considerations 490 6.1. DOTS Signal Channel CBOR Mappings Registry 492 This specification registers the DOTS telemetry attributes in the 493 IANA "DOTS Signal Channel CBOR Mappings" registry established by 494 [I-D.ietf-dots-signal-channel]. 496 The DOTS telemetry attributes defined in this specification are 497 comprehension-optional parameters. 499 o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys 500 are assigned from the 0x8000 - 0xBFFF range. 502 +-------------------+------------+--------+---------------+--------+ 503 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 504 | | Type | Key | Type & | Type | 505 | | | | Information | | 506 +-------------------+------------+--------+---------------+--------+ 507 | TODO | | | | | 508 +-------------------+------------+--------+---------------+--------+ 510 6.2. DOTS Signal Telemetry YANG Module 512 This document requests IANA to register the following URI in the "ns" 513 subregistry within the "IETF XML Registry" [RFC3688]: 515 URI: urn:ietf:params:xml:ns:yang:TODO 516 Registrant Contact: The IESG. 517 XML: N/A; the requested URI is an XML namespace. 519 This document requests IANA to register the following YANG module in 520 the "YANG Module Names" subregistry [RFC7950] within the "YANG 521 Parameters" registry. 523 name: ietf-dots-telemetry 524 namespace: urn:ietf:params:xml:ns:yang:TODO 525 maintained by IANA: N 526 prefix: dots-telemetry 527 reference: RFC XXXX 529 7. Security Considerations 531 Security considerations in [I-D.ietf-dots-signal-channel] need to be 532 taken into consideration. 534 8. Acknowledgements 536 The authors would like to thank Flemming Andreasen, Liang Xia, and 537 Kaname Nishizuka co-authors of https://tools.ietf.org/html/draft- 538 doron-dots-telemetry-00 draft and everyone who had contributed to 539 that document. 541 9. References 543 9.1. Normative References 545 [Enterprise-Numbers] 546 "Private Enterprise Numbers", 2005, . 549 [I-D.ietf-dots-data-channel] 550 Boucadair, M. and R. K, "Distributed Denial-of-Service 551 Open Threat Signaling (DOTS) Data Channel Specification", 552 draft-ietf-dots-data-channel-31 (work in progress), July 553 2019. 555 [I-D.ietf-dots-signal-channel] 556 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 557 Teague, "Distributed Denial-of-Service Open Threat 558 Signaling (DOTS) Signal Channel Specification", draft- 559 ietf-dots-signal-channel-35 (work in progress), July 2019. 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, 563 DOI 10.17487/RFC2119, March 1997, 564 . 566 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 567 DOI 10.17487/RFC3688, January 2004, 568 . 570 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 571 RFC 7950, DOI 10.17487/RFC7950, August 2016, 572 . 574 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 575 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 576 May 2017, . 578 9.2. Informative References 580 [I-D.ietf-dots-use-cases] 581 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 582 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 583 Open Threat Signaling", draft-ietf-dots-use-cases-18 (work 584 in progress), July 2019. 586 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 587 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 588 . 590 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 591 Threat Signaling (DOTS) Requirements", RFC 8612, 592 DOI 10.17487/RFC8612, May 2019, 593 . 595 Authors' Addresses 597 Tirumaleswar Reddy 598 McAfee, Inc. 599 Embassy Golf Link Business Park 600 Bangalore, Karnataka 560071 601 India 603 Email: kondtir@gmail.com 605 Mohamed Boucadair 606 Orange 607 Rennes 35000 608 France 610 Email: mohamed.boucadair@orange.com 611 Ehud Doron 612 Radware Ltd. 613 Raoul Wallenberg Street 614 Tel-Aviv 69710 615 Israel 617 Email: ehudd@radware.com