idnits 2.17.1 draft-nishizuka-dots-signal-control-filtering-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-dots-data-channel], [I-D.ietf-dots-signal-channel], [RFCXXXX]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 22, 2018) is 1982 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: 'RFCXXXX' is mentioned on line 36, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-22 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-25 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-16 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS K. Nishizuka 3 Internet-Draft NTT Communications 4 Intended status: Standards Track T. Nagata 5 Expires: May 26, 2019 Lepidum 6 T. Reddy 7 McAfee 8 M. Boucadair 9 Orange 10 November 22, 2018 12 Controlling Filtering Rules Using DOTS Signal Channel 13 draft-nishizuka-dots-signal-control-filtering-01 15 Abstract 17 This document specifies an extension to the DOTS signal channel to 18 control the filtering rules when an attack mitigation is active. 20 Particularly, this extension allows a DOTS client to activate or de- 21 activate filtering rules during a DDoS attack. The characterization 22 of these filtering rules is supposed to be conveyed by a DOTS client 23 during peace time by means of DOTS data channel. 25 Editorial Note (To be removed by RFC Editor) 27 Please update these statements within the document with the RFC 28 number to be assigned to this document: 30 o "This version of this YANG module is part of RFC XXXX;" 32 o "RFC XXXX: Controlling Filtering Rules Using DOTS Signal Channel"; 34 o reference: RFC XXXX 36 o [RFCXXXX] 38 Please update these statements with the RFC number to be assigned to 39 the following documents: 41 o "RFC SSSS: Distributed Denial-of-Service Open Threat Signaling 42 (DOTS) Signal Channel Specification" (used to be 43 [I-D.ietf-dots-signal-channel]) 45 o "RFC DDDD: Distributed Denial-of-Service Open Threat Signaling 46 (DOTS) Data Channel Specification" (used to be 47 [I-D.ietf-dots-data-channel]) 49 Please update the "revision" date of the YANG module. 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at https://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on May 26, 2019. 68 Copyright Notice 70 Copyright (c) 2018 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (https://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 87 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4 88 2. Notational Conventions and Terminology . . . . . . . . . . . 4 89 3. Controlling Filtering Rules . . . . . . . . . . . . . . . . . 4 90 3.1. Binding of the Data Channel and Signal Channel . . . . . 4 91 3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 5 92 3.2.1. Filtering Control . . . . . . . . . . . . . . . . . . 5 93 3.2.2. Sample Examples . . . . . . . . . . . . . . . . . . . 6 94 3.2.3. DOTS Signal Filtering Control Module . . . . . . . . 10 95 3.2.3.1. Tree Structure . . . . . . . . . . . . . . . . . 10 96 3.2.3.2. YANG Module . . . . . . . . . . . . . . . . . . . 10 98 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 99 4.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 13 100 4.2. DOTS Signal Control Filtering YANG Module . . . . . . . . 13 101 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 102 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 103 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 104 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 105 7.2. Informative References . . . . . . . . . . . . . . . . . 15 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 108 1. Introduction 110 1.1. The Problem 112 The DOTS data channel protocol [I-D.ietf-dots-data-channel] is used 113 for bulk data exchange between DOTS agents to improve the 114 coordination of all the parties involved in the response to the DDoS 115 attack. Filter management is one of its tasks which enables a DOTS 116 client to retrieve DOTS server filtering capabilities and to manage 117 filtering rules. Filtering rules are used for dropping or rate- 118 limiting unwanted traffic, and permitting accept-listed traffic. 120 Unlike the DOTS signal channel, the DOTS data channel is not expected 121 to deal with attack conditions. As such, an issue that might be 122 encountered in some deployments is when filters installed by means of 123 DOTS data channel protocol may not function as expected during DDoS 124 attacks or exacerbate an ongoing DDoS attack. The DOTS data channel 125 cannot be used then to change these filters, which may complicate 126 DDoS mitigation operations [Interop]. 128 A typical case is a DOTS client which configures during peace time 129 filtering rules using DOTS data channel to permit traffic from 130 accept-listed sources, but during a volumetric DDoS attack the DDoS 131 mitigator identifies the source addresses/prefixes in the accept- 132 listed filtering rules are attacking the target. For example, an 133 attacker can spoof the IP addresses of accept-listed sources to 134 generate attack traffic or the attacker can compromise the accept- 135 listed sources and program them to launch DDoS attack. 137 [I-D.ietf-dots-signal-channel] is designed so that the DDoS server 138 notifies the conflict to the DOTS client ('conflict-cause' set to 2 139 (Conflicts with an existing accept list)), but the DOTS client may 140 not be able to withdraw the accept-list rules during the attack 141 period due to the high-volume attack traffic saturating the inbound 142 link. In other words, the DOTS client cannot use the DOTS data 143 channel to withdraw the accept-list filters when the DDoS attack is 144 in progress. This assumes that this DOTS client is the owner of the 145 filtering rule. 147 1.2. The Solution 149 This specification addresses the problems discussed in Section 1.1 by 150 adding the capability of managing filtering rules using the DOTS 151 signal channel, which enables a DOTS client to request the activation 152 or de-activation of filtering rules during a DDoS attack. 154 The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is 155 designed to enable a DOTS client to contact a DOTS server for help 156 even under severe network congestion conditions. Therefore, 157 extending the DOTS signal channel protocol to manage the filtering 158 rules during a attack will enhance the protection capability offered 159 by DOTS protocols. Sample examples are provided in Section 3.2.2. 161 Note: The experiment at the IETF103 hackathon [Interop] showed 162 that even when the incoming link is saturated by DDoS attack 163 traffic, the DOTS client can signal mitigation requests using the 164 DOTS signal channel over the saturated link. 166 Conflicts that are induced by filters installed by other DOTS clients 167 of the same domain are not discussed in this specification. 169 2. Notational Conventions and Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 The reader should be familiar with the terms defined in 178 [I-D.ietf-dots-requirements]. 180 3. Controlling Filtering Rules 182 3.1. Binding of the Data Channel and Signal Channel 184 The filtering rules eventually managed using the DOTS signal channel 185 must be created a priori by the same DOTS client using the DOTS data 186 channel. Managing conflicts with filters installed by other DOTS 187 clients of the same domain is out of scope. 189 As discussed in Section 4.4.1 of [I-D.ietf-dots-signal-channel], a 190 DOTS client must use the same 'cuid' for both the signal and data 191 channels. This requirement is meant to facilitate binding channels 192 used by the same DOTS client. 194 The DOTS signal and data channels from a DOTS client may or may not 195 use the same DOTS server. Nevertheless, the scope of the mitigation 196 request, alias, and filtering rules are not restricted to the DOTS 197 server but to the DOTS server administrative domain. To that aim, 198 DOTS servers within a domain are assumed to have a mechanism to 199 coordinate the mitigation requests, aliases, and filtering rules to 200 coordinate their decisions for better mitigation operation 201 efficiency. The exact details about such mechanism is out of scope 202 of this document. 204 A filtering rule controlled by the DOTS signal channel is identified 205 by its Access Control List (ACL) name. Note that an ACL name 206 unambiguously identifies an ACL bound to a DOTS client, but the same 207 name may be used by distinct DOTS clients. 209 The activation or de-activation of an ACL by the signal channel 210 overrides the 'activation-type' (defined in Section 7.2 211 [I-D.ietf-dots-data-channel]) a priori conveyed with the filtering 212 rules using the DOTS data channel. 214 3.2. DOTS Signal Channel Extension 216 3.2.1. Filtering Control 218 This specification extends the mitigation request defined in 219 [I-D.ietf-dots-signal-channel] to convey the intended control of the 220 configured filtering rules. The DOTS client conveys the following 221 parameters in the CBOR body of the mitigation request: 223 acl-name: A name of an access list defined in the data channel. 225 As a reminder, an ACL is an ordered list of Access Control Entries 226 (ACE). Each Access Control Entry has a list of match criteria and 227 a list of actions [I-D.ietf-dots-data-channel]. The list of 228 configured ACLs can be retrieved using the DOTS data channel 229 during peace time. 231 This is an optional attribute. 233 activation-type: Indicates the activation type of an ACL overriding 234 the existing 'activation-type' installed by the DOTS client using 235 the DOTS data channel. 237 This attribute can be set to 'deactivate', 'immediate', or 238 'activate-when-mitigating' defined [I-D.ietf-dots-data-channel]. 240 Note that 'immediate' or 'activate-when-mitigating' are equivalent 241 when a mitigation request is being processed by the DOTS server. 243 If this attribute is not provided, the DOTS server MUST use 244 'activate-when-mitigating' as the default value. 246 This is an optional attribute. 248 If the DOTS server does not find the ACL name conveyed in the 249 mitigation request in its configuration data for this DOTS client, it 250 MUST respond with a "4.04 (Not Found)" error response code. 252 It is RECOMMENDED for a DOTS client to subscribe to asynchronous 253 notifications of the attack mitigation, as detailed in 254 Section 4.4.2.1 of [I-D.ietf-dots-signal-channel]. If not, the 255 polling mechanism in Section 4.4.2.2 of 256 [I-D.ietf-dots-signal-channel] has to be followed by the DOTS client. 258 A DOTS client relies on the information received from the DOTS server 259 and/or local information to the DOTS client domain to trigger a 260 filter control request. Obviously, only filters that are pertinent 261 for an ongoing mitigation should be controlled by a DOTS client using 262 the DOTS signal channel. 264 3.2.2. Sample Examples 266 This section provides sample examples to illustrate the behavior 267 specified in Section 3.2.1. 269 Let's consider a DOTS client which contacts its DOTS server during 270 peace time to install an accept-list allowing for UDP traffic issued 271 from 2001:db8:1234::/48 with a destination port number 443 to be 272 forwarded to 2001:db8:6401::2/127. It does so by sending, for 273 example, a PUT request shown in Figure 1. 275 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 276 /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ 277 /acl=an-accept-list HTTP/1.1 278 Host: {host}:{port} 279 Content-Type: application/yang-data+json 280 { 281 "ietf-dots-data-channel:acls": { 282 "acl": [ 283 { 284 "name": "an-accept-list", 285 "type": "ipv6-acl-type", 286 "activation-type": "activate-when-mitigating", 287 "aces": { 288 "ace": [ 289 { 290 "name": "test-ace-ipv6-udp", 291 "matches": { 292 "ipv6": { 293 "destination-ipv6-network": "2001:db8:6401::2/127", 294 "source-ipv6-network": "2001:db8:1234::/48" 295 }, 296 "udp": { 297 "destination-port": { 298 "operator": "eq", 299 "port": 443 300 } 301 } 302 }, 303 "actions": { 304 "forwarding": "accept" 305 } 306 } 307 ] 308 } 309 } 310 ] 311 } 312 } 314 Figure 1: DOTS Data Channel Request to Create a Filtering 316 Some time later, consider that a DDoS attack is detected by the DOTS 317 client on 2001:db8:6401::2/127. Consequently, the DOTS client sends 318 a mitigation request to its DOTS server as shown in Figure 2. 320 Header: PUT (Code=0.03) 321 Uri-Path: ".well-known" 322 Uri-Path: "dots" 323 Uri-Path: "mitigate" 324 Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" 325 Uri-Path: "mid=123" 326 Content-Format: "application/dots+cbor" 327 { 328 "ietf-dots-signal-channel:mitigation-scope": { 329 "scope": [ 330 { 331 "target-prefix": [ 332 "2001:db8:6401::2/127" 333 ], 334 "target-protocol": [ 335 17 336 ], 337 "lifetime": 3600 338 } 339 ] 340 } 341 } 343 Figure 2: DOTS Signal Channel Mitigation Request 345 The DOTS server accepts immediately the request by replying with 2.01 346 (Created) (Figure 3). 348 { 349 "ietf-dots-signal-channel:mitigation-scope": { 350 "scope": [ 351 { 352 "mid": 123, 353 "lifetime": 3600, 354 } 355 ] 356 } 357 } 359 Figure 3: Conflict Status Response 361 Assuming the DOTS client subscribed to asynchronous notifications, 362 when the DOTS server concludes that some of the attack sources belong 363 to 2001:db8:1234::/48, it sends a notification message with 'status' 364 code set to '1 (Attack mitigation is in progress)' and 'conflict- 365 cause' set to '2' (conflict-with-acceptlist) to the DOTS client to 366 indicate that this mitigation request is in progress, but a conflict 367 is detected. 369 Upon receipt of the notification message from the DOTS server, the 370 DOTS client sends a PUT request to deactivate the "an-accept-list" 371 ACL as shown in Figure 4. 373 The DOTS client can also decide to send a PUT request to deactivate 374 the "an-accept-list" ACL, if suspect traffic is received from an 375 accept-listed source (2001:db8:1234::/48). The structure of that PUT 376 is the same as the one shown in Figure 4. 378 Header: PUT (Code=0.03) 379 Uri-Path: ".well-known" 380 Uri-Path: "dots" 381 Uri-Path: "mitigate" 382 Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" 383 Uri-Path: "mid=123" 384 Content-Format: "application/dots+cbor" 385 { 386 "ietf-dots-signal-channel:mitigation-scope": { 387 "scope": [ 388 { 389 "target-prefix": [ 390 "2001:db8:6401::2/127" 391 ], 392 "target-protocol": [ 393 17 394 ], 395 "acl-list": [ 396 { 397 "acl-name": "an-accept-list", 398 "activation-type": "deactivate" 399 } 400 ] 401 "lifetime": 3600 402 } 403 ] 404 } 405 } 407 Figure 4: PUT for Controlling a Filter 409 Then, the DOTS server deactivates "an-accept-list" ACL and replies 410 with 2.04 (Changed) response to the DOTS client to confirm the 411 successful operation. 413 3.2.3. DOTS Signal Filtering Control Module 415 3.2.3.1. Tree Structure 417 This document augments the "dots-signal-channel" DOTS signal YANG 418 module defined in [I-D.ietf-dots-signal-channel] for managing the 419 filtering rules. 421 This document defines the YANG module "ietf-dots-signal-control- 422 filter", which has the following tree structure: 424 module: ietf-dots-signal-control-filter 425 augment /ietf-signal:dots-signal/ietf-signal:message-type 426 /ietf-signal:mitigation-scope/ietf-signal:scope: 427 +--rw acl-list* [acl-name] {control-filtering}? 428 +--rw acl-name 429 | -> /ietf-data:dots-data/dots-client/acls/acl/name 430 +--rw activation-type? enumeration 432 3.2.3.2. YANG Module 434 file "ietf-dots-signal-control-filter@2018-11-20.yang" 436 module ietf-dots-signal-control-filter { 437 yang-version 1.1; 438 namespace 439 "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control-filter"; 440 prefix signal-control-filter; 442 import ietf-dots-signal-channel { 443 prefix ietf-signal; 444 reference 445 "RFC SSSS: Distributed Denial-of-Service Open Threat 446 Signaling (DOTS) Signal Channel Specification"; 447 } 448 import ietf-dots-data-channel { 449 prefix ietf-data; 450 reference 451 "RFC DDDD: Distributed Denial-of-Service Open Threat 452 Signaling (DOTS) Data Channel Specification"; 453 } 455 organization 456 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 457 contact 458 "WG Web: 459 WG List: 460 Author: Konda, Tirumaleswar Reddy 461 463 Author: Mohamed Boucadair 464 466 Author: Kaname Nishizuka 467 469 Author: Takahiko Nagata 470 "; 472 description 473 "This module contains YANG definition for the signaling 474 messages exchanged between a DOTS client and a DOTS server 475 for the DOTS signal channel controlling the filtering rules 476 configured using the DOTS data channel. 478 Copyright (c) 2018 IETF Trust and the persons identified as 479 authors of the code. All rights reserved. 481 Redistribution and use in source and binary forms, with or 482 without modification, is permitted pursuant to, and subject 483 to the license terms contained in, the Simplified BSD License 484 set forth in Section 4.c of the IETF Trust's Legal Provisions 485 Relating to IETF Documents 486 (http://trustee.ietf.org/license-info). 488 This version of this YANG module is part of RFC XXXX; see 489 the RFC itself for full legal notices."; 491 revision 2018-11-20 { 492 description 493 "Initial revision."; 494 reference 495 "RFC XXXX: Controlling Filtering Rules Using DOTS Signal 496 Channel "; 497 } 499 feature control-filtering { 500 description 501 "This feature means that DOTS signal channel is able to 502 manage the filtering rules created by the same DOTS 503 client using the DOTS data channel."; 504 } 506 augment "/ietf-signal:dots-signal/ietf-signal:message-type/" + 507 "ietf-signal:mitigation-scope/ietf-signal:scope" { 509 if-feature control-filtering; 511 description "ACL name and activation type"; 513 list acl-list { 514 key "acl-name"; 515 description 516 "List of ACLs as defined in the DOTS data 517 channel. These ACLs are uniquely defined by 518 cuid and name."; 519 leaf acl-name { 520 type leafref { 521 path "/ietf-data:dots-data/ietf-data:dots-client/" + 522 "ietf-data:acls/ietf-data:acl/ietf-data:name"; 523 } 524 description 525 "Reference to the ACL name bound to a DOTS client."; 526 } 527 leaf activation-type { 528 type enumeration { 529 enum "activate-when-mitigating" { 530 value 1; 531 description 532 "The ACL is installed only when a mitigation is active. 533 The ACL is specific to this DOTS client."; 534 } 535 enum "immediate" { 536 value 2; 537 description 538 "The ACL is immediately activated."; 539 } 540 enum "deactivate" { 541 value 3; 542 description 543 "The ACL is maintained by the DOTS server, but it is 544 deactivated."; 545 } 546 } 547 description 548 "Set the activation type of an ACL."; 549 } 550 } 551 } 552 } 553 555 4. IANA Considerations 557 4.1. DOTS Signal Channel CBOR Mappings Registry 559 This specification registers the 'activation-type' parameter in the 560 IANA "DOTS Signal Channel CBOR Mappings" registry established by 561 [I-D.ietf-dots-signal-channel]. 563 The 'activation-type' is a comprehension-required parameter. The 564 'acl-list' and 'acl-name' parameters are defined as comprehension- 565 required parameters in Table 6 in [I-D.ietf-dots-signal-channel]. 566 Following the rules in [I-D.ietf-dots-signal-channel], if the DOTS 567 server does not understand the 'acl-list' or 'acl-name' or 568 'activation-type' attributes, it responds with a "4.00 (Bad Request)" 569 error response code. 571 o Note to the RFC Editor: Please delete (TBD1) once the CBOR key is 572 assigned from the (0x0001 - 0x3FFF) range. 574 +-------------------+------------+--------+---------------+--------+ 575 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 576 | | Type | Key | Type & | Type | 577 | | | | Information | | 578 +-------------------+------------+--------+---------------+--------+ 579 | activation-type | enumeration| 0x0031 | 0 unsigned | String | 580 | | | (TBD1) | | | 581 +-------------------+------------+--------+---------------+--------+ 583 4.2. DOTS Signal Control Filtering YANG Module 585 This document requests IANA to register the following URI in the 586 "IETF XML Registry" [RFC3688]: 588 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control-filter 589 Registrant Contact: The IESG. 590 XML: N/A; the requested URI is an XML namespace. 592 This document requests IANA to register the following YANG module in 593 the "YANG Module Names" registry [RFC7950]. 595 name: ietf-dots-signal-control-filter 596 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control-filter 597 prefix: signal-control-filter 598 reference: RFC XXXX 600 5. Security Considerations 602 The security considerations discussed in 603 [I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel] need 604 to be taken into account. 606 6. Acknowledgements 608 TBD 610 7. References 612 7.1. Normative References 614 [I-D.ietf-dots-data-channel] 615 Boucadair, M., K, R., Nishizuka, K., Xia, L., Patil, P., 616 Mortensen, A., and N. Teague, "Distributed Denial-of- 617 Service Open Threat Signaling (DOTS) Data Channel 618 Specification", draft-ietf-dots-data-channel-22 (work in 619 progress), September 2018. 621 [I-D.ietf-dots-signal-channel] 622 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 623 Teague, "Distributed Denial-of-Service Open Threat 624 Signaling (DOTS) Signal Channel Specification", draft- 625 ietf-dots-signal-channel-25 (work in progress), September 626 2018. 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, 630 DOI 10.17487/RFC2119, March 1997, 631 . 633 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 634 DOI 10.17487/RFC3688, January 2004, 635 . 637 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 638 RFC 7950, DOI 10.17487/RFC7950, August 2016, 639 . 641 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 642 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 643 May 2017, . 645 7.2. Informative References 647 [I-D.ietf-dots-requirements] 648 Mortensen, A., Moskowitz, R., and R. K, "Distributed 649 Denial of Service (DDoS) Open Threat Signaling 650 Requirements", draft-ietf-dots-requirements-16 (work in 651 progress), October 2018. 653 [Interop] Nishizuka, K., Shallow, J., and L. Xia , "DOTS Interop 654 test report, IETF 103 Hackathon", November 2018, 655 . 659 Authors' Addresses 661 Kaname Nishizuka 662 NTT Communications 663 GranPark 16F 3-4-1 Shibaura, Minato-ku 664 Tokyo 108-8118 665 Japan 667 Email: kaname@nttv6.jp 669 Takahiko Nagata 670 Lepidum 671 Japan 673 Email: nagata@lepidum.co.jp 675 Tirumaleswar Reddy 676 McAfee, Inc. 677 Embassy Golf Link Business Park 678 Bangalore, Karnataka 560071 679 India 681 Email: kondtir@gmail.com 683 Mohamed Boucadair 684 Orange 685 Rennes 35000 686 France 688 Email: mohamed.boucadair@orange.com