idnits 2.17.1 draft-bosh-dots-quick-blocks-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 13, 2021) is 1199 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 592, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-core-new-block-04 == Outdated reference: A later version (-08) exists of draft-ietf-dots-rfc8782-bis-04 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-25) exists of draft-ietf-dots-telemetry-15 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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 J. Shallow 5 Expires: July 17, 2021 January 13, 2021 7 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 8 Channel Configuration Attributes for Faster Block Transmission 9 draft-bosh-dots-quick-blocks-01 11 Abstract 13 This document specifies new DOTS signal channel configuration 14 parameters that are negotiated between DOTS peers to enable the use 15 of Q-Block1 and Q-Block2 Options. These options enable faster 16 transmission rates for large amounts of data with less packet 17 interchanges as well as supporting faster recovery should any of the 18 blocks get lost in transmission. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 17, 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. DOTS Attributes for Faster Block Transmission . . . . . . . . 4 57 4. DOTS Fast Block Transmission YANG Module . . . . . . . . . . 7 58 4.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 7 59 4.2. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . 9 60 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 5.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 13 63 5.2. DOTS Signal Filtering Control YANG Module . . . . . . . . 14 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 68 8.2. Informative References . . . . . . . . . . . . . . . . . 16 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 71 1. Introduction 73 The Constrained Application Protocol (CoAP) [RFC7252], although 74 inspired by HTTP, was designed to use UDP instead of TCP. The 75 message layer of CoAP over UDP includes support for reliable 76 delivery, simple congestion control, and flow control. [RFC7959] 77 introduced the CoAP Block1 and Block2 Options to handle data records 78 that cannot fit in a single IP packet, so not having to rely on IP 79 fragmentation and was further updated by [RFC8323] for use over TCP, 80 TLS, and WebSockets. 82 The CoAP Block1 and Block2 Options work well in environments where 83 there are no or minimal packet losses. These options operate 84 synchronously where each individual block has to be requested and can 85 only ask for (or send) the next block when the request for the 86 previous block has completed. Packet, and hence block transmission 87 rate, is controlled by Round Trip Times (RTTs). 89 There is a requirement for these blocks of data to be transmitted at 90 higher rates under network conditions where there may be asymmetrical 91 transient packet loss (i.e., responses may get dropped). An example 92 is when a network is subject to a Distributed Denial of Service 93 (DDoS) attack and there is a need for DDoS mitigation agents relying 94 upon CoAP to communicate with each other (e.g., 95 [I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] recommends the 96 use of Confirmable (CON) responses to handle potential packet loss. 98 However, such a recommendation does not work with a flooded pipe DDoS 99 situation. 101 The block-wise transfer specified in [RFC7959] covers the general 102 case, but falls short in situations where packet loss is highly 103 asymmetrical. The mechanism specified in [I-D.ietf-core-new-block] 104 provides roughly similar features to the Block1/Block2 Options. It 105 provides additional properties that are tailored towards the intended 106 DOTS transmission. Concretely, [I-D.ietf-core-new-block] primarily 107 targets applications such as DDoS Open Threat Signaling (DOTS) that 108 can't use Confirmable (CON) responses to handle potential packet loss 109 and that support application-specific mechanisms to assess whether 110 the remote peer is able to handle the messages sent by a CoAP 111 endpoint (e.g., DOTS heartbeats in Section 4.7 of 112 [I-D.ietf-dots-rfc8782-bis]). 114 [I-D.ietf-core-new-block] includes guards to prevent a CoAP agent 115 from overloading the network by adopting an aggressive sending rate. 116 These guards are followed in addition to the existing CoAP congestion 117 control as specified in Section 4.7 of [RFC7252]. Table 1 lists the 118 CoAP attributes that are used for 120 +---------------------+---------------+ 121 | Parameter Name | Default Value | 122 +=====================+===============| 123 | MAX_PAYLOADS | 10 | 124 | NON_MAX_RETRANSMIT | 4 | 125 | NON_TIMEOUT | 2 s | 126 | NON_RECEIVE_TIMEOUT | 4 s | 127 | NON_PROBING_WAIT | 247 s | 128 | NON_PARTIAL_TIMEOUT | 247 s | 129 +---------------------+---------------+ 131 Table 1: Congestion Control Parameters 133 PROBING_RATE and other transmission parameters are negotiated between 134 DOTS peers as discussed in Section 4.5.2 of 135 [I-D.ietf-dots-rfc8782-bis]. Nevertheless, some of the attributes 136 listed in Table 1 are not supported. This document defines new DOTS 137 signal channel attributes that are meant to customize the 138 configuration of faster block transmission in a DOTS context. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119][RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 Readers should be familiar with the terms and concepts defined in 149 [RFC7252] and [RFC8612]. 151 The terms "payload" and "body" are defined in [RFC7959]. The term 152 "payload" is thus used for the content of a single CoAP message 153 (i.e., a single block being transferred), while the term "body" is 154 used for the entire resource representation that is being transferred 155 in a block-wise fashion. 157 The meaning of the symbols in YANG tree diagrams are defined in 158 [RFC8340] and [RFC8791]. 160 (D)TLS is used for statements that apply to both Transport Layer 161 Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) 162 [RFC6347]. Specific terms are used for any statement that applies to 163 either protocol alone. 165 3. DOTS Attributes for Faster Block Transmission 167 Section 6.2 of [I-D.ietf-core-new-block] defines the following 168 attributes that are used for congestion control purposes: 170 MAX_PAYLOADS: is the maximum number of payloads that can be 171 transmitted at any one time. 173 NON_MAX_RETRANSMIT: is the maximum number of times a request for the 174 retransmission of missings payloads can occur without a response 175 from the remote peer. By default, NON_MAX_RETRANSMIT has the same 176 value as MAX_RETRANSMIT (Section 4.8 of [RFC7252]). 178 NON_TIMEOUT: is the maximum period of delay between sending sets of 179 MAX_PAYLOADS payloads for the same body. NON_TIMEOUT has the same 180 value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). 182 NON_RECEIVE_TIMEOUT: is the maximum time to wait for a missing 183 payload before requesting retransmission. NON_RECEIVE_TIMEOUT has 184 a value of twice NON_TIMEOUT. 186 NON_PROBING_WAIT: is used to limit the potential wait needed 187 calculated when using PROBING_WAIT. NON_PROBING_WAIT has the same 188 value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of 189 [RFC7252]). 191 NON_PARTIAL_TIMEOUT: is used for expiring partially received bodies. 192 NON_PARTIAL_TIMEOUT has the same value as computed for 193 EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). 195 These attributes are used together with PROBING_RATE parameter which 196 in CoAP indicates the average data rate that must not be exceeded by 197 a CoAP endpoint in sending to a peer endpoint that does not respond. 198 The single body of blocks will be subjected to PROBING_RATE 199 (Section 4.7 of [RFC7252]), not the individual packets. If the wait 200 time between sending bodies that are not being responded to based on 201 PROBING_RATE exceeds NON_PROBING_WAIT, then the gap time is limited 202 to NON_PROBING_WAIT. 204 Except MAX_PAYLOADS, all the aforementioned attributes can be derived 205 from attributes that can be negotiated between DOTS peers as per 206 Section 4.5.2 of [I-D.ietf-dots-rfc8782-bis]. This document augments 207 the "ietf-dots-signal-channel" (dots-signal) DOTS signal YANG module 208 defined in [I-D.ietf-dots-rfc8782-bis] with this additional attribute 209 that can be negotiated between DOTS peers to enable faster 210 transmission: 212 max-payloads: This attribute echoes the MAX_PAYLOADS parameter in 213 [I-D.ietf-core-new-block]. 215 This is an optional attribute. 217 For the sake of more flexible configuration, this document defines 218 also the following attributes: 220 non-max-retransmit: This attribute echoes the NON_MAX_RETRANSMIT 221 parameter in [I-D.ietf-core-new-block]. The default value of this 222 attribute is 'max-retransmit'. Note that DOTS uses a default 223 value of '3' instead of '4' used for the generic CoAP use 224 (Section 4.5.2 of [I-D.ietf-dots-rfc8782-bis]). 226 This is an optional attribute. 228 non-timeout: This attribute echoes the NON_TIMEOUT parameter in 229 [I-D.ietf-core-new-block]. The default value of this attribute is 230 'ack-timeout'. 232 This is an optional attribute. 234 An example of PUT message to convey the configuration parameters for 235 the DOTS signal channel is depicted in Figure 1. In this example, 236 the 'max-payloads' is set to '15' when no mitigation is active, while 237 it is set to '10' when a mitigation is active. The same value is 238 used for both 'non-max-retransmit' and 'non-timeout' in idle and 239 mitigation times. 241 Header: PUT (Code=0.03) 242 Uri-Path: ".well-known" 243 Uri-Path: "dots" 244 Uri-Path: "config" 245 Uri-Path: "sid=123" 246 Content-Format: "application/dots+cbor" 248 { 249 "ietf-dots-signal-channel:signal-config": { 250 "mitigating-config": { 251 "heartbeat-interval": { 252 "current-value": 30 253 }, 254 "missing-hb-allowed": { 255 "current-value": 15 256 }, 257 "probing-rate": { 258 "current-value": 15 259 }, 260 "max-retransmit": { 261 "current-value": 3 262 }, 263 "ack-timeout": { 264 "current-value-decimal": "2.00" 265 }, 266 "ack-random-factor": { 267 "current-value-decimal": "1.50" 268 }, 269 "ietf-dots-fast-trans:max-payloads": { 270 "current-value": 10 271 }, 272 "ietf-dots-fast-trans:non-max-retransmit": { 273 "current-value": 3 274 }, 275 "ietf-dots-fast-trans:non-timeout": { 276 "current-value-decimal": "2.00" 277 } 278 }, 279 "idle-config": { 280 "heartbeat-interval": { 281 "current-value": 0 282 }, 283 "max-retransmit": { 284 "current-value": 3 285 }, 286 "ack-timeout": { 287 "current-value-decimal": "2.00" 288 }, 289 "ack-random-factor": { 290 "current-value-decimal": "1.50" 291 }, 292 "ietf-dots-fast-trans:max-payloads": { 293 "current-value": 15 294 }, 295 "ietf-dots-fast-trans:non-max-retransmit": { 296 "current-value": 3 297 }, 298 "ietf-dots-fast-trans:non-timeout": { 299 "current-value-decimal": "2.00" 300 } 301 } 302 } 303 } 305 Figure 1: Example of PUT to Convey the Configuration Parameters 307 4. DOTS Fast Block Transmission YANG Module 309 4.1. Tree Structure 311 This document defines the YANG module "ietf-dots-fast-trans" 312 (Section 4), which has the following tree structure: 314 module: ietf-dots-fast-trans 316 augment-structure /dots-signal:dots-signal/dots-signal:message-type 317 /dots-signal:signal-config 318 /dots-signal:mitigating-config: 319 +-- max-payloads 320 | +-- (direction)? 321 | | +--:(server-to-client-only) 322 | | +-- max-value? uint16 323 | | +-- min-value? uint16 324 | +-- current-value? uint16 325 +-- non-max-retransmit 326 | +-- (direction)? 327 | | +--:(server-to-client-only) 328 | | +-- max-value? uint16 329 | | +-- min-value? uint16 330 | +-- current-value? uint16 331 +-- non-timeout 332 +-- (direction)? 333 | +--:(server-to-client-only) 334 | +-- max-value-decimal? decimal64 335 | +-- min-value-decimal? decimal64 336 +-- current-value-decimal? decimal64 338 augment-structure /dots-signal:dots-signal/dots-signal:message-type 339 /dots-signal:signal-config/dots-signal:idle-config: 340 +-- max-payloads 341 | +-- (direction)? 342 | | +--:(server-to-client-only) 343 | | +-- max-value? uint16 344 | | +-- min-value? uint16 345 | +-- current-value? uint16 346 +-- non-max-retransmit 347 | +-- (direction)? 348 | | +--:(server-to-client-only) 349 | | +-- max-value? uint16 350 | | +-- min-value? uint16 351 | +-- current-value? uint16 352 +-- non-timeout 353 +-- (direction)? 354 | +--:(server-to-client-only) 355 | +-- max-value-decimal? decimal64 356 | +-- min-value-decimal? decimal64 357 +-- current-value-decimal? decimal64 359 4.2. YANG/JSON Mapping Parameters to CBOR 361 The YANG/JSON mapping parameters to CBOR are listed in Table 2. 363 o Note: Implementers must check that the mapping output provided by 364 their YANG-to-CBOR encoding schemes is aligned with the content of 365 Table 2. 367 +----------------------+------------+------+---------------+--------+ 368 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 369 | | Type | Key | Type & | Type | 370 | | | | Information | | 371 +======================+============+======+===============+========+ 372 | ietf-dots-fast-trans:| container | TBA1 | 5 map | Object | 373 | max-payloads | | | | | 374 +----------------------+------------+------+---------------+--------+ 375 | ietf-dots-fast-trans:| container | TBA2 | 5 map | Object | 376 | non-max-retransmit | | | | | 377 +----------------------+------------+------+---------------+--------+ 378 | ietf-dots-fast-trans:| container | TBA3 | 5 map | Object | 379 | non-timeout | | | | | 380 +----------------------+------------+------+---------------+--------+ 382 Table 2: YANG/JSON Mapping Parameters to CBOR 384 4.3. YANG Module 386 This module uses the data structure extension defined in [RFC8791]. 388 file "ietf-dots-fast-trans@2020-12-02.yang" 389 module ietf-dots-fast-trans { 390 yang-version 1.1; 391 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-fast-trans"; 392 prefix dots-fast; 394 import ietf-dots-signal-channel { 395 prefix dots-signal; 396 reference 397 "RFC YYYY: Distributed Denial-of-Service Open Threat 398 Signaling (DOTS) Signal Channel Specification"; 399 } 400 import ietf-yang-structure-ext { 401 prefix sx; 402 reference 403 "RFC 8791: YANG Data Structure Extensions"; 404 } 406 organization 407 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 408 contact 409 "WG Web: 410 WG List: 412 Author: Mohamed Boucadair 413 ; 415 Author: Jon Shallow 416 "; 417 description 418 "This module contains YANG definitions for the configuration 419 of parameters that can be negotiated between a DOTS client 420 and a DOTS server for faster block transmission. 422 Copyright (c) 2021 IETF Trust and the persons identified as 423 authors of the code. All rights reserved. 425 Redistribution and use in source and binary forms, with or 426 without modification, is permitted pursuant to, and subject 427 to the license terms contained in, the Simplified BSD License 428 set forth in Section 4.c of the IETF Trust's Legal Provisions 429 Relating to IETF Documents 430 (http://trustee.ietf.org/license-info). 432 This version of this YANG module is part of RFC XXXX; see 433 the RFC itself for full legal notices."; 435 revision 2021-01-11 { 436 description 437 "Initial revision."; 438 reference 439 "RFC XXXX: Distributed Denial-of-Service Open Threat 440 Signaling (DOTS) Configuration Attributes 441 for Faster Block Transmission"; 442 } 444 grouping fast-transmission-attributes { 445 description 446 "A set of DOTS signal channel session configuration 447 that are negotiated between DOTS agents when 448 making use of Q-Block1 and Q-Block2 Options."; 449 container max-payloads { 450 description 451 "Indicates the maximum number of payloads that 452 can be transmitted at any one time."; 453 choice direction { 454 description 455 "Indicates the communication direction in which the 456 data nodes can be included."; 457 case server-to-client-only { 458 description 459 "These data nodes appear only in a mitigation message 460 sent from the server to the client."; 461 leaf max-value { 462 type uint16; 463 description 464 "Maximum acceptable max-payloads value."; 465 } 466 leaf min-value { 467 type uint16; 468 description 469 "Minimum acceptable max-payloads value."; 470 } 471 } 472 } 473 leaf current-value { 474 type uint16; 475 default "10"; 476 description 477 "Current max-payloads value."; 478 } 479 } 480 container non-max-retransmit { 481 description 482 "Indicates the the maximum number of times a 483 request for the retransmission of missings payloads 484 can occur without a response from the remote peer."; 485 leaf max-value { 486 type uint16; 487 config false; 488 description 489 "Maximum acceptable non-max-retransmit value."; 490 } 491 leaf min-value { 492 type uint16; 493 config false; 494 description 495 "Minimum acceptable non-max-retransmit value."; 496 } 497 leaf current-value { 498 type uint16; 499 default "3"; 500 description 501 "Current non-max-retransmit value."; 502 } 504 } 505 container non-timeout { 506 description 507 "Indicates the maximum period of delay between 508 sending sets of MAX_PAYLOADS payloads for the same 509 body. By default, this parameter has the same value 510 as ACK_TIMEOUT."; 511 choice direction { 512 description 513 "Indicates the communication direction in which the 514 data nodes can be included."; 515 case server-to-client-only { 516 description 517 "These data nodes appear only in a mitigation message 518 sent from the server to the client."; 519 leaf max-value-decimal { 520 type decimal64 { 521 fraction-digits 2; 522 } 523 units "seconds"; 524 description 525 "Maximum ack-timeout value."; 526 } 527 leaf min-value-decimal { 528 type decimal64 { 529 fraction-digits 2; 530 } 531 units "seconds"; 532 description 533 "Minimum ack-timeout value."; 534 } 535 } 536 } 537 leaf current-value-decimal { 538 type decimal64 { 539 fraction-digits 2; 540 } 541 units "seconds"; 542 default "2"; 543 description 544 "Current ack-timeout value."; 545 } 546 } 547 } 549 sx:augment-structure "/dots-signal:dots-signal" 550 + "/dots-signal:message-type" 551 + "/dots-signal:signal-config" 552 + "/dots-signal:mitigating-config" { 553 description 554 "Indicates DOTS configuration parameters to use for 555 faster transmission when a mitigation is active."; 556 uses fast-transmission-attributes; 557 } 558 sx:augment-structure "/dots-signal:dots-signal" 559 + "/dots-signal:message-type" 560 + "/dots-signal:signal-config" 561 + "/dots-signal:idle-config" { 562 description 563 "Indicates DOTS configuration parameters to use for 564 faster transmission when no mitigation is active."; 565 uses fast-transmission-attributes; 566 } 567 } 568 570 5. IANA Considerations 572 5.1. DOTS Signal Channel CBOR Mappings Registry 574 This specification registers the following parameters in the IANA 575 "DOTS Signal Channel CBOR Key Values" registry [Key-Map]. 577 o Note to the RFC Editor: Please replace TBA1/TBA2/TBA3 with the 578 CBOR keys that are assigned from the 128-255 range. Please update 579 Table 2 accordingly. 581 +----------------------+-------+-------+------------+---------------+ 582 | Parameter Name | CBOR | CBOR | Change | Specification | 583 | | Key | Major | Controller | Document(s) | 584 | | Value | Type | | | 585 +======================+=======+=======+============+===============+ 586 | ietf-dots-fast-trans:| TBA1 | 5 | IESG | [RFCXXXX] | 587 | max-payloads | | | | | 588 +----------------------+-------+-------+------------+---------------+ 589 | ietf-dots-fast-trans:| TBA2 | 5 | IESG | [RFCXXXX] | 590 | non-max-retransmit | | | | | 591 +----------------------+-------+-------+------------+---------------+ 592 | ietf-dots-fast-trans:| TBA3 | 5 | IESG | [RFCXXXX] | 593 | non-timeout | | | | | 594 +----------------------+-------+-------+------------+---------------+ 596 5.2. DOTS Signal Filtering Control YANG Module 598 This document requests IANA to register the following URI in the "ns" 599 subregistry within the "IETF XML Registry" [RFC3688]: 601 URI: urn:ietf:params:xml:ns:yang:ietf-dots-fast-trans 602 Registrant Contact: The IESG. 603 XML: N/A; the requested URI is an XML namespace. 605 This document requests IANA to register the following YANG module in 606 the "YANG Module Names" subregistry [RFC6020] within the "YANG 607 Parameters" registry. 609 Name: ietf-dots-fast-trans 610 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-fast-trans 611 Maintained by IANA: N 612 Prefix: dots-fast 613 Reference: RFC XXXX 615 6. Security Considerations 617 The security considerations for the DOTS signal channel protocol are 618 discussed in Section 11 of [I-D.ietf-dots-rfc8782-bis]. 620 CoAP-specific security considerations are discussed in Section 11 of 621 [I-D.ietf-core-new-block]. 623 This document defines YANG data structures that are meant to be used 624 as an abstract representation in DOTS signal channel messages. As 625 such, the "ietf-dots-fast-trans" module does not introduce any new 626 vulnerabilities beyond those specified above. 628 7. Acknowledgements 630 TBC 632 8. References 634 8.1. Normative References 636 [I-D.ietf-core-new-block] 637 Boucadair, M. and J. Shallow, "Constrained Application 638 Protocol (CoAP) Block-Wise Transfer Options for Faster 639 Transmission", draft-ietf-core-new-block-04 (work in 640 progress), January 2021. 642 [I-D.ietf-dots-rfc8782-bis] 643 Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed 644 Denial-of-Service Open Threat Signaling (DOTS) Signal 645 Channel Specification", draft-ietf-dots-rfc8782-bis-04 646 (work in progress), December 2020. 648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, 650 DOI 10.17487/RFC2119, March 1997, 651 . 653 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 654 DOI 10.17487/RFC3688, January 2004, 655 . 657 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 658 the Network Configuration Protocol (NETCONF)", RFC 6020, 659 DOI 10.17487/RFC6020, October 2010, 660 . 662 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 663 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 664 January 2012, . 666 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 667 Application Protocol (CoAP)", RFC 7252, 668 DOI 10.17487/RFC7252, June 2014, 669 . 671 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 672 the Constrained Application Protocol (CoAP)", RFC 7959, 673 DOI 10.17487/RFC7959, August 2016, 674 . 676 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 677 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 678 May 2017, . 680 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 681 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 682 Application Protocol) over TCP, TLS, and WebSockets", 683 RFC 8323, DOI 10.17487/RFC8323, February 2018, 684 . 686 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 687 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 688 . 690 [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data 691 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 692 June 2020, . 694 8.2. Informative References 696 [I-D.ietf-dots-telemetry] 697 Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., 698 and J. Shallow, "Distributed Denial-of-Service Open Threat 699 Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 700 (work in progress), December 2020. 702 [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", 703 . 706 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 707 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 708 . 710 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 711 Threat Signaling (DOTS) Requirements", RFC 8612, 712 DOI 10.17487/RFC8612, May 2019, 713 . 715 Authors' Addresses 717 Mohamed Boucadair 718 Orange 719 Rennes 35000 720 France 722 Email: mohamed.boucadair@orange.com 724 Jon Shallow 725 United Kingdom 727 Email: supjps-ietf@jpshallow.com