idnits 2.17.00 (12 Aug 2021) /tmp/idnits31671/draft-ietf-dots-robust-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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (11 February 2022) is 92 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 853, but not defined == Outdated reference: draft-ietf-core-new-block has been published as RFC 9177 == Outdated reference: A later version (-25) exists of draft-ietf-dots-telemetry-23 Summary: 0 errors (**), 0 flaws (~~), 5 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: 15 August 2022 11 February 2022 7 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 8 Channel Configuration Attributes for Robust Block Transmission 9 draft-ietf-dots-robust-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 CoAP Options. These options enable robust 16 and faster transmission rates for large amounts of data with less 17 packet interchanges as well as supporting faster recovery should any 18 of the blocks get lost in transmission. 20 This document defines a YANG data model for representing these new 21 DOTS signal channel configuration parameters. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 15 August 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. DOTS Attributes for Robust Block Transmission . . . . . . . . 4 59 4. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 10 60 5. DOTS Robust Block Transmission YANG Module . . . . . . . . . 11 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 62 6.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 18 63 6.2. DOTS Robust Block Transmission YANG Module . . . . . . . 19 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 68 9.2. Informative References . . . . . . . . . . . . . . . . . 21 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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. The block- 77 wise transfer [RFC7959] introduced the CoAP Block1 and Block2 Options 78 to handle data records that cannot fit in a single IP packet, so not 79 having to rely on IP fragmentation. The block-wise transfer was 80 further updated by [RFC8323] for use over TCP, 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. 97 However, such a recommendation does not work with a flooded pipe DDoS 98 situation because the returning ACK packets may not get through. 100 The block-wise transfer specified in [RFC7959] covers the general 101 case, but falls short in situations where packet loss is highly 102 asymmetrical. The mechanism specified in [I-D.ietf-core-new-block] 103 provides roughly similar features to the Block1/Block2 Options, but 104 provides additional properties that are tailored towards the intended 105 DOTS transmission. Concretely, [I-D.ietf-core-new-block] primarily 106 targets applications such as DDoS Open Threat Signaling (DOTS) that 107 can't use Confirmable responses to handle potential packet loss and 108 that support application-specific mechanisms to assess whether the 109 remote peer is able to handle the messages sent by a CoAP endpoint 110 (e.g., DOTS heartbeats in Section 4.7 of [RFC9132]). 112 [I-D.ietf-core-new-block] includes guards to prevent a CoAP agent 113 from overloading the network by adopting an aggressive sending rate. 114 These guards are followed in addition to the existing CoAP congestion 115 control as specified in Section 4.7 of [RFC7252] (mainly, 116 PROBING_RATE). Table 1 lists the additional CoAP attributes that are 117 used for the guards (Section 7.2 of [I-D.ietf-core-new-block]). 119 +---------------------+-------------------+ 120 | Parameter Name | Default Value | 121 +=====================+===================+ 122 | MAX_PAYLOADS | 10 | 123 | NON_MAX_RETRANSMIT | 4 | 124 | NON_TIMEOUT | 2 s | 125 | NON_RECEIVE_TIMEOUT | 4 s | 126 | NON_PROBING_WAIT | between 247-248 s | 127 | NON_PARTIAL_TIMEOUT | 247 s | 128 +---------------------+-------------------+ 130 Table 1: Congestion Control Parameters 132 PROBING_RATE and other transmission parameters are negotiated between 133 DOTS peers as discussed in Section 4.5.2 of [RFC9132]. Nevertheless, 134 the attributes listed in Table 1 are not supported. This document 135 defines new DOTS signal channel attributes that are used to customize 136 the configuration of robust block transmission in a DOTS context. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119][RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 Readers should be familiar with the terms and concepts defined in 147 [RFC7252] and [RFC8612]. 149 The terms "payload" and "body" are defined in [RFC7959]. The term 150 "payload" is thus used for the content of a single CoAP message 151 (i.e., a single block being transferred), while the term "body" is 152 used for the entire resource representation that is being transferred 153 in a block-wise fashion. 155 The meaning of the symbols in YANG tree diagrams are defined in 156 [RFC8340] and [RFC8791]. 158 3. DOTS Attributes for Robust Block Transmission 160 Section 7.2 of [I-D.ietf-core-new-block] defines the following 161 attributes that are used for congestion control purposes: 163 MAX_PAYLOADS: is the maximum number of payloads that can be 164 transmitted at any one time. 166 NON_MAX_RETRANSMIT: is the maximum number of times a request for the 167 retransmission of missing payloads can occur without a response 168 from the remote peer. By default, NON_MAX_RETRANSMIT has the same 169 value as MAX_RETRANSMIT (Section 4.8 of [RFC7252]). 171 NON_TIMEOUT: is the maximum period of delay between sending sets of 172 MAX_PAYLOADS payloads for the same body. NON_TIMEOUT has the same 173 value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). 175 NON_RECEIVE_TIMEOUT: is the maximum time to wait for a missing 176 payload before requesting retransmission. By default, 177 NON_RECEIVE_TIMEOUT has a value of twice NON_TIMEOUT. 179 NON_PROBING_WAIT: is used to limit the potential wait needed 180 calculated when using PROBING_WAIT. 182 NON_PARTIAL_TIMEOUT: is used for expiring partially received bodies. 184 These attributes are used together with PROBING_RATE parameter which 185 in CoAP indicates the average data rate that must not be exceeded by 186 a CoAP endpoint in sending to a peer endpoint that does not respond. 187 The single body of blocks will be subjected to PROBING_RATE 188 (Section 4.7 of [RFC7252]), not the individual packets. If the wait 189 time between sending bodies that are not being responded to 190 calculated using on PROBING_RATE exceeds NON_PROBING_WAIT, then the 191 gap time is limited to NON_PROBING_WAIT. 193 This document augments the "ietf-dots-signal-channel" DOTS signal 194 YANG module defined in Section 5.3 of [RFC9132] with the following 195 additional attributes that can be negotiated between DOTS peers to 196 enable robust and faster transmission: 198 max-payloads: This attribute echoes the MAX_PAYLOADS parameter in 199 [I-D.ietf-core-new-block]. 201 This is an optional attribute. 203 non-max-retransmit: This attribute echoes the NON_MAX_RETRANSMIT 204 parameter in [I-D.ietf-core-new-block]. The default value of this 205 attribute is 'max-retransmit'. Note that DOTS uses a default 206 value of '3' instead of '4' used for the generic CoAP use 207 (Section 4.5.2 of [RFC9132]) for max-transmit. 209 This is an optional attribute. 211 non-timeout: This attribute echoes the NON_TIMEOUT parameter in 212 [I-D.ietf-core-new-block]. The default value of this attribute is 213 'ack-timeout'. 215 This is an optional attribute. 217 non-receive-timeout: This attribute echoes the NON_RECEIVE_TIMEOUT 218 parameter in [I-D.ietf-core-new-block]. The default value of this 219 attribute is twice 'non-timeout'. 221 This is an optional attribute. 223 non-probing-wait: This attribute echoes the NON_PROBING_WAIT 224 parameter in [I-D.ietf-core-new-block]. The default value of this 225 attribute is 247s. 227 This is an optional attribute. 229 non-partial-timeout: This attribute echoes the NON_PARTIAL_TIMEOUT 230 parameter in [I-D.ietf-core-new-block]. The default value of this 231 attribute is 274s. 233 This is an optional attribute. 235 The tree structure of the "ietf-dots-robust-trans" module (Section 5) 236 is shown in Figure 1. 238 module: ietf-dots-robust-trans 240 augment-structure /dots-signal:dots-signal/dots-signal:message-type 241 /dots-signal:signal-config 242 /dots-signal:mitigating-config: 243 +-- max-payloads 244 | +-- (direction)? 245 | | +--:(server-to-client-only) 246 | | +-- max-value? uint16 247 | | +-- min-value? uint16 248 | +-- current-value? uint16 249 +-- non-max-retransmit 250 | +-- (direction)? 251 | | +--:(server-to-client-only) 252 | | +-- max-value? uint16 253 | | +-- min-value? uint16 254 | +-- current-value? uint16 255 +-- non-timeout 256 | +-- (direction)? 257 | | +--:(server-to-client-only) 258 | | +-- max-value-decimal? decimal64 259 | | +-- min-value-decimal? decimal64 260 | +-- current-value-decimal? decimal64 261 +-- non-receive-timeout 262 | +-- (direction)? 263 | | +--:(server-to-client-only) 264 | | +-- max-value-decimal? decimal64 265 | | +-- min-value-decimal? decimal64 266 | +-- current-value-decimal? decimal64 267 +-- non-probing-wait 268 | +-- (direction)? 269 | | +--:(server-to-client-only) 270 | | +-- max-value-decimal? decimal64 271 | | +-- min-value-decimal? decimal64 272 | +-- current-value-decimal? decimal64 273 +-- non-partial-wait: 274 +-- (direction)? 275 | +--:(server-to-client-only) 276 | +-- max-value-decimal? decimal64 277 | +-- min-value-decimal? decimal64 278 +-- current-value-decimal? decimal64 280 augment-structure /dots-signal:dots-signal/dots-signal:message-type 281 /dots-signal:signal-config/dots-signal:idle-config: 282 +-- max-payloads 283 | +-- (direction)? 284 | | +--:(server-to-client-only) 285 | | +-- max-value? uint16 286 | | +-- min-value? uint16 287 | +-- current-value? uint16 288 +-- non-max-retransmit 289 | +-- (direction)? 290 | | +--:(server-to-client-only) 291 | | +-- max-value? uint16 292 | | +-- min-value? uint16 293 | +-- current-value? uint16 294 +-- non-timeout 295 | +-- (direction)? 296 | | +--:(server-to-client-only) 297 | | +-- max-value-decimal? decimal64 298 | | +-- min-value-decimal? decimal64 299 | +-- current-value-decimal? decimal64 300 +-- non-receive-timeout 301 | +-- (direction)? 302 | | +--:(server-to-client-only) 303 | | +-- max-value-decimal? decimal64 304 | | +-- min-value-decimal? decimal64 305 | +-- current-value-decimal? decimal64 306 +-- non-probing-wait 307 | +-- (direction)? 308 | | +--:(server-to-client-only) 309 | | +-- max-value-decimal? decimal64 310 | | +-- min-value-decimal? decimal64 311 | +-- current-value-decimal? decimal64 312 +-- non-partial-wait: 313 +-- (direction)? 314 | +--:(server-to-client-only) 315 | +-- max-value-decimal? decimal64 316 | +-- min-value-decimal? decimal64 317 +-- current-value-decimal? decimal64 319 Figure 1: DOTS Fast Block Transmission Tree Structure 321 These attributes are mapped to CBOR types as specified in Section 4 322 and Section 6 of [RFC9132]. 324 DOTS clients follow the procedure specified in Section 4.5 of 325 [RFC9132] to negotiate, configure, and retrieve the DOTS signal 326 channel session behavior (including Q-Block parameters) with DOTS 327 peers. 329 Implementation Note 1: 'non-probing-wait' ideally should be left 330 having some jitter and so should not be hard-coded with an 331 explicit value. It is suggested to use a base value (using 332 NON_TIMEOUT instead of NON_TIMEOUT_RANDOM) and, then, the jitter 333 (ACK_RANDOM_FACTOR - 1) is added to each time the value is 334 checked. 336 Implementation Note 2: If any of the signal channel session 337 configuration parameters is updated, the 'non-probing-wait' and 338 'non-partial-timeout' values should be recalculated according to 339 the definition algorithms in Section 7.2 of 340 [I-D.ietf-core-new-block]. 342 An example of PUT message to configure Q-Block parameters is depicted 343 in Figure 2. In this example, the 'max-payloads' attribute is set to 344 '15' when no mitigation is active, while it is set to '10' when a 345 mitigation is active. The same value is used for 'non-max- 346 retransmit', 'non-timeout', 'non-receive-timeout', 'non-probing- 347 wait', and "non-partial-wait" in both idle and mitigation times. The 348 meaning of other attributes is detailed in Section 4.5 of [RFC9132]. 350 Header: PUT (Code=0.03) 351 Uri-Path: ".well-known" 352 Uri-Path: "dots" 353 Uri-Path: "config" 354 Uri-Path: "sid=123" 355 Content-Format: "application/dots+cbor" 357 { 358 "ietf-dots-signal-channel:signal-config": { 359 "mitigating-config": { 360 "heartbeat-interval": { 361 "current-value": 30 362 }, 363 "missing-hb-allowed": { 364 "current-value": 15 365 }, 366 "probing-rate": { 367 "current-value": 15 368 }, 369 "max-retransmit": { 370 "current-value": 3 371 }, 372 "ack-timeout": { 373 "current-value-decimal": "2.00" 374 }, 375 "ack-random-factor": { 376 "current-value-decimal": "1.50" 378 }, 379 "ietf-dots-robust-trans:max-payloads": { 380 "current-value": 10 381 }, 382 "ietf-dots-robust-trans:non-max-retransmit": { 383 "current-value": 3 384 }, 385 "ietf-dots-robust-trans:non-timeout": { 386 "current-value-decimal": "2.00" 387 }, 388 "ietf-dots-robust-trans:non-receive-timeout": { 389 "current-value-decimal": "4.00" 390 }, 391 "ietf-dots-robust-trans:non-probing-wait": { 392 "current-value-decimal": "247.00" 393 }, 394 "ietf-dots-robust-trans:non-partial-wait": { 395 "current-value-decimal": "247.00" 396 } 397 }, 398 "idle-config": { 399 "heartbeat-interval": { 400 "current-value": 0 401 }, 402 "max-retransmit": { 403 "current-value": 3 404 }, 405 "ack-timeout": { 406 "current-value-decimal": "2.00" 407 }, 408 "ack-random-factor": { 409 "current-value-decimal": "1.50" 410 }, 411 "ietf-dots-robust-trans:max-payloads": { 412 "current-value": 15 413 }, 414 "ietf-dots-robust-trans:non-max-retransmit": { 415 "current-value": 3 416 }, 417 "ietf-dots-robust-trans:non-timeout": { 418 "current-value-decimal": "2.00" 419 }, 420 "ietf-dots-robust-trans:non-receive-timeout": { 421 "current-value-decimal": "4.00" 422 }, 423 "ietf-dots-robust-trans:non-probing-wait": { 424 "current-value-decimal": "247.00" 425 }, 426 "ietf-dots-robust-trans:non-partial-wait": { 427 "current-value-decimal": "247.00" 428 } 429 } 430 } 431 } 433 Figure 2: Example of PUT to Convey the Configuration Parameters 435 The payload of the message depicted in Figure 2 is CBOR-encoded as 436 indicated by the Content-Format set to "application/dots+cbor" 437 (Section 10.3 of [RFC9132]). However, and for the sake of better 438 readability, the example uses JSON encoding of YANG-modeled data 439 following the mapping table in Section 4 and Section 6 of [RFC9132]: 440 use the JSON names and types defined in Section 4. These conventions 441 are inherited from [RFC9132]. 443 4. YANG/JSON Mapping Parameters to CBOR 445 The YANG/JSON mapping parameters to CBOR are listed in Table 2. 447 * Note: Implementers must check that the mapping output provided by 448 their YANG-to-CBOR encoding schemes is aligned with the content of 449 Table 2. 451 +----------------------+------------+------+---------------+--------+ 452 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 453 | | Type | Key | Type & | Type | 454 | | | | Information | | 455 +======================+============+======+===============+========+ 456 | ietf-dots-robust- | container | TBA1 | 5 map | Object | 457 | trans:max-payloads | | | | | 458 +----------------------+------------+------+---------------+--------+ 459 | ietf-dots-robust- | container | TBA2 | 5 map | Object | 460 | trans:non-max- | | | | | 461 | retransmit | | | | | 462 +----------------------+------------+------+---------------+--------+ 463 | ietf-dots-robust- | container | TBA3 | 5 map | Object | 464 | trans:non-timeout | | | | | 465 +----------------------+------------+------+---------------+--------+ 466 | ietf-dots-robust- | container | TBA4 | 5 map | Object | 467 | trans:non-receive- | | | | | 468 | timeout | | | | | 469 +----------------------+------------+------+---------------+--------+ 470 | ietf-dots-robust- | container | TBA5 | 5 map | Object | 471 | trans:non-probing- | | | | | 472 | wait | | | | | 473 +----------------------+------------+------+---------------+--------+ 474 | ietf-dots-robust- | container | TBA6 | 5 map | Object | 475 | trans:non-partial- | | | | | 476 | wait | | | | | 477 +----------------------+------------+------+---------------+--------+ 479 Table 2: YANG/JSON Mapping Parameters to CBOR 481 5. DOTS Robust Block Transmission YANG Module 483 The "ietf-dots-robust-trans" module is not intended to be used via 484 NETCONF/RESTCONF; it serves only to provide abstract data structures. 485 This module uses the data structure extension defined in [RFC8791]. 487 file "ietf-dots-robust-trans@2022-01-04.yang" 488 module ietf-dots-robust-trans { 489 yang-version 1.1; 490 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans"; 491 prefix dots-robust; 493 import ietf-dots-signal-channel { 494 prefix dots-signal; 495 reference 496 "RFC 9132: Distributed Denial-of-Service Open Threat 497 Signaling (DOTS) Signal Channel Specification"; 499 } 500 import ietf-yang-structure-ext { 501 prefix sx; 502 reference 503 "RFC 8791: YANG Data Structure Extensions"; 504 } 506 organization 507 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 508 contact 509 "WG Web: 510 WG List: 512 Author: Mohamed Boucadair 513 ; 515 Author: Jon Shallow 516 "; 517 description 518 "This module contains YANG definitions for the configuration 519 of parameters that can be negotiated between a DOTS client 520 and a DOTS server for robust block transmission. 522 Copyright (c) 2022 IETF Trust and the persons identified as 523 authors of the code. All rights reserved. 525 Redistribution and use in source and binary forms, with or 526 without modification, is permitted pursuant to, and subject 527 to the license terms contained in, the Revised BSD License 528 set forth in Section 4.c of the IETF Trust's Legal Provisions 529 Relating to IETF Documents 530 (http://trustee.ietf.org/license-info). 532 This version of this YANG module is part of RFC XXXX; see 533 the RFC itself for full legal notices."; 535 revision 2022-01-04 { 536 description 537 "Initial revision."; 538 reference 539 "RFC XXXX: Distributed Denial-of-Service Open Threat 540 Signaling (DOTS) Configuration Attributes 541 for Robust Block Transmission"; 542 } 544 grouping robust-transmission-attributes { 545 description 546 "A set of DOTS signal channel session configuration 547 that are negotiated between DOTS agents when 548 making use of Q-Block1 and Q-Block2 Options."; 549 container max-payloads { 550 description 551 "Indicates the maximum number of payloads that 552 can be transmitted at any one time."; 553 choice direction { 554 description 555 "Indicates the communication direction in which the 556 data nodes can be included."; 557 case server-to-client-only { 558 description 559 "These data nodes appear only in a message sent 560 from the server to the client."; 561 leaf max-value { 562 type uint16; 563 description 564 "Maximum acceptable max-payloads value."; 565 } 566 leaf min-value { 567 type uint16; 568 description 569 "Minimum acceptable max-payloads value."; 570 } 571 } 572 } 573 leaf current-value { 574 type uint16; 575 default "10"; 576 description 577 "Current max-payloads value."; 578 reference 579 "RFC NNNN: Constrained Application Protocol (CoAP) 580 Block-Wise Transfer Options Supporting 581 Robust Transmission, Section 7.2"; 582 } 583 } 584 container non-max-retransmit { 585 description 586 "Indicates the maximum number of times a request 587 for the retransmission of missings payloads can 588 occur without a response from the remote peer."; 589 choice direction { 590 description 591 "Indicates the communication direction in which the 592 data nodes can be included."; 593 case server-to-client-only { 594 description 595 "These data nodes appear only in a message sent 596 from the server to the client."; 597 leaf max-value { 598 type uint16; 599 description 600 "Maximum acceptable non-max-retransmit value."; 601 } 602 leaf min-value { 603 type uint16; 604 description 605 "Minimum acceptable non-max-retransmit value."; 606 } 607 } 608 } 609 leaf current-value { 610 type uint16; 611 default "3"; 612 description 613 "Current non-max-retransmit value."; 614 reference 615 "RFC NNNN: Constrained Application Protocol (CoAP) 616 Block-Wise Transfer Options Supporting 617 Robust Transmission, Section 7.2"; 618 } 619 } 620 container non-timeout { 621 description 622 "Indicates the maximum period of delay between 623 sending sets of MAX_PAYLOADS payloads for the same 624 body."; 625 choice direction { 626 description 627 "Indicates the communication direction in which the 628 data nodes can be included."; 629 case server-to-client-only { 630 description 631 "These data nodes appear only in a message sent 632 from the server to the client."; 633 leaf max-value-decimal { 634 type decimal64 { 635 fraction-digits 2; 636 } 637 units "seconds"; 638 description 639 "Maximum ack-timeout value."; 640 } 641 leaf min-value-decimal { 642 type decimal64 { 643 fraction-digits 2; 644 } 645 units "seconds"; 646 description 647 "Minimum ack-timeout value."; 648 } 649 } 650 } 651 leaf current-value-decimal { 652 type decimal64 { 653 fraction-digits 2; 654 } 655 units "seconds"; 656 default "2.00"; 657 description 658 "Current ack-timeout value."; 659 reference 660 "RFC NNNN: Constrained Application Protocol (CoAP) 661 Block-Wise Transfer Options Supporting 662 Robust Transmission, Section 7.2"; 663 } 664 } 665 container non-receive-timeout { 666 description 667 "Indicates the time to wait for a missing payload 668 before requesting retransmission."; 669 choice direction { 670 description 671 "Indicates the communication direction in which the 672 data nodes can be included."; 673 case server-to-client-only { 674 description 675 "These data nodes appear only in a message sent 676 from the server to the client."; 677 leaf max-value-decimal { 678 type decimal64 { 679 fraction-digits 2; 680 } 681 units "seconds"; 682 description 683 "Maximum non-receive-timeout value."; 684 } 685 leaf min-value-decimal { 686 type decimal64 { 687 fraction-digits 2; 688 } 689 units "seconds"; 690 description 691 "Minimum non-receive-timeout value."; 692 } 693 } 694 } 695 leaf current-value-decimal { 696 type decimal64 { 697 fraction-digits 2; 698 } 699 units "seconds"; 700 default "4.00"; 701 description 702 "Current non-receive-timeout value."; 703 reference 704 "RFC NNNN: Constrained Application Protocol (CoAP) 705 Block-Wise Transfer Options Supporting 706 Robust Transmission, Section 7.2"; 707 } 708 } 709 container non-probing-wait { 710 description 711 "Is used to limit the potential wait needed calculated 712 when using probing-rate."; 713 choice direction { 714 description 715 "Indicates the communication direction in which the 716 data nodes can be included."; 717 case server-to-client-only { 718 description 719 "These data nodes appear only in a message sent 720 from the server to the client."; 721 leaf max-value-decimal { 722 type decimal64 { 723 fraction-digits 2; 724 } 725 units "seconds"; 726 description 727 "Maximum non-probing-wait value."; 728 } 729 leaf min-value-decimal { 730 type decimal64 { 731 fraction-digits 2; 732 } 733 units "seconds"; 734 description 735 "Minimum non-probing-wait value."; 736 } 737 } 738 } 739 leaf current-value-decimal { 740 type decimal64 { 741 fraction-digits 2; 742 } 743 units "seconds"; 744 default "247.00"; 745 description 746 "Current non-probing-wait value."; 747 reference 748 "RFC NNNN: Constrained Application Protocol (CoAP) 749 Block-Wise Transfer Options Supporting 750 Robust Transmission, Section 7.2"; 751 } 752 } 753 container non-partial-wait { 754 description 755 "Is used for expiring partially received bodies."; 756 choice direction { 757 description 758 "Indicates the communication direction in which the 759 data nodes can be included."; 760 case server-to-client-only { 761 description 762 "These data nodes appear only in a message sent 763 from the server to the client."; 764 leaf max-value-decimal { 765 type decimal64 { 766 fraction-digits 2; 767 } 768 units "seconds"; 769 description 770 "Maximum non-partial-wait value."; 771 } 772 leaf min-value-decimal { 773 type decimal64 { 774 fraction-digits 2; 775 } 776 units "seconds"; 777 description 778 "Minimum non-partial-wait value."; 779 } 780 } 781 } 782 leaf current-value-decimal { 783 type decimal64 { 784 fraction-digits 2; 785 } 786 units "seconds"; 787 default "247.00"; 788 description 789 "Current non-partial-wait value."; 790 reference 791 "RFC NNNN: Constrained Application Protocol (CoAP) 792 Block-Wise Transfer Options Supporting 793 Robust Transmission, Section 7.2"; 794 } 795 } 796 } 798 sx:augment-structure "/dots-signal:dots-signal" 799 + "/dots-signal:message-type" 800 + "/dots-signal:signal-config" 801 + "/dots-signal:mitigating-config" { 802 description 803 "Indicates DOTS configuration parameters to use for 804 robust transmission when a mitigation is active."; 805 uses robust-transmission-attributes; 806 } 807 sx:augment-structure "/dots-signal:dots-signal" 808 + "/dots-signal:message-type" 809 + "/dots-signal:signal-config" 810 + "/dots-signal:idle-config" { 811 description 812 "Indicates DOTS configuration parameters to use for 813 robust transmission when no mitigation is active."; 814 uses robust-transmission-attributes; 815 } 816 } 817 819 Note to the RFC Editor: Please replace RFC NNNN with the RFC 820 number assignd to [I-D.ietf-core-new-block]. 822 6. IANA Considerations 824 6.1. DOTS Signal Channel CBOR Mappings Registry 826 This specification registers the following parameters in the IANA 827 "DOTS Signal Channel CBOR Key Values" registry [Key-Map]. 829 * Note to the RFC Editor: Please replace TBA1-TBA6 with the CBOR 830 keys that are assigned from the 32768-49151 range. Please update 831 Table 2 accordingly. 833 +------------------------+-------+-------+------------+---------------+ 834 | Parameter Name | CBOR | CBOR | Change | Specification | 835 | | Key | Major | Controller | Document(s) | 836 | | Value | Type | | | 837 +========================+=======+=======+============+===============+ 838 | ietf-dots-robust-trans:| TBA1 | 5 | IESG | [RFCXXXX] | 839 | max-payloads | | | | | 840 +------------------------+-------+-------+------------+---------------+ 841 | ietf-dots-robust-trans:| TBA2 | 5 | IESG | [RFCXXXX] | 842 | non-max-retransmit | | | | | 843 +------------------------+-------+-------+------------+---------------+ 844 | ietf-dots-robust-trans:| TBA3 | 5 | IESG | [RFCXXXX] | 845 | non-timeout | | | | | 846 +------------------------+-------+-------+------------+---------------+ 847 | ietf-dots-robust-trans:| TBA4 | 5 | IESG | [RFCXXXX] | 848 | non-receive-timeout | | | | | 849 +------------------------+-------+-------+------------+---------------+ 850 | ietf-dots-robust-trans:| TBA5 | 5 | IESG | [RFCXXXX] | 851 | non-probing-wait | | | | | 852 +------------------------+-------+-------+------------+---------------+ 853 | ietf-dots-robust-trans:| TBA6 | 5 | IESG | [RFCXXXX] | 854 | non-partial-wait | | | | | 855 +------------------------+-------+-------+------------+---------------+ 857 6.2. DOTS Robust Block Transmission YANG Module 859 This document requests IANA to register the following URI in the "ns" 860 subregistry within the "IETF XML Registry" [RFC3688]: 862 URI: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans 863 Registrant Contact: The IESG. 864 XML: N/A; the requested URI is an XML namespace. 866 This document requests IANA to register the following YANG module in 867 the "YANG Module Names" subregistry [RFC6020] within the "YANG 868 Parameters" registry. 870 Name: ietf-dots-robust-trans 871 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans 872 Maintained by IANA? N 873 Prefix: dots-robust 874 Reference: RFC XXXX 876 7. Security Considerations 878 The security considerations for the DOTS signal channel protocol are 879 discussed in Section 11 of [RFC9132]. 881 CoAP-specific security considerations are discussed in Section 11 of 882 [I-D.ietf-core-new-block]. 884 This document defines YANG data structures that are meant to be used 885 as an abstract representation in DOTS signal channel messages. As 886 such, the "ietf-dots-robust-trans" module (Section 5) does not 887 introduce any new vulnerabilities beyond those specified above. 889 8. Acknowledgements 891 Thanks to Tiru Reddy, Meiling Chen, and kaname nishizuka for the 892 review. 894 Thanks to Michal Vasko for the yangdoctors review. 896 Thanks to Valery Smyslov for shepherding the document. 898 9. References 900 9.1. Normative References 902 [I-D.ietf-core-new-block] 903 Boucadair, M. and J. Shallow, "Constrained Application 904 Protocol (CoAP) Block-Wise Transfer Options Supporting 905 Robust Transmission", Work in Progress, Internet-Draft, 906 draft-ietf-core-new-block-14, 26 May 2021, 907 . 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, 912 DOI 10.17487/RFC2119, March 1997, 913 . 915 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 916 DOI 10.17487/RFC3688, January 2004, 917 . 919 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 920 the Network Configuration Protocol (NETCONF)", RFC 6020, 921 DOI 10.17487/RFC6020, October 2010, 922 . 924 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 925 Application Protocol (CoAP)", RFC 7252, 926 DOI 10.17487/RFC7252, June 2014, 927 . 929 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 930 the Constrained Application Protocol (CoAP)", RFC 7959, 931 DOI 10.17487/RFC7959, August 2016, 932 . 934 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 935 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 936 May 2017, . 938 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 939 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 940 Application Protocol) over TCP, TLS, and WebSockets", 941 RFC 8323, DOI 10.17487/RFC8323, February 2018, 942 . 944 [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data 945 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 946 June 2020, . 948 [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, 949 "Distributed Denial-of-Service Open Threat Signaling 950 (DOTS) Signal Channel Specification", RFC 9132, 951 DOI 10.17487/RFC9132, September 2021, 952 . 954 9.2. Informative References 956 [I-D.ietf-dots-telemetry] 957 Boucadair, M., Reddy.K, T., Doron, E., Chen, M., and J. 958 Shallow, "Distributed Denial-of-Service Open Threat 959 Signaling (DOTS) Telemetry", Work in Progress, Internet- 960 Draft, draft-ietf-dots-telemetry-23, 4 February 2022, 961 . 964 [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", 965 . 968 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 969 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 970 . 972 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 973 Threat Signaling (DOTS) Requirements", RFC 8612, 974 DOI 10.17487/RFC8612, May 2019, 975 . 977 Authors' Addresses 979 Mohamed Boucadair 980 Orange 981 35000 Rennes 982 France 984 Email: mohamed.boucadair@orange.com 986 Jon Shallow 987 United Kingdom 989 Email: supjps-ietf@jpshallow.com