idnits 2.17.1 draft-boucadair-dots-rfc8782-yang-update-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 == Line 137 has weird spacing: '...er-port ine...' == Line 159 has weird spacing: '...er-port ine...' == Line 166 has weird spacing: '...cl-name lea...' -- The document date (July 6, 2020) is 1362 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) ** Obsolete normative reference: RFC 8782 (Obsoleted by RFC 9132) Summary: 1 error (**), 0 flaws (~~), 4 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 Updates: 8782 (if approved) J. Shallow 5 Intended status: Standards Track July 6, 2020 6 Expires: January 7, 2021 8 A YANG Data Model for Distributed Denial-of-Service Open Threat 9 Signaling (DOTS) Signal Channel 10 draft-boucadair-dots-rfc8782-yang-update-00 12 Abstract 14 This document specifies an updated version of the Distributed Denial- 15 of-Service Open Threat Signaling (DOTS) Signal Channel YANG data 16 model. This updated version makes use of the new mechanisms for 17 defining abstract data structures with YANG as specified in RFC8791. 19 This document updates RFC 8782. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 7, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Summary of Changes From RFC8782 . . . . . . . . . . . . . . . 2 57 3. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 64 8.2. Informative References . . . . . . . . . . . . . . . . . 20 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 67 1. Introduction 69 As specified in [RFC8782], messages exchanged between DOTS agents are 70 serialized using Concise Binary Object Representation (CBOR) 71 [RFC7252]. CBOR-encoded payloads are used to carry signal channel- 72 specific payload messages which convey request parameters and 73 response information such as errors. 75 This document specifies a YANG module [RFC7950] for representing DOTS 76 mitigation scopes, DOTS signal channel session configuration data, 77 and DOTS redirected signaling. All parameters in the payload of the 78 DOTS signal channel are mapped to CBOR types as specified in Table 5 79 of [RFC8782]. 81 This YANG module is not intended to be used via NETCONF/RESTCONF for 82 DOTS server management purposes; such a module is out of the scope of 83 this document. It serves only to provide abstract data structures. 84 This document uses the "structure" extension specified in [RFC8791]. 86 The meaning of the symbols in YANG tree diagrams is defined in 87 [RFC8340] and [RFC8791]. 89 2. Summary of Changes From RFC8782 91 The main changes compared to the YANG version published in [RFC8782] 92 are as follows: 94 o Follow the new YANG data structure specified in [RFC8791]. 96 o Add in "choice" to indicate the communication direction in which a 97 data node applies. If no "choice" is indicated, a node can appear 98 in both directions (i.e., from DOTS clients to DOTS servers and 99 vice versa). 101 o Remove "config" clauses. Note that "config" statements will be 102 ignored (if present) anyway according to Section 4 of [RFC8791]. 104 o Remove "cuid", "cdid", and "sid" nodes from the structure because 105 these nodes are included as Uri-Path options, not within the 106 message body. 108 o Remove the list keys for the mitigation scope message type (i.e., 109 "cuid" and "mid"). "mid" is not indicated as a key because it is 110 included as Uri-Path option for requests and in the message body 111 for responses. Note that Section 4 of [RFC8791] specifies that a 112 list does not require to have a key statement defined. 114 These changes are made with the constraint to avoid changes to the 115 mapping table defined in Table 5 of [RFC8782]. A DOTS signal channel 116 attribute that may be present in both requests and responses will 117 thus have the same CBOR key value and CBOR major type. 119 3. Tree Structure 121 This document defines the YANG module "ietf-dots-signal-channel", 122 which has the following tree structure. A DOTS signal message can be 123 a mitigation, a configuration, a redirect, or a heartbeat message. 124 The use of these attributes is specified in [RFC8782]. 126 This tree structure obsoletes the one described in Section 5.1 of 127 [RFC8782]. 129 module: ietf-dots-signal-channel 131 structure dots-signal: 132 +-- (message-type)? 133 +--:(mitigation-scope) 134 | +-- scope* [] 135 | +-- target-prefix* inet:ip-prefix 136 | +-- target-port-range* [lower-port] 137 | | +-- lower-port inet:port-number 138 | | +-- upper-port? inet:port-number 139 | +-- target-protocol* uint8 140 | +-- target-fqdn* inet:domain-name 141 | +-- target-uri* inet:uri 142 | +-- alias-name* string 143 | +-- lifetime? int32 144 | +-- trigger-mitigation? boolean 145 | +-- (direction)? 146 | +--:(server-to-client-only) 147 | +-- mid? uint32 148 | +-- mitigation-start? uint64 149 | +-- status? iana-signal:status 150 | +-- conflict-information 151 | | +-- conflict-status? 152 | | | iana-signal:conflict-status 153 | | +-- conflict-cause? 154 | | | iana-signal:conflict-cause 155 | | +-- retry-timer? uint32 156 | | +-- conflict-scope 157 | | +-- target-prefix* inet:ip-prefix 158 | | +-- target-port-range* [lower-port] 159 | | | +-- lower-port inet:port-number 160 | | | +-- upper-port? inet:port-number 161 | | +-- target-protocol* uint8 162 | | +-- target-fqdn* inet:domain-name 163 | | +-- target-uri* inet:uri 164 | | +-- alias-name* string 165 | | +-- acl-list* [acl-name] 166 | | | +-- acl-name leafref 167 | | | +-- acl-type? leafref 168 | | +-- mid? uint32 169 | +-- bytes-dropped? 170 | | yang:zero-based-counter64 171 | +-- bps-dropped? yang:gauge64 172 | +-- pkts-dropped? 173 | | yang:zero-based-counter64 174 | +-- pps-dropped? yang:gauge64 175 | +-- attack-status? 176 | iana-signal:attack-status 177 +--:(signal-config) 178 | +-- mitigating-config 179 | | +-- heartbeat-interval 180 | | | +-- (direction)? 181 | | | | +--:(server-to-client-only) 182 | | | | +-- max-value? uint16 183 | | | | +-- min-value? uint16 184 | | | +-- current-value? uint16 185 | | +-- missing-hb-allowed 186 | | | +-- (direction)? 187 | | | | +--:(server-to-client-only) 188 | | | | +-- max-value? uint16 189 | | | | +-- min-value? uint16 190 | | | +-- current-value? uint16 191 | | +-- probing-rate 192 | | | +-- (direction)? 193 | | | | +--:(server-to-client-only) 194 | | | | +-- max-value? uint16 195 | | | | +-- min-value? uint16 196 | | | +-- current-value? uint16 197 | | +-- max-retransmit 198 | | | +-- (direction)? 199 | | | | +--:(server-to-client-only) 200 | | | | +-- max-value? uint16 201 | | | | +-- min-value? uint16 202 | | | +-- current-value? uint16 203 | | +-- ack-timeout 204 | | | +-- (direction)? 205 | | | | +--:(server-to-client-only) 206 | | | | +-- max-value-decimal? decimal64 207 | | | | +-- min-value-decimal? decimal64 208 | | | +-- current-value-decimal? decimal64 209 | | +-- ack-random-factor 210 | | +-- (direction)? 211 | | | +--:(server-to-client-only) 212 | | | +-- max-value-decimal? decimal64 213 | | | +-- min-value-decimal? decimal64 214 | | +-- current-value-decimal? decimal64 215 | +-- idle-config 216 | +-- heartbeat-interval 217 | | +-- (direction)? 218 | | | +--:(server-to-client-only) 219 | | | +-- max-value? uint16 220 | | | +-- min-value? uint16 221 | | +-- current-value? uint16 222 | +-- missing-hb-allowed 223 | | +-- (direction)? 224 | | | +--:(server-to-client-only) 225 | | | +-- max-value? uint16 226 | | | +-- min-value? uint16 227 | | +-- current-value? uint16 228 | +-- probing-rate 229 | | +-- (direction)? 230 | | | +--:(server-to-client-only) 231 | | | +-- max-value? uint16 232 | | | +-- min-value? uint16 233 | | +-- current-value? uint16 234 | +-- max-retransmit 235 | | +-- (direction)? 236 | | | +--:(server-to-client-only) 237 | | | +-- max-value? uint16 238 | | | +-- min-value? uint16 239 | | +-- current-value? uint16 240 | +-- ack-timeout 241 | | +-- (direction)? 242 | | | +--:(server-to-client-only) 243 | | | +-- max-value-decimal? decimal64 244 | | | +-- min-value-decimal? decimal64 245 | | +-- current-value-decimal? decimal64 246 | +-- ack-random-factor 247 | +-- (direction)? 248 | | +--:(server-to-client-only) 249 | | +-- max-value-decimal? decimal64 250 | | +-- min-value-decimal? decimal64 251 | +-- current-value-decimal? decimal64 252 +--:(redirected-signal) 253 | +-- (direction)? 254 | +--:(server-to-client-only) 255 | +-- alt-server string 256 | +-- alt-server-record* inet:ip-address 257 +--:(heartbeat) 258 +-- peer-hb-status boolean 260 4. YANG Module 262 This module uses the common YANG types defined in [RFC6991] and types 263 defined in [RFC8783]. 265 This version obsoletes the version described in Section 5.3 of 266 [RFC8782]. 268 file "ietf-dots-signal-channel@2020-07-02.yang" 269 module ietf-dots-signal-channel { 270 yang-version 1.1; 271 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel"; 272 prefix signal; 274 import ietf-inet-types { 275 prefix inet; 276 reference 277 "Section 4 of RFC 6991"; 278 } 279 import ietf-yang-types { 280 prefix yang; 281 reference 282 "Section 3 of RFC 6991"; 283 } 284 import ietf-dots-data-channel { 285 prefix ietf-data; 286 reference 287 "RFC 8783: Distributed Denial-of-Service Open Threat Signaling 288 (DOTS) Data Channel Specification"; 289 } 290 import iana-dots-signal-channel { 291 prefix iana-signal; 292 reference 293 "RFC 8782: Distributed Denial-of-Service Open Threat Signaling 294 (DOTS) Signal Channel Specification"; 295 } 296 import ietf-yang-structure-ext { 297 prefix sx; 298 reference 299 "RFC 8791: YANG Data Structure Extensions"; 300 } 302 organization 303 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 304 contact 305 "WG Web: 306 WG List: 308 Editor: Mohamed Boucadair 309 311 Editor: Jon Shallow 312 314 Author: Konda, Tirumaleswar Reddy.K 315 317 Author: Prashanth Patil 318 320 Author: Andrew Mortensen 321 323 Author: Nik Teague 324 "; 325 description 326 "This module contains YANG definition for the signaling 327 messages exchanged between a DOTS client and a DOTS server. 329 Copyright (c) 2020 IETF Trust and the persons identified as 330 authors of the code. All rights reserved. 332 Redistribution and use in source and binary forms, with or 333 without modification, is permitted pursuant to, and subject 334 to the license terms contained in, the Simplified BSD License 335 set forth in Section 4.c of the IETF Trust's Legal Provisions 336 Relating to IETF Documents 337 (http://trustee.ietf.org/license-info). 339 This version of this YANG module is part of RFC 8782; see 340 the RFC itself for full legal notices."; 342 revision 2020-07-02 { 343 description 344 "Updated revision to comply with RFC8791."; 345 reference 346 "RFC xxxx: A YANG Data Model for Distributed Denial-of-Service 347 Open Threat Signaling (DOTS) Signal Channel"; 348 } 349 revision 2020-05-28 { 350 description 351 "Initial revision."; 352 reference 353 "RFC 8782: Distributed Denial-of-Service Open Threat 354 Signaling (DOTS) Signal Channel Specification"; 355 } 357 /* 358 * Groupings 359 */ 361 grouping mitigation-scope { 362 description 363 "Specifies the scope of the mitigation request."; 364 list scope { 365 description 366 "The scope of the request."; 367 uses ietf-data:target; 368 leaf-list alias-name { 369 type string; 370 description 371 "An alias name that points to a resource."; 372 } 373 leaf lifetime { 374 type int32; 375 units "seconds"; 376 default "3600"; 377 description 378 "Indicates the lifetime of the mitigation request. 380 A lifetime of '0' in a mitigation request is an 381 invalid value. 383 A lifetime of negative one (-1) indicates indefinite 384 lifetime for the mitigation request."; 385 } 386 leaf trigger-mitigation { 387 type boolean; 388 default "true"; 389 description 390 "If set to 'false', DDoS mitigation will not be 391 triggered unless the DOTS signal channel 392 session is lost."; 393 } 394 choice direction { 395 description 396 "Indicates the communication direction in which the 397 nodes can be included."; 398 case server-to-client-only { 399 description 400 "These nodes appear only in a mitigation message 401 sent from the server to the client."; 402 leaf mid { 403 type uint32; 404 description 405 "Mitigation request identifier. 407 This identifier must be unique for each mitigation 408 request bound to the DOTS client."; 409 } 410 leaf mitigation-start { 411 type uint64; 412 description 413 "Mitigation start time is represented in seconds 414 relative to 1970-01-01T00:00:00Z in UTC time."; 415 } 416 leaf status { 417 type iana-signal:status; 418 description 419 "Indicates the status of a mitigation request. 420 It must be included in responses only."; 421 } 422 container conflict-information { 423 description 424 "Indicates that a conflict is detected. 425 Must only be used for responses."; 426 leaf conflict-status { 427 type iana-signal:conflict-status; 428 description 429 "Indicates the conflict status."; 430 } 431 leaf conflict-cause { 432 type iana-signal:conflict-cause; 433 description 434 "Indicates the cause of the conflict."; 435 } 436 leaf retry-timer { 437 type uint32; 438 units "seconds"; 439 description 440 "The DOTS client must not resend the 441 same request that has a conflict before the expiry of 442 this timer."; 443 } 444 container conflict-scope { 445 description 446 "Provides more information about the conflict scope."; 447 uses ietf-data:target { 448 when "/dots-signal/scope/conflict-information/" 449 + "conflict-cause = 'overlapping-targets'"; 450 } 451 leaf-list alias-name { 452 when "../../conflict-cause = 'overlapping-targets'"; 453 type string; 454 description 455 "Conflicting alias-name."; 456 } 457 list acl-list { 458 when "../../conflict-cause =" 459 + " 'conflict-with-acceptlist'"; 460 key "acl-name"; 461 description 462 "List of conflicting ACLs as defined in the DOTS data 463 channel. These ACLs are uniquely defined by 464 cuid and acl-name."; 465 leaf acl-name { 466 type leafref { 467 path "/ietf-data:dots-data/ietf-data:dots-client/" 468 + "ietf-data:acls/ietf-data:acl/ietf-data:name"; 469 } 470 description 471 "Reference to the conflicting ACL name bound to 472 a DOTS client."; 473 } 474 leaf acl-type { 475 type leafref { 476 path "/ietf-data:dots-data/ietf-data:dots-client/" 477 + "ietf-data:acls/ietf-data:acl/ietf-data:type"; 478 } 479 description 480 "Reference to the conflicting ACL type bound to 481 a DOTS client."; 482 } 483 } 484 leaf mid { 485 when "../../conflict-cause = 'overlapping-targets'"; 486 type uint32; 487 description 488 "Reference to the conflicting 'mid' bound to 489 the same DOTS client."; 490 } 491 } 492 } 493 leaf bytes-dropped { 494 type yang:zero-based-counter64; 495 units "bytes"; 496 description 497 "The total dropped byte count for the mitigation 498 request since the attack mitigation was triggered. 499 The count wraps around when it reaches the maximum value 500 of counter64 for dropped bytes."; 501 } 502 leaf bps-dropped { 503 type yang:gauge64; 504 description 505 "The average number of dropped bits per second for 506 the mitigation request since the attack 507 mitigation was triggered. This should be over 508 five-minute intervals (that is, measuring bytes 509 into five-minute buckets and then averaging these 510 buckets over the time since the mitigation was 511 triggered)."; 512 } 513 leaf pkts-dropped { 514 type yang:zero-based-counter64; 515 description 516 "The total number of dropped packet count for the 517 mitigation request since the attack mitigation was 518 triggered. The count wraps around when it reaches 519 the maximum value of counter64 for dropped packets."; 520 } 521 leaf pps-dropped { 522 type yang:gauge64; 523 description 524 "The average number of dropped packets per second 525 for the mitigation request since the attack 526 mitigation was triggered. This should be over 527 five-minute intervals (that is, measuring packets 528 into five-minute buckets and then averaging these 529 buckets over the time since the mitigation was 530 triggered)."; 531 } 532 leaf attack-status { 533 type iana-signal:attack-status; 534 description 535 "Indicates the status of an attack as seen by the 536 DOTS client."; 537 } 538 } 539 } 540 } 541 } 543 grouping config-parameters { 544 description 545 "Subset of DOTS signal channel session configuration."; 546 container heartbeat-interval { 547 description 548 "DOTS agents regularly send heartbeats to each other 549 after mutual authentication is successfully 550 completed in order to keep the DOTS signal channel 551 open."; 552 choice direction { 553 description 554 "Indicates the communication direction in which the 555 nodes can be included."; 556 case server-to-client-only { 557 description 558 "These nodes appear only in a mitigation message 559 sent from the server to the client."; 560 leaf max-value { 561 type uint16; 562 units "seconds"; 563 description 564 "Maximum acceptable heartbeat-interval value."; 565 } 566 leaf min-value { 567 type uint16; 568 units "seconds"; 569 description 570 "Minimum acceptable heartbeat-interval value."; 571 } 572 } 573 } 574 leaf current-value { 575 type uint16; 576 units "seconds"; 577 default "30"; 578 description 579 "Current heartbeat-interval value. 581 '0' means that heartbeat mechanism is deactivated."; 582 } 583 } 584 container missing-hb-allowed { 585 description 586 "Maximum number of missing heartbeats allowed."; 587 choice direction { 588 description 589 "Indicates the communication direction in which the 590 nodes can be included."; 591 case server-to-client-only { 592 description 593 "These nodes appear only in a mitigation message 594 sent from the server to the client."; 595 leaf max-value { 596 type uint16; 597 description 598 "Maximum acceptable missing-hb-allowed value."; 599 } 600 leaf min-value { 601 type uint16; 602 description 603 "Minimum acceptable missing-hb-allowed value."; 604 } 605 } 606 } 607 leaf current-value { 608 type uint16; 609 default "15"; 610 description 611 "Current missing-hb-allowed value."; 612 } 613 } 614 container probing-rate { 615 description 616 "The limit for sending Non-confirmable messages with 617 no response."; 618 choice direction { 619 description 620 "Indicates the communication direction in which the 621 nodes can be included."; 622 case server-to-client-only { 623 description 624 "These nodes appear only in a mitigation message 625 sent from the server to the client."; 626 leaf max-value { 627 type uint16; 628 units "byte/second"; 629 description 630 "Maximum acceptable probing-rate value."; 631 } 632 leaf min-value { 633 type uint16; 634 units "byte/second"; 635 description 636 "Minimum acceptable probing-rate value."; 637 } 638 } 639 } 640 leaf current-value { 641 type uint16; 642 units "byte/second"; 643 default "5"; 644 description 645 "Current probing-rate value."; 646 } 647 } 648 container max-retransmit { 649 description 650 "Maximum number of retransmissions of a Confirmable 651 message."; 652 choice direction { 653 description 654 "Indicates the communication direction in which the 655 nodes can be included."; 656 case server-to-client-only { 657 description 658 "These nodes appear only in a mitigation message 659 sent from the server to the client."; 660 leaf max-value { 661 type uint16; 662 description 663 "Maximum acceptable max-retransmit value."; 664 } 665 leaf min-value { 666 type uint16; 667 description 668 "Minimum acceptable max-retransmit value."; 669 } 670 } 672 } 673 leaf current-value { 674 type uint16; 675 default "3"; 676 description 677 "Current max-retransmit value."; 678 } 679 } 680 container ack-timeout { 681 description 682 "Initial retransmission timeout value."; 683 choice direction { 684 description 685 "Indicates the communication direction in which the 686 nodes can be included."; 687 case server-to-client-only { 688 description 689 "These nodes appear only in a mitigation message 690 sent from the server to the client."; 691 leaf max-value-decimal { 692 type decimal64 { 693 fraction-digits 2; 694 } 695 units "seconds"; 696 description 697 "Maximum ack-timeout value."; 698 } 699 leaf min-value-decimal { 700 type decimal64 { 701 fraction-digits 2; 702 } 703 units "seconds"; 704 description 705 "Minimum ack-timeout value."; 706 } 707 } 708 } 709 leaf current-value-decimal { 710 type decimal64 { 711 fraction-digits 2; 712 } 713 units "seconds"; 714 default "2"; 715 description 716 "Current ack-timeout value."; 717 } 718 } 719 container ack-random-factor { 720 description 721 "Random factor used to influence the timing of 722 retransmissions."; 723 choice direction { 724 description 725 "Indicates the communication direction in which the 726 nodes can be included."; 727 case server-to-client-only { 728 description 729 "These nodes appear only in a mitigation message 730 sent from the server to the client."; 731 leaf max-value-decimal { 732 type decimal64 { 733 fraction-digits 2; 734 } 735 description 736 "Maximum acceptable ack-random-factor value."; 737 } 738 leaf min-value-decimal { 739 type decimal64 { 740 fraction-digits 2; 741 } 742 description 743 "Minimum acceptable ack-random-factor value."; 744 } 745 } 746 } 747 leaf current-value-decimal { 748 type decimal64 { 749 fraction-digits 2; 750 } 751 default "1.5"; 752 description 753 "Current ack-random-factor value."; 754 } 755 } 756 } 758 grouping signal-config { 759 description 760 "DOTS signal channel session configuration."; 761 container mitigating-config { 762 description 763 "Configuration parameters to use when a mitigation 764 is active."; 765 uses config-parameters; 766 } 767 container idle-config { 768 description 769 "Configuration parameters to use when no mitigation 770 is active."; 771 uses config-parameters; 772 } 773 } 775 grouping redirected-signal { 776 description 777 "Grouping for the redirected signaling."; 778 choice direction { 779 description 780 "Indicates the communication direction in which the 781 nodes can be included."; 782 case server-to-client-only { 783 description 784 "These nodes appear only in a mitigation message 785 sent from the server to the client."; 786 leaf alt-server { 787 type string; 788 mandatory true; 789 description 790 "FQDN of an alternate server."; 791 } 792 leaf-list alt-server-record { 793 type inet:ip-address; 794 description 795 "List of records for the alternate server."; 796 } 797 } 798 } 799 } 801 /* 802 * DOTS Signal Channel Structure 803 */ 805 sx:structure dots-signal { 806 description 807 "Main structure for DOTS signal message. 809 A DOTS signal message can be a mitigation, a configuration, 810 or a redirected signal message."; 811 choice message-type { 812 description 813 "Can be a mitigation, a configuration, or a redirect 814 message."; 815 case mitigation-scope { 816 description 817 "Mitigation scope of a mitigation message."; 818 uses mitigation-scope; 819 reference 820 "Section 4.4 of RFC 8782"; 821 } 822 case signal-config { 823 description 824 "Configuration message."; 825 uses signal-config; 826 reference 827 "Section 4.5 of RFC 8782"; 828 } 829 case redirected-signal { 830 description 831 "Redirected signaling."; 832 uses redirected-signal; 833 reference 834 "Section 4.6 of RFC 8782"; 835 } 836 case heartbeat { 837 description 838 "DOTS heartbeats."; 839 leaf peer-hb-status { 840 type boolean; 841 mandatory true; 842 description 843 "Indicates whether a DOTS agent receives heartbeats 844 from its peer. The value is set to 'true' if the 845 DOTS agent is receiving heartbeat messages 846 from its peer."; 847 } 848 reference 849 "Section 4.7 of RFC 8782"; 850 } 851 } 852 } 853 } 854 856 5. Security Considerations 858 This document defines YANG data structures that are meant to be used 859 as an abstract representation of DOTS signal channel messages. As 860 such, this document does not introduce any new vulnerabilities beyond 861 those specified Section 10 of [RFC8782]. 863 6. IANA Considerations 865 This document requests IANA to register the following URI in the "ns" 866 subregistry within the "IETF XML Registry" [RFC3688]: 868 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel 869 Registrant Contact: The IESG. 870 XML: N/A; the requested URI is an XML namespace. 872 This document requests IANA to register the following YANG modules in 873 the "YANG Module Names" subregistry [RFC6020] within the "YANG 874 Parameters" registry. 876 Name: ietf-dots-signal-channel 877 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel 878 Maintained by IANA: N 879 Prefix: signal 880 Reference: RFC XXXX 882 7. Acknowledgements 884 Many thanks to Martin Bjoerklund for the suggestion to use RFC8791. 886 The initial version of the DOTS signal channel YANG model was 887 specified in [RFC8782] authored by Tirumaleswar Reddy.K, Mohamed 888 Boucadair, Prashanth Patil, Andrew Mortensen, and Nik Teague. 890 8. References 892 8.1. Normative References 894 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 895 DOI 10.17487/RFC3688, January 2004, 896 . 898 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 899 the Network Configuration Protocol (NETCONF)", RFC 6020, 900 DOI 10.17487/RFC6020, October 2010, 901 . 903 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 904 RFC 6991, DOI 10.17487/RFC6991, July 2013, 905 . 907 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 908 Application Protocol (CoAP)", RFC 7252, 909 DOI 10.17487/RFC7252, June 2014, 910 . 912 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 913 RFC 7950, DOI 10.17487/RFC7950, August 2016, 914 . 916 [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., 917 Mortensen, A., and N. Teague, "Distributed Denial-of- 918 Service Open Threat Signaling (DOTS) Signal Channel 919 Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, 920 . 922 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 923 Denial-of-Service Open Threat Signaling (DOTS) Data 924 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 925 May 2020, . 927 [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data 928 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 929 June 2020, . 931 8.2. Informative References 933 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 934 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 935 . 937 Authors' Addresses 939 Mohamed Boucadair 940 Orange 941 Rennes 35000 942 France 944 Email: mohamed.boucadair@orange.com 946 Jon Shallow 947 United Kingdom 949 Email: supjps-ietf@jpshallow.com