]> Orange

Rennes 35000 France mohamed.boucadair@orange.com

United Kingdom supjps-ietf@jpshallow.com

DOTS This document specifies an updated version of the Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel YANG data model. This updated version makes use of the new mechanisms for defining abstract data structures with YANG as specified in RFC8791. This document updates RFC 8782.

As specified in , messages exchanged between DOTS agents are serialized using Concise Binary Object Representation (CBOR) . CBOR-encoded payloads are used to carry signal channel-specific payload messages which convey request parameters and response information such as errors. This document specifies a YANG module for representing DOTS mitigation scopes, DOTS signal channel session configuration data, and DOTS redirected signaling. All parameters in the payload of the DOTS signal channel are mapped to CBOR types as specified in Table 5 of . This YANG module is not intended to be used via NETCONF/RESTCONF for DOTS server management purposes; such a module is out of the scope of this document. It serves only to provide abstract data structures. This document uses the "structure" extension specified in . The meaning of the symbols in YANG tree diagrams is defined in and .

The main changes compared to the YANG version published in are as follows: Follow the new YANG data structure specified in . Add in "choice" to indicate the communication direction in which a data node applies. If no "choice" is indicated, a node can appear in both directions (i.e., from DOTS clients to DOTS servers and vice versa). Remove "config" clauses. Note that "config" statements will be ignored (if present) anyway according to Section 4 of . Remove "cuid", "cdid", and "sid" nodes from the structure because these nodes are included as Uri-Path options, not within the message body. Remove the list keys for the mitigation scope message type (i.e., "cuid" and "mid"). "mid" is not indicated as a key because it is included as Uri-Path option for requests and in the message body for responses. Note that Section 4 of specifies that a list does not require to have a key statement defined. These changes are made with the constraint to avoid changes to the mapping table defined in Table 5 of . A DOTS signal channel attribute that may be present in both requests and responses will thus have the same CBOR key value and CBOR major type.

This document defines the YANG module "ietf-dots-signal-channel", which has the following tree structure. A DOTS signal message can be a mitigation, a configuration, a redirect, or a heartbeat message. The use of these attributes is specified in . This tree structure obsoletes the one described in Section 5.1 of .

This module uses the common YANG types defined in and types defined in . This version obsoletes the version described in Section 5.3 of .

file "ietf-dots-signal-channel@2020-07-02.yang" module ietf-dots-signal-channel { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel"; prefix signal; import ietf-inet-types { prefix inet; reference "Section 4 of RFC 6991"; } import ietf-yang-types { prefix yang; reference "Section 3 of RFC 6991"; } import ietf-dots-data-channel { prefix ietf-data; reference "RFC 8783: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification"; } import iana-dots-signal-channel { prefix iana-signal; reference "RFC 8782: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; } import ietf-yang-structure-ext { prefix sx; reference "RFC 8791: YANG Data Structure Extensions"; } organization "IETF DDoS Open Threat Signaling (DOTS) Working Group"; contact "WG Web: WG List: Editor: Mohamed Boucadair Editor: Jon Shallow Author: Konda, Tirumaleswar Reddy.K Author: Prashanth Patil Author: Andrew Mortensen Author: Nik Teague "; description "This module contains YANG definition for the signaling messages exchanged between a DOTS client and a DOTS server. Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 8782; see the RFC itself for full legal notices."; revision 2020-07-02 { description "Updated revision to comply with RFC8791."; reference "RFC xxxx: A YANG Data Model for Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel"; } revision 2020-05-28 { description "Initial revision."; reference "RFC 8782: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; } /* * Groupings */ grouping mitigation-scope { description "Specifies the scope of the mitigation request."; list scope { description "The scope of the request."; uses ietf-data:target; leaf-list alias-name { type string; description "An alias name that points to a resource."; } leaf lifetime { type int32; units "seconds"; default "3600"; description "Indicates the lifetime of the mitigation request. A lifetime of '0' in a mitigation request is an invalid value. A lifetime of negative one (-1) indicates indefinite lifetime for the mitigation request."; } leaf trigger-mitigation { type boolean; default "true"; description "If set to 'false', DDoS mitigation will not be triggered unless the DOTS signal channel session is lost."; } choice direction { description "Indicates the communication direction in which the nodes can be included."; case server-to-client-only { description "These nodes appear only in a mitigation message sent from the server to the client."; leaf mid { type uint32; description "Mitigation request identifier. This identifier must be unique for each mitigation request bound to the DOTS client."; } leaf mitigation-start { type uint64; description "Mitigation start time is represented in seconds relative to 1970-01-01T00:00:00Z in UTC time."; } leaf status { type iana-signal:status; description "Indicates the status of a mitigation request. It must be included in responses only."; } container conflict-information { description "Indicates that a conflict is detected. Must only be used for responses."; leaf conflict-status { type iana-signal:conflict-status; description "Indicates the conflict status."; } leaf conflict-cause { type iana-signal:conflict-cause; description "Indicates the cause of the conflict."; } leaf retry-timer { type uint32; units "seconds"; description "The DOTS client must not resend the same request that has a conflict before the expiry of this timer."; } container conflict-scope { description "Provides more information about the conflict scope."; uses ietf-data:target { when "/dots-signal/scope/conflict-information/" + "conflict-cause = 'overlapping-targets'"; } leaf-list alias-name { when "../../conflict-cause = 'overlapping-targets'"; type string; description "Conflicting alias-name."; } list acl-list { when "../../conflict-cause =" + " 'conflict-with-acceptlist'"; key "acl-name"; description "List of conflicting ACLs as defined in the DOTS data channel. These ACLs are uniquely defined by cuid and acl-name."; leaf acl-name { type leafref { path "/ietf-data:dots-data/ietf-data:dots-client/" + "ietf-data:acls/ietf-data:acl/ietf-data:name"; } description "Reference to the conflicting ACL name bound to a DOTS client."; } leaf acl-type { type leafref { path "/ietf-data:dots-data/ietf-data:dots-client/" + "ietf-data:acls/ietf-data:acl/ietf-data:type"; } description "Reference to the conflicting ACL type bound to a DOTS client."; } } leaf mid { when "../../conflict-cause = 'overlapping-targets'"; type uint32; description "Reference to the conflicting 'mid' bound to the same DOTS client."; } } } leaf bytes-dropped { type yang:zero-based-counter64; units "bytes"; description "The total dropped byte count for the mitigation request since the attack mitigation was triggered. The count wraps around when it reaches the maximum value of counter64 for dropped bytes."; } leaf bps-dropped { type yang:gauge64; description "The average number of dropped bits per second for the mitigation request since the attack mitigation was triggered. This should be over five-minute intervals (that is, measuring bytes into five-minute buckets and then averaging these buckets over the time since the mitigation was triggered)."; } leaf pkts-dropped { type yang:zero-based-counter64; description "The total number of dropped packet count for the mitigation request since the attack mitigation was triggered. The count wraps around when it reaches the maximum value of counter64 for dropped packets."; } leaf pps-dropped { type yang:gauge64; description "The average number of dropped packets per second for the mitigation request since the attack mitigation was triggered. This should be over five-minute intervals (that is, measuring packets into five-minute buckets and then averaging these buckets over the time since the mitigation was triggered)."; } leaf attack-status { type iana-signal:attack-status; description "Indicates the status of an attack as seen by the DOTS client."; } } } } } grouping config-parameters { description "Subset of DOTS signal channel session configuration."; container heartbeat-interval { description "DOTS agents regularly send heartbeats to each other after mutual authentication is successfully completed in order to keep the DOTS signal channel open."; choice direction { description "Indicates the communication direction in which the nodes can be included."; case server-to-client-only { description "These nodes appear only in a mitigation message sent from the server to the client."; leaf max-value { type uint16; units "seconds"; description "Maximum acceptable heartbeat-interval value."; } leaf min-value { type uint16; units "seconds"; description "Minimum acceptable heartbeat-interval value."; } } } leaf current-value { type uint16; units "seconds"; default "30"; description "Current heartbeat-interval value. '0' means that heartbeat mechanism is deactivated."; } } container missing-hb-allowed { description "Maximum number of missing heartbeats allowed."; choice direction { description "Indicates the communication direction in which the nodes can be included."; case server-to-client-only { description "These nodes appear only in a mitigation message sent from the server to the client."; leaf max-value { type uint16; description "Maximum acceptable missing-hb-allowed value."; } leaf min-value { type uint16; description "Minimum acceptable missing-hb-allowed value."; } } } leaf current-value { type uint16; default "15"; description "Current missing-hb-allowed value."; } } container probing-rate { description "The limit for sending Non-confirmable messages with no response."; choice direction { description "Indicates the communication direction in which the nodes can be included."; case server-to-client-only { description "These nodes appear only in a mitigation message sent from the server to the client."; leaf max-value { type uint16; units "byte/second"; description "Maximum acceptable probing-rate value."; } leaf min-value { type uint16; units "byte/second"; description "Minimum acceptable probing-rate value."; } } } leaf current-value { type uint16; units "byte/second"; default "5"; description "Current probing-rate value."; } } container max-retransmit { description "Maximum number of retransmissions of a Confirmable message."; choice direction { description "Indicates the communication direction in which the nodes can be included."; case server-to-client-only { description "These nodes appear only in a mitigation message sent from the server to the client."; leaf max-value { type uint16; description "Maximum acceptable max-retransmit value."; } leaf min-value { type uint16; description "Minimum acceptable max-retransmit value."; } } } leaf current-value { type uint16; default "3"; description "Current max-retransmit value."; } } container ack-timeout { description "Initial retransmission timeout value."; choice direction { description "Indicates the communication direction in which the nodes can be included."; case server-to-client-only { description "These nodes appear only in a mitigation message sent from the server to the client."; leaf max-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Maximum ack-timeout value."; } leaf min-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Minimum ack-timeout value."; } } } leaf current-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; default "2"; description "Current ack-timeout value."; } } container ack-random-factor { description "Random factor used to influence the timing of retransmissions."; choice direction { description "Indicates the communication direction in which the nodes can be included."; case server-to-client-only { description "These nodes appear only in a mitigation message sent from the server to the client."; leaf max-value-decimal { type decimal64 { fraction-digits 2; } description "Maximum acceptable ack-random-factor value."; } leaf min-value-decimal { type decimal64 { fraction-digits 2; } description "Minimum acceptable ack-random-factor value."; } } } leaf current-value-decimal { type decimal64 { fraction-digits 2; } default "1.5"; description "Current ack-random-factor value."; } } } grouping signal-config { description "DOTS signal channel session configuration."; container mitigating-config { description "Configuration parameters to use when a mitigation is active."; uses config-parameters; } container idle-config { description "Configuration parameters to use when no mitigation is active."; uses config-parameters; } } grouping redirected-signal { description "Grouping for the redirected signaling."; choice direction { description "Indicates the communication direction in which the nodes can be included."; case server-to-client-only { description "These nodes appear only in a mitigation message sent from the server to the client."; leaf alt-server { type string; mandatory true; description "FQDN of an alternate server."; } leaf-list alt-server-record { type inet:ip-address; description "List of records for the alternate server."; } } } } /* * DOTS Signal Channel Structure */ sx:structure dots-signal { description "Main structure for DOTS signal message. A DOTS signal message can be a mitigation, a configuration, or a redirected signal message."; choice message-type { description "Can be a mitigation, a configuration, or a redirect message."; case mitigation-scope { description "Mitigation scope of a mitigation message."; uses mitigation-scope; reference "Section 4.4 of RFC 8782"; } case signal-config { description "Configuration message."; uses signal-config; reference "Section 4.5 of RFC 8782"; } case redirected-signal { description "Redirected signaling."; uses redirected-signal; reference "Section 4.6 of RFC 8782"; } case heartbeat { description "DOTS heartbeats."; leaf peer-hb-status { type boolean; mandatory true; description "Indicates whether a DOTS agent receives heartbeats from its peer. The value is set to 'true' if the DOTS agent is receiving heartbeat messages from its peer."; } reference "Section 4.7 of RFC 8782"; } } } } ]]>

This document defines YANG data structures that are meant to be used as an abstract representation of DOTS signal channel messages. As such, this document does not introduce any new vulnerabilities beyond those specified Section 10 of .

This document requests IANA to register the following URI in the "ns" subregistry within the "IETF XML Registry" :

This document requests IANA to register the following YANG modules in the "YANG Module Names" subregistry within the "YANG Parameters" registry.

Many thanks to Martin Björklund for the suggestion to use RFC8791. The initial version of the DOTS signal channel YANG model was specified in authored by Tirumaleswar Reddy.K, Mohamed Boucadair, Prashanth Patil, Andrew Mortensen, and Nik Teague.