idnits 2.17.1 draft-bosh-dots-quick-blocks-03.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 (June 29, 2021) is 1030 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 729, 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: December 31, 2021 June 29, 2021 7 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 8 Channel Configuration Attributes for Robust Block Transmission 9 draft-bosh-dots-quick-blocks-03 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 robust and 16 faster 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 December 31, 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 Robust 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 as the returning ACK packets may not get through. 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 additional 118 CoAP attributes that are used for the guards. 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, the attributes listed in 136 Table 1 are not supported. This document defines new DOTS signal 137 channel attributes that are meant to customize the configuration of 138 robust 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 Robust 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. By default, 184 NON_RECEIVE_TIMEOUT has 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 201 calculated using on PROBING_RATE exceeds NON_PROBING_WAIT, then the 202 gap time is limited 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 robust and 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]) for max-transmit. 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-robust-trans:max-payloads": { 279 "current-value": 10 280 }, 281 "ietf-dots-robust-trans:non-max-retransmit": { 282 "current-value": 3 283 }, 284 "ietf-dots-robust-trans:non-timeout": { 285 "current-value-decimal": "2.00" 286 }, 287 "ietf-dots-robust-trans:non-probing-wait": { 288 "current-value-decimal": "247.00" 289 }, 290 "ietf-dots-robust-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-robust-trans:max-payloads": { 308 "current-value": 15 309 }, 310 "ietf-dots-robust-trans:non-max-retransmit": { 311 "current-value": 3 312 }, 313 "ietf-dots-robust-trans:non-timeout": { 314 "current-value-decimal": "2.00" 315 }, 316 "ietf-dots-robust-trans:non-probing-wait": { 317 "current-value-decimal": "247.00" 318 }, 319 "ietf-dots-robust-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-robust-trans" 332 (Section 4), which has the following tree structure: 334 module: ietf-dots-robust-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-robust- | container | TBA1 | 5 map | Object | 417 | trans:max-payloads | | | | | 418 +----------------------+------------+------+---------------+--------+ 419 | ietf-dots-robust- | container | TBA2 | 5 map | Object | 420 | trans:non-max- | | | | | 421 | retransmit | | | | | 422 +----------------------+------------+------+---------------+--------+ 423 | ietf-dots-robust- | container | TBA3 | 5 map | Object | 424 | trans:non-timeout | | | | | 425 +----------------------+------------+------+---------------+--------+ 426 | ietf-dots-robust- | container | TBA4 | 5 map | Object | 427 |trans:non-probing-wait| | | | | 428 +----------------------+------------+------+---------------+--------+ 429 | ietf-dots-robust- | container | TBA5 | 5 map | Object | 430 |trans:non-partial-wait| | | | | 431 +----------------------+------------+------+---------------+--------+ 433 Table 2: YANG/JSON Mapping Parameters to CBOR 435 4.3. YANG Module 437 This module uses the data structure extension defined in [RFC8791]. 439 file "ietf-dots-robust-trans@2020-05-04.yang" 440 module ietf-dots-robust-trans { 441 yang-version 1.1; 442 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans"; 443 prefix dots-robust; 445 import ietf-dots-signal-channel { 446 prefix dots-signal; 447 reference 448 "RFC YYYY: Distributed Denial-of-Service Open Threat 449 Signaling (DOTS) Signal Channel Specification"; 450 } 451 import ietf-yang-structure-ext { 452 prefix sx; 453 reference 454 "RFC 8791: YANG Data Structure Extensions"; 455 } 457 organization 458 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 460 contact 461 "WG Web: 462 WG List: 464 Author: Mohamed Boucadair 465 ; 467 Author: Jon Shallow 468 "; 469 description 470 "This module contains YANG definitions for the configuration 471 of parameters that can be negotiated between a DOTS client 472 and a DOTS server for robust block transmission. 474 Copyright (c) 2021 IETF Trust and the persons identified as 475 authors of the code. All rights reserved. 477 Redistribution and use in source and binary forms, with or 478 without modification, is permitted pursuant to, and subject 479 to the license terms contained in, the Simplified BSD License 480 set forth in Section 4.c of the IETF Trust's Legal Provisions 481 Relating to IETF Documents 482 (http://trustee.ietf.org/license-info). 484 This version of this YANG module is part of RFC XXXX; see 485 the RFC itself for full legal notices."; 487 revision 2021-05-04 { 488 description 489 "Initial revision."; 490 reference 491 "RFC XXXX: Distributed Denial-of-Service Open Threat 492 Signaling (DOTS) Configuration Attributes 493 for Robust Block Transmission"; 494 } 496 grouping robust-transmission-attributes { 497 description 498 "A set of DOTS signal channel session configuration 499 that are negotiated between DOTS agents when 500 making use of Q-Block1 and Q-Block2 Options."; 501 container max-payloads { 502 description 503 "Indicates the maximum number of payloads that 504 can be transmitted at any one time."; 505 choice direction { 506 description 507 "Indicates the communication direction in which the 508 data nodes can be included."; 509 case server-to-client-only { 510 description 511 "These data nodes appear only in a mitigation message 512 sent from the server to the client."; 513 leaf max-value { 514 type uint16; 515 description 516 "Maximum acceptable max-payloads value."; 517 } 518 leaf min-value { 519 type uint16; 520 description 521 "Minimum acceptable max-payloads value."; 522 } 523 } 524 } 525 leaf current-value { 526 type uint16; 527 default "10"; 528 description 529 "Current max-payloads value."; 530 } 531 } 532 container non-max-retransmit { 533 description 534 "Indicates the the maximum number of times a 535 request for the retransmission of missings payloads 536 can occur without a response from the remote peer."; 537 leaf max-value { 538 type uint16; 539 config false; 540 description 541 "Maximum acceptable non-max-retransmit value."; 542 } 543 leaf min-value { 544 type uint16; 545 config false; 546 description 547 "Minimum acceptable non-max-retransmit value."; 548 } 549 leaf current-value { 550 type uint16; 551 default "3"; 552 description 553 "Current non-max-retransmit value."; 554 } 555 } 556 container non-timeout { 557 description 558 "Indicates the maximum period of delay between 559 sending sets of MAX_PAYLOADS payloads for the same 560 body. By default, this parameter has the same value 561 as ACK_TIMEOUT."; 562 choice direction { 563 description 564 "Indicates the communication direction in which the 565 data nodes can be included."; 566 case server-to-client-only { 567 description 568 "These data nodes appear only in a mitigation message 569 sent from the server to the client."; 570 leaf max-value-decimal { 571 type decimal64 { 572 fraction-digits 2; 573 } 574 units "seconds"; 575 description 576 "Maximum ack-timeout value."; 577 } 578 leaf min-value-decimal { 579 type decimal64 { 580 fraction-digits 2; 581 } 582 units "seconds"; 583 description 584 "Minimum ack-timeout value."; 585 } 586 } 587 } 588 leaf current-value-decimal { 589 type decimal64 { 590 fraction-digits 2; 591 } 592 units "seconds"; 593 default "2"; 594 description 595 "Current ack-timeout value."; 596 } 597 } 598 container non-probing-wait { 599 description 600 "Is used to limit the potential wait needed calculated 601 when using probing-rate."; 602 choice direction { 603 description 604 "Indicates the communication direction in which the 605 data nodes can be included."; 606 case server-to-client-only { 607 description 608 "These data nodes appear only in a mitigation message 609 sent from the server to the client."; 610 leaf max-value-decimal { 611 type decimal64 { 612 fraction-digits 2; 613 } 614 units "seconds"; 615 description 616 "Maximum non-probing-wait value."; 617 } 618 leaf min-value-decimal { 619 type decimal64 { 620 fraction-digits 2; 621 } 622 units "seconds"; 623 description 624 "Minimum non-probing-wait value."; 625 } 626 } 627 } 628 leaf current-value-decimal { 629 type decimal64 { 630 fraction-digits 2; 631 } 632 units "seconds"; 633 default "247"; 634 description 635 "Current non-probing-wait value."; 636 } 637 } 638 container non-partial-wait { 639 description 640 "Is used for expiring partially received bodies."; 641 choice direction { 642 description 643 "Indicates the communication direction in which the 644 data nodes can be included."; 645 case server-to-client-only { 646 description 647 "These data nodes appear only in a mitigation message 648 sent from the server to the client."; 649 leaf max-value-decimal { 650 type decimal64 { 651 fraction-digits 2; 653 } 654 units "seconds"; 655 description 656 "Maximum non-partial-wait value."; 657 } 658 leaf min-value-decimal { 659 type decimal64 { 660 fraction-digits 2; 661 } 662 units "seconds"; 663 description 664 "Minimum non-partial-wait value."; 665 } 666 } 667 } 668 leaf current-value-decimal { 669 type decimal64 { 670 fraction-digits 2; 671 } 672 units "seconds"; 673 default "247"; 674 description 675 "Current non-partial-wait value."; 676 } 677 } 678 } 680 sx:augment-structure "/dots-signal:dots-signal" 681 + "/dots-signal:message-type" 682 + "/dots-signal:signal-config" 683 + "/dots-signal:mitigating-config" { 684 description 685 "Indicates DOTS configuration parameters to use for 686 robust transmission when a mitigation is active."; 687 uses robust-transmission-attributes; 688 } 689 sx:augment-structure "/dots-signal:dots-signal" 690 + "/dots-signal:message-type" 691 + "/dots-signal:signal-config" 692 + "/dots-signal:idle-config" { 693 description 694 "Indicates DOTS configuration parameters to use for 695 robust transmission when no mitigation is active."; 696 uses robust-transmission-attributes; 697 } 698 } 699 701 5. IANA Considerations 703 5.1. DOTS Signal Channel CBOR Mappings Registry 705 This specification registers the following parameters in the IANA 706 "DOTS Signal Channel CBOR Key Values" registry [Key-Map]. 708 o Note to the RFC Editor: Please replace TBA1/TBA2/TBA3 with the 709 CBOR keys that are assigned from the 128-255 range. Please update 710 Table 2 accordingly. 712 +------------------------+-------+-------+------------+---------------+ 713 | Parameter Name | CBOR | CBOR | Change | Specification | 714 | | Key | Major | Controller | Document(s) | 715 | | Value | Type | | | 716 +========================+=======+=======+============+===============+ 717 | ietf-dots-robust-trans:| TBA1 | 5 | IESG | [RFCXXXX] | 718 | max-payloads | | | | | 719 +------------------------+-------+-------+------------+---------------+ 720 | ietf-dots-robust-trans:| TBA2 | 5 | IESG | [RFCXXXX] | 721 | non-max-retransmit | | | | | 722 +------------------------+-------+-------+------------+---------------+ 723 | ietf-dots-robust-trans:| TBA3 | 5 | IESG | [RFCXXXX] | 724 | non-timeout | | | | | 725 +------------------------+-------+-------+------------+---------------+ 726 | ietf-dots-robust-trans:| TBA4 | 5 | IESG | [RFCXXXX] | 727 | non-probing-wait | | | | | 728 +------------------------+-------+-------+------------+---------------+ 729 | ietf-dots-robust-trans:| TBA5 | 5 | IESG | [RFCXXXX] | 730 | non-partial-wait | | | | | 731 +------------------------+-------+-------+------------+---------------+ 733 5.2. DOTS Signal Filtering Control YANG Module 735 This document requests IANA to register the following URI in the "ns" 736 subregistry within the "IETF XML Registry" [RFC3688]: 738 URI: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans 739 Registrant Contact: The IESG. 740 XML: N/A; the requested URI is an XML namespace. 742 This document requests IANA to register the following YANG module in 743 the "YANG Module Names" subregistry [RFC6020] within the "YANG 744 Parameters" registry. 746 Name: ietf-dots-robust-trans 747 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans 748 Maintained by IANA: N 749 Prefix: dots-robust 750 Reference: RFC XXXX 752 6. Security Considerations 754 The security considerations for the DOTS signal channel protocol are 755 discussed in Section 11 of [I-D.ietf-dots-rfc8782-bis]. 757 CoAP-specific security considerations are discussed in Section 11 of 758 [I-D.ietf-core-new-block]. 760 This document defines YANG data structures that are meant to be used 761 as an abstract representation in DOTS signal channel messages. As 762 such, the "ietf-dots-robust-trans" module does not introduce any new 763 vulnerabilities beyond those specified above. 765 7. Acknowledgements 767 TBC 769 8. References 771 8.1. Normative References 773 [I-D.ietf-core-new-block] 774 Boucadair, M. and J. Shallow, "Constrained Application 775 Protocol (CoAP) Block-Wise Transfer Options for Faster 776 Transmission", draft-ietf-core-new-block-11 (work in 777 progress), April 2021. 779 [I-D.ietf-dots-rfc8782-bis] 780 Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed 781 Denial-of-Service Open Threat Signaling (DOTS) Signal 782 Channel Specification", draft-ietf-dots-rfc8782-bis-06 783 (work in progress), March 2021. 785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 786 Requirement Levels", BCP 14, RFC 2119, 787 DOI 10.17487/RFC2119, March 1997, 788 . 790 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 791 DOI 10.17487/RFC3688, January 2004, 792 . 794 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 795 the Network Configuration Protocol (NETCONF)", RFC 6020, 796 DOI 10.17487/RFC6020, October 2010, 797 . 799 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 800 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 801 January 2012, . 803 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 804 Application Protocol (CoAP)", RFC 7252, 805 DOI 10.17487/RFC7252, June 2014, 806 . 808 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 809 the Constrained Application Protocol (CoAP)", RFC 7959, 810 DOI 10.17487/RFC7959, August 2016, 811 . 813 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 814 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 815 May 2017, . 817 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 818 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 819 Application Protocol) over TCP, TLS, and WebSockets", 820 RFC 8323, DOI 10.17487/RFC8323, February 2018, 821 . 823 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 824 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 825 . 827 [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data 828 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 829 June 2020, . 831 8.2. Informative References 833 [I-D.ietf-dots-telemetry] 834 Boucadair, M., Reddy, T., Doron, E., Chen, M., and J. 835 Shallow, "Distributed Denial-of-Service Open Threat 836 Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 837 (work in progress), December 2020. 839 [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", 840 . 843 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 844 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 845 . 847 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 848 Threat Signaling (DOTS) Requirements", RFC 8612, 849 DOI 10.17487/RFC8612, May 2019, 850 . 852 Authors' Addresses 854 Mohamed Boucadair 855 Orange 856 Rennes 35000 857 France 859 Email: mohamed.boucadair@orange.com 861 Jon Shallow 862 United Kingdom 864 Email: supjps-ietf@jpshallow.com