idnits 2.17.1 draft-bosh-dots-quick-blocks-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 11, 2021) is 1194 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 461, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-core-new-block-04 == Outdated reference: A later version (-08) exists of draft-ietf-dots-rfc8782-bis-04 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-25) exists of draft-ietf-dots-telemetry-15 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track J. Shallow 5 Expires: July 15, 2021 January 11, 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-00 11 Abstract 13 This document specifies new DOTS signal channel configuration 14 parameters that are negotiated between DOTS peers to enable the use 15 of Q-Block1 and Q-Block2 Options. These options enable faster 16 transmission rates for large amounts of data with less packet 17 interchanges as well as supporting faster recovery should any of the 18 blocks get lost in transmission. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 15, 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 . . . . . . . . . . 5 58 4.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 5 59 4.2. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . 6 60 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 5.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 10 63 5.2. DOTS Signal Filtering Control YANG Module . . . . . . . . 11 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 68 8.2. Informative References . . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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_TIMEOUT | 2 s | 125 | NON_RECEIVE_TIMEOUT | 4 s | 126 | NON_PROBING_WAIT | 247 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 134 [I-D.ietf-dots-rfc8782-bis]. Nevertheless, some of the attributes 135 listed in Table 1 are not supported. This document defines new DOTS 136 signal channel attributes that are meant to customize the 137 configuration of faster block transmission in a DOTS context. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119][RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 Readers should be familiar with the terms and concepts defined in 148 [RFC7252] and [RFC8612]. 150 The terms "payload" and "body" are defined in [RFC7959]. The term 151 "payload" is thus used for the content of a single CoAP message 152 (i.e., a single block being transferred), while the term "body" is 153 used for the entire resource representation that is being transferred 154 in a block-wise fashion. 156 The meaning of the symbols in YANG tree diagrams are defined in 157 [RFC8340] and [RFC8791]. 159 (D)TLS is used for statements that apply to both Transport Layer 160 Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) 161 [RFC6347]. Specific terms are used for any statement that applies to 162 either protocol alone. 164 3. DOTS Attributes for Faster Block Transmission 166 Section 6.2 of [I-D.ietf-core-new-block] defines the following 167 attributes that are used for congestion control purposes: 169 MAX_PAYLOADS: is the maximum number of payloads that can be 170 transmitted at any one time. 172 NON_TIMEOUT: is the maximum period of delay between sending sets of 173 MAX_PAYLOADS payloads for the same body. NON_TIMEOUT has the same 174 value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). 176 NON_RECEIVE_TIMEOUT: is the maximum time to wait for a missing 177 payload before requesting retransmission. NON_RECEIVE_TIMEOUT has 178 a value of twice NON_TIMEOUT. 180 NON_PROBING_WAIT: is used to limit the potential wait needed 181 calculated when using PROBING_WAIT. NON_PROBING_WAIT has the same 182 value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of 183 [RFC7252]). 185 NON_PARTIAL_TIMEOUT: is used for expiring partially received bodies. 186 NON_PARTIAL_TIMEOUT has the same value as computed for 187 EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). 189 These attributes are used together with PROBING_RATE parameter which 190 in CoAP indicates the average data rate that must not be exceeded by 191 a CoAP endpoint in sending to a peer endpoint that does not respond. 192 The single body of blocks will be subjected to PROBING_RATE 193 (Section 4.7 of [RFC7252]), not the individual packets. If the wait 194 time between sending bodies that are not being responded to based on 195 PROBING_RATE exceeds NON_PROBING_WAIT, then the gap time is limited 196 to NON_PROBING_WAIT. 198 Except MAX_PAYLOADS, all the aforementioned attributes can be derived 199 from attributes that can be negotiated between DOTS peers as per 200 Section 4.5.2 of [I-D.ietf-dots-rfc8782-bis]. This document augments 201 the "ietf-dots-signal-channel" (dots-signal) DOTS signal YANG module 202 defined in [I-D.ietf-dots-rfc8782-bis] with this additional attribute 203 that can be negotiated between DOTS peers to enable faster 204 transmission: 206 max-payloads: This attribute echoes the MAX_PAYLOADS parameter in 207 [I-D.ietf-core-new-block]. 209 This is an optional attribute. 211 For the sake of more flexible configuration, this document defines 212 also the following attribute: 214 non-timeout: This attribute echoes the NON_TIMEOUT parameter in 215 [I-D.ietf-core-new-block]. The the default value of this 216 attribute is 'ack-timeout'. 218 This is an optional attribute. 220 4. DOTS Fast Block Transmission YANG Module 222 4.1. Tree Structure 224 This document defines the YANG module "ietf-dots-fast-trans" 225 (Section 4), which has the following tree structure: 227 module: ietf-dots-fast-trans 229 augment-structure /dots-signal:dots-signal/dots-signal:message-type 230 /dots-signal:signal-config 231 /dots-signal:mitigating-config: 232 +-- max-payloads 233 | +-- (direction)? 234 | | +--:(server-to-client-only) 235 | | +-- max-value? uint16 236 | | +-- min-value? uint16 237 | +-- current-value? uint16 238 +-- non-timeout 239 +-- (direction)? 240 | +--:(server-to-client-only) 241 | +-- max-value-decimal? decimal64 242 | +-- min-value-decimal? decimal64 243 +-- current-value-decimal? decimal64 244 augment-structure /dots-signal:dots-signal/dots-signal:message-type 245 /dots-signal:signal-config/dots-signal:idle-config: 246 +-- max-payloads 247 | +-- (direction)? 248 | | +--:(server-to-client-only) 249 | | +-- max-value? uint16 250 | | +-- min-value? uint16 251 | +-- current-value? uint16 252 +-- non-timeout 253 +-- (direction)? 254 | +--:(server-to-client-only) 255 | +-- max-value-decimal? decimal64 256 | +-- min-value-decimal? decimal64 257 +-- current-value-decimal? decimal64 259 4.2. YANG/JSON Mapping Parameters to CBOR 261 The YANG/JSON mapping parameters to CBOR are listed in Table 2. 263 o Note: Implementers must check that the mapping output provided by 264 their YANG-to-CBOR encoding schemes is aligned with the content of 265 Table 2. 267 +----------------------+------------+------+---------------+--------+ 268 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 269 | | Type | Key | Type & | Type | 270 | | | | Information | | 271 +======================+============+======+===============+========+ 272 | ietf-dots-fast-trans:| container | TBA1 | 5 map | Object | 273 | max-payloads | | | | | 274 +----------------------+------------+------+---------------+--------+ 275 | ietf-dots-fast-trans:| container | TBA2 | 5 map | Object | 276 | non-timeout | | | | | 277 +----------------------+------------+------+---------------+--------+ 279 Table 2: YANG/JSON Mapping Parameters to CBOR 281 4.3. YANG Module 283 This module uses the data structure extension defined in [RFC8791]. 285 file "ietf-dots-fast-trans@2020-12-02.yang" 286 module ietf-dots-fast-trans { 287 yang-version 1.1; 288 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-fast-trans"; 289 prefix dots-fast; 291 import ietf-dots-signal-channel { 292 prefix dots-signal; 293 reference 294 "RFC YYYY: Distributed Denial-of-Service Open Threat 295 Signaling (DOTS) Signal Channel Specification"; 296 } 297 import ietf-yang-structure-ext { 298 prefix sx; 299 reference 300 "RFC 8791: YANG Data Structure Extensions"; 301 } 303 organization 304 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 305 contact 306 "WG Web: 307 WG List: 309 Author: Mohamed Boucadair 310 ; 312 Author: Jon Shallow 313 "; 314 description 315 "This module contains YANG definitions for the configuration 316 of parameters that can be negotiated between a DOTS client 317 and a DOTS server for faster block transmission. 319 Copyright (c) 2021 IETF Trust and the persons identified as 320 authors of the code. All rights reserved. 322 Redistribution and use in source and binary forms, with or 323 without modification, is permitted pursuant to, and subject 324 to the license terms contained in, the Simplified BSD License 325 set forth in Section 4.c of the IETF Trust's Legal Provisions 326 Relating to IETF Documents 327 (http://trustee.ietf.org/license-info). 329 This version of this YANG module is part of RFC XXXX; see 330 the RFC itself for full legal notices."; 332 revision 2021-01-11 { 333 description 334 "Initial revision."; 335 reference 336 "RFC XXXX: Distributed Denial-of-Service Open Threat 337 Signaling (DOTS) Configuration Attributes 338 for Faster Block Transmission"; 339 } 341 grouping fast-transmission-attributes { 342 description 343 "A set of DOTS signal channel session configuration 344 that are negotiated between DOTS agents when 345 making use of Q-Block1 and Q-Block2 Options."; 346 container max-payloads { 347 description 348 "Indicates the maximum number of payloads that 349 can be transmitted at any one time."; 350 choice direction { 351 description 352 "Indicates the communication direction in which the 353 data nodes can be included."; 354 case server-to-client-only { 355 description 356 "These data nodes appear only in a mitigation message 357 sent from the server to the client."; 358 leaf max-value { 359 type uint16; 360 description 361 "Maximum acceptable max-payloads value."; 362 } 363 leaf min-value { 364 type uint16; 365 description 366 "Minimum acceptable max-payloads value."; 367 } 368 } 369 } 370 leaf current-value { 371 type uint16; 372 default "10"; 373 description 374 "Current max-payloads value."; 375 } 376 } 377 container non-timeout { 378 description 379 "Indicates the maximum period of delay between 380 sending sets of MAX_PAYLOADS payloads for the same 381 body. By default, this parameter has the same value 382 as ACK_TIMEOUT."; 383 choice direction { 384 description 385 "Indicates the communication direction in which the 386 data nodes can be included."; 387 case server-to-client-only { 388 description 389 "These data nodes appear only in a mitigation message 390 sent from the server to the client."; 391 leaf max-value-decimal { 392 type decimal64 { 393 fraction-digits 2; 394 } 395 units "seconds"; 396 description 397 "Maximum ack-timeout value."; 398 } 399 leaf min-value-decimal { 400 type decimal64 { 401 fraction-digits 2; 402 } 403 units "seconds"; 404 description 405 "Minimum ack-timeout value."; 406 } 407 } 408 } 409 leaf current-value-decimal { 410 type decimal64 { 411 fraction-digits 2; 412 } 413 units "seconds"; 414 default "2"; 415 description 416 "Current ack-timeout value."; 417 } 418 } 419 } 421 sx:augment-structure "/dots-signal:dots-signal" 422 + "/dots-signal:message-type" 423 + "/dots-signal:signal-config" 424 + "/dots-signal:mitigating-config" { 425 description 426 "Indicates DOTS configuration parameters to use for 427 faster transmission when a mitigation is active."; 428 uses fast-transmission-attributes; 429 } 430 sx:augment-structure "/dots-signal:dots-signal" 431 + "/dots-signal:message-type" 432 + "/dots-signal:signal-config" 433 + "/dots-signal:idle-config" { 434 description 435 "Indicates DOTS configuration parameters to use for 436 faster transmission when no mitigation is active."; 437 uses fast-transmission-attributes; 438 } 439 } 440 442 5. IANA Considerations 444 5.1. DOTS Signal Channel CBOR Mappings Registry 446 This specification registers the following parameters in the IANA 447 "DOTS Signal Channel CBOR Key Values" registry [Key-Map]. 449 o Note to the RFC Editor: Please replace TBA1-TBA2 with the CBOR 450 keys that are assigned from the 128-255 range. Please update 451 Table 2 accordingly. 453 +----------------------+-------+-------+------------+---------------+ 454 | Parameter Name | CBOR | CBOR | Change | Specification | 455 | | Key | Major | Controller | Document(s) | 456 | | Value | Type | | | 457 +======================+=======+=======+============+===============+ 458 | ietf-dots-fast-trans:| TBA1 | 5 | IESG | [RFCXXXX] | 459 | max-payloads | | | | | 460 +----------------------+-------+-------+------------+---------------+ 461 | ietf-dots-fast-trans:| TBA2 | 5 | IESG | [RFCXXXX] | 462 | non-timeout | | | | | 463 +----------------------+-------+-------+------------+---------------+ 465 5.2. DOTS Signal Filtering Control YANG Module 467 This document requests IANA to register the following URI in the "ns" 468 subregistry within the "IETF XML Registry" [RFC3688]: 470 URI: urn:ietf:params:xml:ns:yang:ietf-dots-fast-trans 471 Registrant Contact: The IESG. 472 XML: N/A; the requested URI is an XML namespace. 474 This document requests IANA to register the following YANG module in 475 the "YANG Module Names" subregistry [RFC6020] within the "YANG 476 Parameters" registry. 478 Name: ietf-dots-fast-trans 479 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-fast-trans 480 Maintained by IANA: N 481 Prefix: dots-fast 482 Reference: RFC XXXX 484 6. Security Considerations 486 The security considerations for the DOTS signal channel protocol are 487 discussed in Section 11 of [I-D.ietf-dots-rfc8782-bis]. 489 CoAP-specific security considerations are discussed in Section 11 of 490 [I-D.ietf-core-new-block]. 492 This document defines YANG data structures that are meant to be used 493 as an abstract representation in DOTS signal channel messages. As 494 such, the "ietf-dots-fast-trans" module does not introduce any new 495 vulnerabilities beyond those specified above. 497 7. Acknowledgements 499 TBC 501 8. References 503 8.1. Normative References 505 [I-D.ietf-core-new-block] 506 Boucadair, M. and J. Shallow, "Constrained Application 507 Protocol (CoAP) Block-Wise Transfer Options for Faster 508 Transmission", draft-ietf-core-new-block-04 (work in 509 progress), January 2021. 511 [I-D.ietf-dots-rfc8782-bis] 512 Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed 513 Denial-of-Service Open Threat Signaling (DOTS) Signal 514 Channel Specification", draft-ietf-dots-rfc8782-bis-04 515 (work in progress), December 2020. 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, 519 DOI 10.17487/RFC2119, March 1997, 520 . 522 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 523 DOI 10.17487/RFC3688, January 2004, 524 . 526 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 527 the Network Configuration Protocol (NETCONF)", RFC 6020, 528 DOI 10.17487/RFC6020, October 2010, 529 . 531 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 532 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 533 January 2012, . 535 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 536 Application Protocol (CoAP)", RFC 7252, 537 DOI 10.17487/RFC7252, June 2014, 538 . 540 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 541 the Constrained Application Protocol (CoAP)", RFC 7959, 542 DOI 10.17487/RFC7959, August 2016, 543 . 545 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 546 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 547 May 2017, . 549 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 550 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 551 Application Protocol) over TCP, TLS, and WebSockets", 552 RFC 8323, DOI 10.17487/RFC8323, February 2018, 553 . 555 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 556 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 557 . 559 [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data 560 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 561 June 2020, . 563 8.2. Informative References 565 [I-D.ietf-dots-telemetry] 566 Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., 567 and J. Shallow, "Distributed Denial-of-Service Open Threat 568 Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 569 (work in progress), December 2020. 571 [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", 572 . 575 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 576 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 577 . 579 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 580 Threat Signaling (DOTS) Requirements", RFC 8612, 581 DOI 10.17487/RFC8612, May 2019, 582 . 584 Authors' Addresses 586 Mohamed Boucadair 587 Orange 588 Rennes 35000 589 France 591 Email: mohamed.boucadair@orange.com 592 Jon Shallow 593 United Kingdom 595 Email: supjps-ietf@jpshallow.com