idnits 2.17.1 draft-bosh-dots-quick-blocks-02.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 (May 4, 2021) is 1087 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 727, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-core-new-block-11 == Outdated reference: A later version (-08) exists of draft-ietf-dots-rfc8782-bis-06 ** 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: November 5, 2021 May 4, 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-02 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 November 5, 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 . . . . . . . . . . . . . . . . . . . . . 8 59 4.2. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . 9 60 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 10 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 62 5.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 16 63 5.2. DOTS Signal Filtering Control YANG Module . . . . . . . . 16 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 68 8.2. Informative References . . . . . . . . . . . . . . . . . 18 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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. By default, NON_PROBING_WAIT 188 has the same value as EXCHANGE_LIFETIME (Section 4.8.2 of 189 [RFC7252]). 191 NON_PARTIAL_TIMEOUT: is used for expiring partially received bodies. 192 By default, NON_PARTIAL_TIMEOUT has the same value as 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 This document augments the "ietf-dots-signal-channel" (dots-signal) 205 DOTS signal YANG module defined in [I-D.ietf-dots-rfc8782-bis] with 206 these additional attributes that can be negotiated between DOTS peers 207 to enable faster transmission: 209 max-payloads: This attribute echoes the MAX_PAYLOADS parameter in 210 [I-D.ietf-core-new-block]. 212 This is an optional attribute. 214 For the sake of more flexible configuration, this document defines 215 also the following attributes: 217 non-max-retransmit: This attribute echoes the NON_MAX_RETRANSMIT 218 parameter in [I-D.ietf-core-new-block]. The default value of this 219 attribute is 'max-retransmit'. Note that DOTS uses a default 220 value of '3' instead of '4' used for the generic CoAP use 221 (Section 4.5.2 of [I-D.ietf-dots-rfc8782-bis]). 223 This is an optional attribute. 225 non-timeout: This attribute echoes the NON_TIMEOUT parameter in 226 [I-D.ietf-core-new-block]. The default value of this attribute is 227 'ack-timeout'. 229 This is an optional attribute. 231 non-probing-wait: This attribute echoes the NON_PROBING_WAIT 232 parameter in [I-D.ietf-core-new-block]. The default value of this 233 attribute is 247s. 235 This is an optional attribute. 237 non-partial-timeout: This attribute echoes the NON_PARTIAL_TIMEOUT 238 parameter in [I-D.ietf-core-new-block]. The default value of this 239 attribute is 274s. 241 This is an optional attribute. 243 An example of PUT message to convey the configuration parameters for 244 the DOTS signal channel is depicted in Figure 1. In this example, 245 the 'max-payloads' is set to '15' when no mitigation is active, while 246 it is set to '10' when a mitigation is active. The same value is 247 used for both 'non-max-retransmit' and 'non-timeout' in idle and 248 mitigation times. 250 Header: PUT (Code=0.03) 251 Uri-Path: ".well-known" 252 Uri-Path: "dots" 253 Uri-Path: "config" 254 Uri-Path: "sid=123" 255 Content-Format: "application/dots+cbor" 257 { 258 "ietf-dots-signal-channel:signal-config": { 259 "mitigating-config": { 260 "heartbeat-interval": { 261 "current-value": 30 262 }, 263 "missing-hb-allowed": { 264 "current-value": 15 265 }, 266 "probing-rate": { 267 "current-value": 15 268 }, 269 "max-retransmit": { 270 "current-value": 3 271 }, 272 "ack-timeout": { 273 "current-value-decimal": "2.00" 274 }, 275 "ack-random-factor": { 276 "current-value-decimal": "1.50" 277 }, 278 "ietf-dots-fast-trans:max-payloads": { 279 "current-value": 10 280 }, 281 "ietf-dots-fast-trans:non-max-retransmit": { 282 "current-value": 3 283 }, 284 "ietf-dots-fast-trans:non-timeout": { 285 "current-value-decimal": "2.00" 286 }, 287 "ietf-dots-fast-trans:non-probing-wait": { 288 "current-value-decimal": "247.00" 289 }, 290 "ietf-dots-fast-trans:non-partial-wait": { 291 "current-value-decimal": "247.00" 292 } 293 }, 294 "idle-config": { 295 "heartbeat-interval": { 296 "current-value": 0 297 }, 298 "max-retransmit": { 299 "current-value": 3 300 }, 301 "ack-timeout": { 302 "current-value-decimal": "2.00" 303 }, 304 "ack-random-factor": { 305 "current-value-decimal": "1.50" 306 }, 307 "ietf-dots-fast-trans:max-payloads": { 308 "current-value": 15 309 }, 310 "ietf-dots-fast-trans:non-max-retransmit": { 311 "current-value": 3 312 }, 313 "ietf-dots-fast-trans:non-timeout": { 314 "current-value-decimal": "2.00" 315 }, 316 "ietf-dots-fast-trans:non-probing-wait": { 317 "current-value-decimal": "247.00" 318 }, 319 "ietf-dots-fast-trans:non-partial-wait": { 320 "current-value-decimal": "247.00" 321 } 322 } 323 } 324 } 326 Figure 1: Example of PUT to Convey the Configuration Parameters 328 4. DOTS Fast Block Transmission YANG Module 329 4.1. Tree Structure 331 This document defines the YANG module "ietf-dots-fast-trans" 332 (Section 4), which has the following tree structure: 334 module: ietf-dots-fast-trans 336 augment-structure /dots-signal:dots-signal/dots-signal:message-type 337 /dots-signal:signal-config 338 /dots-signal:mitigating-config: 339 +-- max-payloads 340 | +-- (direction)? 341 | | +--:(server-to-client-only) 342 | | +-- max-value? uint16 343 | | +-- min-value? uint16 344 | +-- current-value? uint16 345 +-- non-max-retransmit 346 | +-- (direction)? 347 | | +--:(server-to-client-only) 348 | | +-- max-value? uint16 349 | | +-- min-value? uint16 350 | +-- current-value? uint16 351 +-- non-timeout 352 | +-- (direction)? 353 | | +--:(server-to-client-only) 354 | | +-- max-value-decimal? decimal64 355 | | +-- min-value-decimal? decimal64 356 | +-- current-value-decimal? decimal64 357 +-- non-probing-wait 358 | +-- (direction)? 359 | | +--:(server-to-client-only) 360 | | +-- max-value-decimal? decimal64 361 | | +-- min-value-decimal? decimal64 362 | +-- current-value-decimal? decimal64 363 +-- non-partial-wait: 364 +-- (direction)? 365 | +--:(server-to-client-only) 366 | +-- max-value-decimal? decimal64 367 | +-- min-value-decimal? decimal64 368 +-- current-value-decimal? decimal64 370 augment-structure /dots-signal:dots-signal/dots-signal:message-type 371 /dots-signal:signal-config/dots-signal:idle-config: 372 +-- max-payloads 373 | +-- (direction)? 374 | | +--:(server-to-client-only) 375 | | +-- max-value? uint16 376 | | +-- min-value? uint16 377 | +-- current-value? uint16 378 +-- non-max-retransmit 379 | +-- (direction)? 380 | | +--:(server-to-client-only) 381 | | +-- max-value? uint16 382 | | +-- min-value? uint16 383 | +-- current-value? uint16 384 +-- non-timeout 385 | +-- (direction)? 386 | | +--:(server-to-client-only) 387 | | +-- max-value-decimal? decimal64 388 | | +-- min-value-decimal? decimal64 389 | +-- current-value-decimal? decimal64 390 +-- non-probing-wait 391 | +-- (direction)? 392 | | +--:(server-to-client-only) 393 | | +-- max-value-decimal? decimal64 394 | | +-- min-value-decimal? decimal64 395 | +-- current-value-decimal? decimal64 396 +-- non-partial-wait: 397 +-- (direction)? 398 | +--:(server-to-client-only) 399 | +-- max-value-decimal? decimal64 400 | +-- min-value-decimal? decimal64 401 +-- current-value-decimal? decimal64 403 4.2. YANG/JSON Mapping Parameters to CBOR 405 The YANG/JSON mapping parameters to CBOR are listed in Table 2. 407 o Note: Implementers must check that the mapping output provided by 408 their YANG-to-CBOR encoding schemes is aligned with the content of 409 Table 2. 411 +----------------------+------------+------+---------------+--------+ 412 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 413 | | Type | Key | Type & | Type | 414 | | | | Information | | 415 +======================+============+======+===============+========+ 416 | ietf-dots-fast-trans:| container | TBA1 | 5 map | Object | 417 | max-payloads | | | | | 418 +----------------------+------------+------+---------------+--------+ 419 | ietf-dots-fast-trans:| container | TBA2 | 5 map | Object | 420 | non-max-retransmit | | | | | 421 +----------------------+------------+------+---------------+--------+ 422 | ietf-dots-fast-trans:| container | TBA3 | 5 map | Object | 423 | non-timeout | | | | | 424 +----------------------+------------+------+---------------+--------+ 425 | ietf-dots-fast-trans:| container | TBA4 | 5 map | Object | 426 | non-probing-wait | | | | | 427 +----------------------+------------+------+---------------+--------+ 428 | ietf-dots-fast-trans:| container | TBA5 | 5 map | Object | 429 | non-partial-wait | | | | | 430 +----------------------+------------+------+---------------+--------+ 432 Table 2: YANG/JSON Mapping Parameters to CBOR 434 4.3. YANG Module 436 This module uses the data structure extension defined in [RFC8791]. 438 file "ietf-dots-fast-trans@2020-05-04.yang" 439 module ietf-dots-fast-trans { 440 yang-version 1.1; 441 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-fast-trans"; 442 prefix dots-fast; 444 import ietf-dots-signal-channel { 445 prefix dots-signal; 446 reference 447 "RFC YYYY: Distributed Denial-of-Service Open Threat 448 Signaling (DOTS) Signal Channel Specification"; 449 } 450 import ietf-yang-structure-ext { 451 prefix sx; 452 reference 453 "RFC 8791: YANG Data Structure Extensions"; 454 } 456 organization 457 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 458 contact 459 "WG Web: 460 WG List: 462 Author: Mohamed Boucadair 463 ; 465 Author: Jon Shallow 466 "; 467 description 468 "This module contains YANG definitions for the configuration 469 of parameters that can be negotiated between a DOTS client 470 and a DOTS server for faster block transmission. 472 Copyright (c) 2021 IETF Trust and the persons identified as 473 authors of the code. All rights reserved. 475 Redistribution and use in source and binary forms, with or 476 without modification, is permitted pursuant to, and subject 477 to the license terms contained in, the Simplified BSD License 478 set forth in Section 4.c of the IETF Trust's Legal Provisions 479 Relating to IETF Documents 480 (http://trustee.ietf.org/license-info). 482 This version of this YANG module is part of RFC XXXX; see 483 the RFC itself for full legal notices."; 485 revision 2021-05-04 { 486 description 487 "Initial revision."; 488 reference 489 "RFC XXXX: Distributed Denial-of-Service Open Threat 490 Signaling (DOTS) Configuration Attributes 491 for Faster Block Transmission"; 492 } 494 grouping fast-transmission-attributes { 495 description 496 "A set of DOTS signal channel session configuration 497 that are negotiated between DOTS agents when 498 making use of Q-Block1 and Q-Block2 Options."; 499 container max-payloads { 500 description 501 "Indicates the maximum number of payloads that 502 can be transmitted at any one time."; 503 choice direction { 504 description 505 "Indicates the communication direction in which the 506 data nodes can be included."; 508 case server-to-client-only { 509 description 510 "These data nodes appear only in a mitigation message 511 sent from the server to the client."; 512 leaf max-value { 513 type uint16; 514 description 515 "Maximum acceptable max-payloads value."; 516 } 517 leaf min-value { 518 type uint16; 519 description 520 "Minimum acceptable max-payloads value."; 521 } 522 } 523 } 524 leaf current-value { 525 type uint16; 526 default "10"; 527 description 528 "Current max-payloads value."; 529 } 530 } 531 container non-max-retransmit { 532 description 533 "Indicates the the maximum number of times a 534 request for the retransmission of missings payloads 535 can occur without a response from the remote peer."; 536 leaf max-value { 537 type uint16; 538 config false; 539 description 540 "Maximum acceptable non-max-retransmit value."; 541 } 542 leaf min-value { 543 type uint16; 544 config false; 545 description 546 "Minimum acceptable non-max-retransmit value."; 547 } 548 leaf current-value { 549 type uint16; 550 default "3"; 551 description 552 "Current non-max-retransmit value."; 553 } 554 } 555 container non-timeout { 556 description 557 "Indicates the maximum period of delay between 558 sending sets of MAX_PAYLOADS payloads for the same 559 body. By default, this parameter has the same value 560 as ACK_TIMEOUT."; 561 choice direction { 562 description 563 "Indicates the communication direction in which the 564 data nodes can be included."; 565 case server-to-client-only { 566 description 567 "These data nodes appear only in a mitigation message 568 sent from the server to the client."; 569 leaf max-value-decimal { 570 type decimal64 { 571 fraction-digits 2; 572 } 573 units "seconds"; 574 description 575 "Maximum ack-timeout value."; 576 } 577 leaf min-value-decimal { 578 type decimal64 { 579 fraction-digits 2; 580 } 581 units "seconds"; 582 description 583 "Minimum ack-timeout value."; 584 } 585 } 586 } 587 leaf current-value-decimal { 588 type decimal64 { 589 fraction-digits 2; 590 } 591 units "seconds"; 592 default "2"; 593 description 594 "Current ack-timeout value."; 595 } 596 } 597 container non-probing-wait { 598 description 599 "Is used to limit the potential wait needed calculated 600 when using probing-rate."; 601 choice direction { 602 description 603 "Indicates the communication direction in which the 604 data nodes can be included."; 605 case server-to-client-only { 606 description 607 "These data nodes appear only in a mitigation message 608 sent from the server to the client."; 609 leaf max-value-decimal { 610 type decimal64 { 611 fraction-digits 2; 612 } 613 units "seconds"; 614 description 615 "Maximum non-probing-wait value."; 616 } 617 leaf min-value-decimal { 618 type decimal64 { 619 fraction-digits 2; 620 } 621 units "seconds"; 622 description 623 "Minimum non-probing-wait value."; 624 } 625 } 626 } 627 leaf current-value-decimal { 628 type decimal64 { 629 fraction-digits 2; 630 } 631 units "seconds"; 632 default "247"; 633 description 634 "Current non-probing-wait value."; 635 } 636 } 637 container non-partial-wait { 638 description 639 "Is used for expiring partially received bodies."; 640 choice direction { 641 description 642 "Indicates the communication direction in which the 643 data nodes can be included."; 644 case server-to-client-only { 645 description 646 "These data nodes appear only in a mitigation message 647 sent from the server to the client."; 648 leaf max-value-decimal { 649 type decimal64 { 650 fraction-digits 2; 651 } 652 units "seconds"; 653 description 654 "Maximum non-partial-wait value."; 655 } 656 leaf min-value-decimal { 657 type decimal64 { 658 fraction-digits 2; 659 } 660 units "seconds"; 661 description 662 "Minimum non-partial-wait value."; 663 } 664 } 665 } 666 leaf current-value-decimal { 667 type decimal64 { 668 fraction-digits 2; 669 } 670 units "seconds"; 671 default "247"; 672 description 673 "Current non-partial-wait value."; 674 } 675 } 676 } 678 sx:augment-structure "/dots-signal:dots-signal" 679 + "/dots-signal:message-type" 680 + "/dots-signal:signal-config" 681 + "/dots-signal:mitigating-config" { 682 description 683 "Indicates DOTS configuration parameters to use for 684 faster transmission when a mitigation is active."; 685 uses fast-transmission-attributes; 686 } 687 sx:augment-structure "/dots-signal:dots-signal" 688 + "/dots-signal:message-type" 689 + "/dots-signal:signal-config" 690 + "/dots-signal:idle-config" { 691 description 692 "Indicates DOTS configuration parameters to use for 693 faster transmission when no mitigation is active."; 694 uses fast-transmission-attributes; 695 } 696 } 697 699 5. IANA Considerations 701 5.1. DOTS Signal Channel CBOR Mappings Registry 703 This specification registers the following parameters in the IANA 704 "DOTS Signal Channel CBOR Key Values" registry [Key-Map]. 706 o Note to the RFC Editor: Please replace TBA1/TBA2/TBA3 with the 707 CBOR keys that are assigned from the 128-255 range. Please update 708 Table 2 accordingly. 710 +----------------------+-------+-------+------------+---------------+ 711 | Parameter Name | CBOR | CBOR | Change | Specification | 712 | | Key | Major | Controller | Document(s) | 713 | | Value | Type | | | 714 +======================+=======+=======+============+===============+ 715 | ietf-dots-fast-trans:| TBA1 | 5 | IESG | [RFCXXXX] | 716 | max-payloads | | | | | 717 +----------------------+-------+-------+------------+---------------+ 718 | ietf-dots-fast-trans:| TBA2 | 5 | IESG | [RFCXXXX] | 719 | non-max-retransmit | | | | | 720 +----------------------+-------+-------+------------+---------------+ 721 | ietf-dots-fast-trans:| TBA3 | 5 | IESG | [RFCXXXX] | 722 | non-timeout | | | | | 723 +----------------------+-------+-------+------------+---------------+ 724 | ietf-dots-fast-trans:| TBA4 | 5 | IESG | [RFCXXXX] | 725 | non-probing-wait | | | | | 726 +----------------------+-------+-------+------------+---------------+ 727 | ietf-dots-fast-trans:| TBA5 | 5 | IESG | [RFCXXXX] | 728 | non-partial-wait | | | | | 729 +----------------------+-------+-------+------------+---------------+ 731 5.2. DOTS Signal Filtering Control YANG Module 733 This document requests IANA to register the following URI in the "ns" 734 subregistry within the "IETF XML Registry" [RFC3688]: 736 URI: urn:ietf:params:xml:ns:yang:ietf-dots-fast-trans 737 Registrant Contact: The IESG. 738 XML: N/A; the requested URI is an XML namespace. 740 This document requests IANA to register the following YANG module in 741 the "YANG Module Names" subregistry [RFC6020] within the "YANG 742 Parameters" registry. 744 Name: ietf-dots-fast-trans 745 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-fast-trans 746 Maintained by IANA: N 747 Prefix: dots-fast 748 Reference: RFC XXXX 750 6. Security Considerations 752 The security considerations for the DOTS signal channel protocol are 753 discussed in Section 11 of [I-D.ietf-dots-rfc8782-bis]. 755 CoAP-specific security considerations are discussed in Section 11 of 756 [I-D.ietf-core-new-block]. 758 This document defines YANG data structures that are meant to be used 759 as an abstract representation in DOTS signal channel messages. As 760 such, the "ietf-dots-fast-trans" module does not introduce any new 761 vulnerabilities beyond those specified above. 763 7. Acknowledgements 765 TBC 767 8. References 769 8.1. Normative References 771 [I-D.ietf-core-new-block] 772 Boucadair, M. and J. Shallow, "Constrained Application 773 Protocol (CoAP) Block-Wise Transfer Options for Faster 774 Transmission", draft-ietf-core-new-block-11 (work in 775 progress), April 2021. 777 [I-D.ietf-dots-rfc8782-bis] 778 Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed 779 Denial-of-Service Open Threat Signaling (DOTS) Signal 780 Channel Specification", draft-ietf-dots-rfc8782-bis-06 781 (work in progress), March 2021. 783 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 784 Requirement Levels", BCP 14, RFC 2119, 785 DOI 10.17487/RFC2119, March 1997, 786 . 788 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 789 DOI 10.17487/RFC3688, January 2004, 790 . 792 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 793 the Network Configuration Protocol (NETCONF)", RFC 6020, 794 DOI 10.17487/RFC6020, October 2010, 795 . 797 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 798 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 799 January 2012, . 801 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 802 Application Protocol (CoAP)", RFC 7252, 803 DOI 10.17487/RFC7252, June 2014, 804 . 806 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 807 the Constrained Application Protocol (CoAP)", RFC 7959, 808 DOI 10.17487/RFC7959, August 2016, 809 . 811 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 812 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 813 May 2017, . 815 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 816 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 817 Application Protocol) over TCP, TLS, and WebSockets", 818 RFC 8323, DOI 10.17487/RFC8323, February 2018, 819 . 821 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 822 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 823 . 825 [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data 826 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 827 June 2020, . 829 8.2. Informative References 831 [I-D.ietf-dots-telemetry] 832 Boucadair, M., Reddy, T., Doron, E., Chen, M., and J. 833 Shallow, "Distributed Denial-of-Service Open Threat 834 Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 835 (work in progress), December 2020. 837 [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", 838 . 841 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 842 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 843 . 845 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 846 Threat Signaling (DOTS) Requirements", RFC 8612, 847 DOI 10.17487/RFC8612, May 2019, 848 . 850 Authors' Addresses 852 Mohamed Boucadair 853 Orange 854 Rennes 35000 855 France 857 Email: mohamed.boucadair@orange.com 859 Jon Shallow 860 United Kingdom 862 Email: supjps-ietf@jpshallow.com