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